qboosh: SPECS busybox.spec,1.29,1.30

[Michal Moskal]

On Thu, Jan 17, 2002 at 04:10:22PM +0100, Tomasz Kłoczko wrote:
> On Thu, 17 Jan 2002, Michal Moskal wrote:
> [..]
> > 1. shared uclibc *nie* *wnosi* duzo w sprawie rozmiru binarek
> >    to nie glibc, gdzie static hello world ma 400k.
> 
> Wnosi sporo. Spora ilsć pakeitów jakei mamy jest statycznie linkowana z 
> glibc dodatkowo. 

nie rozumiem...

> Po za tym pakiety linkowane z shared uClibc mieć bendą 
> sporo zastosowań w ssytemach embeded (przykąłdowo werdług tego co jest na 
> stronie uClibc z tą bioblioteką kompiluje sie XFree86).

ok, whatever

> > 2. to nie jest mocno przetestowane przez developerow uclibc, ergo
> >    pewnie gdzies sie wywali
> 
> Można to sprawdzić. Wątpie żeby błąd był akurat w ld.so.
> Tak czy inaczje testowanie i tego będzie miało znaczenie nie tylko dla 
> instalatora.
> Jeżeli załatwimy przy okazji to to mozę się za niedługi czas okazać że 
> PLD jest NAJLEPSZĄ platformą do pracy nad systemami embeded bo bezie 
> miałoa fiormowo dodatkopwy zestaw pakeitów z binarek których bezie można 
> preparować dowolnie przycięty sysytem bez rekompilacji choćby jednego 
> potrzebnego w takich zastosowaniach programu czy też nawet znaczneejh 
> ilści potrzebnych w takich zastosowaniach binarek.
> Top że sami beziemy użwać juz neijako by example takiego przyciętego 
> systemu w pstaci instalatora będzie można uznać za dodatkową okoliczność
> pokazującą jak takie rzeczy preparować z zasobów dystrybucyjnych bez
> podejmowania zbędnych krków.

ok, wszystko pięknie.

> Za kawąłek tego typu podejście oparte o swego rodzaju uogólnienie powinno 
> ułatić *znacznie* robienie instalatora pod sparc* a już za kawałek powinno 
> takzę wpłynać na dalsze uproszeczenie preparowani instalki na x86.

afaik uClibc nie może być shared pod sparc? Ale może się mylę. Tak czy
siak największym problemem z instalacją skwarka jest przpisanie skryptów
które coś robią z urządzeniami (detect-pci-devices i spółka) a nie
rekompilacja tych kilku pakietów. No i oczywiście brak osoby z dostępem
do skwarka która chciałaby to zrobić.

> > > Inne podejście jest takie że skoro ma powstać osobny builder do budowaniua 
> > > instalatora to w tym chroot możnaby w zasadzie trzymać wersje pakeitów 
> > > kompilowane według obecnej procedury ale z "%__cc <arch>-uclibc-cc" co w 
> > > zasadzie powinno uprościć jeszcze bardziej proces budowania instalatora i 
> > > kto wie czy raczje w tym kierunku nie należałoby iść.
> > 
> > Nie każdy kto chce się zajmować installerem musi mieć chroot do tego.
> 
> Wyjdzie na to że raczej tak to będzie musiało wygladać. 

Why? W sensie w zamian za co?

> uClibc jest w
> intencji takie żeby było funkcjonalnym odpowiednikiem glibc w części
> bedącej wspólnym podzwbiorem funkcjonalności. 

parse error.

To zdanie jest prawdziwe również dla cioci kloci (która ma zero wspólnej
funkcjonalności z glibc, więc ma wszystkie funkcje ze zbioru
pustego, które ma glibc), oraz uClibc, ponieważ niewątpliwie ma wszystkie 
funkcje, które ma...

> W tym sensie o ile już ld.so
> z uClibc będzie pracować poprawnie (a z tego co widże pracuje tak) nic nie
> bezie stało na pzreszkodzie zebyutestować dany zaso mopząń było w
> środowisku nie opartym o uClibc. 

To znaczy jak rozumiem mam linkować ash BOOT z glibc, żeby sprawdzić czy
niczego mu w uClibc nie brakuje?

A może mam testować czy ten zlinkowany z glibc ash mi wejdzie na bootdisk?

Albo czemu busybox na uclibc mówi w jednym miejscu memory exhausted, a
na glibc nie, też mam sprawdzać po linkowaniu z uclibc?

Mówisz od rzeczy!

> Po za tym jeśli chdozi o testowanie to
> uClibc jest opcjonalne i moząń go uzywać bez chroot. 

Po skompilowaniu z %__cc gcc-uclibc? mam sobie takiego e2fsprogs
zainstalować i testować?

> Chroot miałby byc
> tylko wymagany przy preparowniu i składaniu całości ze zwględu na
> separacje tych zasobów od reszty systemu na którym są robione produkcyjne
> zasoby (co nie musi oznaczać że nie dałoby sie tego tak zrobić żeby
> developer używał tego bez chroot .. naeleży tylko chwilę sie zastanowić
> jak to rozwiązać żeby przy preparownaiu zasobół użycie odseparowanego
> środowiska było opcjonalne co jest niewatpliwie w stu procentach
> wykonalne, a co więcej .. potrzebne).
                            ^^^^^^^^^

Nie da się ukryć. I tak jest teraz, kiedy binraki boot lądują w innych
katalogach.

> Tak czy inaczej gotuj się na to że preparowanie instalatora w na 
> builderze i386 jest już z zasadzie w tej chwili anachronizmem i będzie
> toleroane jtak długo jak tylko bezie to niezbedne (czytaj: inaczej się nie 
> da bo w danym momencie nie ma jeszcze gotowego osobnego środowiska do 
> budowania instalatora). To że to było budowane w jednym środowisku do tej
> pory winikało li tylko z ograniczeń miejsca dostępnego pod coś ytakeigo. 
> Od kilklunastu dni takie ograniczenie nie isnieje w zawiazku z tym należy 
> już tak działąć jakby to co jest obecnie było tylko stanem przejsciowym a
> nie docelowym,

Wiem.

-- 
: Michal ``,/\/\,       '' Moskal    | |            : GCS {C,UL}++++$
:          |    |alekith      @    |)|(| . org . pl : {E--, W, w-,M}-
:    Linux: We are dot in .ORG.    |                : {b,e>+}++ !tv h
: CurProj: ftp://ftp.pld.org.pl/people/malekith/ksi : PLD Team member