qboosh: SPECS busybox.spec,1.29,1.30

[Tomasz Kłoczko]

On Thu, 17 Jan 2002, Michal Moskal wrote:

> 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...

Pakiety takie jak reiserfsprogs-BOOT, mawk-BOOT, poldek-BOOT, parted-BOOT
nie są linkowane z uClibc tylko z glibc-static. Na sparc i na axp nie ma 
uClibc a po mimo tego te pakiety daję sie zbudować (właśsnie dlatego że 
nie używają w procedurze zawartej w specu uClibc).

> > 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ę.

Na sparc64 owszem ale an sparc jak najbardziej. Zresta prawie skończony
kod ld.so pod sparc jest dołączony do źródeł uClibc. Tak czy inaczje 
robienie portu sparc64 jeszcze przez jakis czas jest po za zasiegiem bo 
bezie to wymagało użycia gcc 3.x (do generowania binarek 64bit na sparc64 
żeby wyprodukowac kernel są odpowiednie/użyteczne/dające poprawny efekt 
źródła).

> 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ć.

To jest osobna sprawa i zalene przyjjdzie rozwiązać to podobnie jak na RH 
gdzie wydzielono część anacondy kompletnie niezależną od arch i takie 
cżęsi które funkcjonuja jako backendy do konkretnej archotektóry. W tym 
moencie i tak nie ma to znaczenia. Jezeli juz w tej chwili ujednolicenie 
związane z używanie uClib pozwolic moze w wygodniejszym odseparowywaniu 
tych częsic zależnych od arch.
Tak czy inaczej juz teraz nie musimy rozwiązywać sprawy z 
wieloplatformowością instalatora. Ważne jest aby za kawałek było ty tak 
łatwe jak to jest tylko możliwe.

[..]
> > Wyjdzie na to że raczej tak to będzie musiało wygladać. 
> 
> Why? W sensie w zamian za co?

Poprostu separacja zadań i środowisk. Buildery są dość czułym punktem tego 
co mamy. De facto majac dostęp do choć jednego buildera na którym są 
produkowane pakiety ma się ma sie taka sytuację w tej chwili jakby się 
miało dsęp do wszystkich (po mimo że są one na rózncyh maszynach) jak i 
jeszcze dalszej niewatpliwie ważnej części zasobół jakie posiadamy. Dalsze 
zmiany w skryptach buildrów bezą musiały niewątpliwie iść w kierunku 
pzreciecia niektórych pzrejść choćby po to żeby ograniczyć potencjalne 
skutki nieautoryzowanego dostępu do jednej z maszyn. Mówiac inaczje żeli 
coś mozę pracować w lepszej separacji od reszty to tak niewątpliwie 
powinno być. Wydzielenie buildra dna zasoby instalatora pozwoli dać 
wybranym osobom dosęp do tego nbez narażania na niepotrzebne ryzyko reszty 
zasobów.
Możliwie szczelne pzregrody w tych "naczyniach" jakie mamy bedą musiały 
sie pojawić w momecie kiedy pakiety zacna być podpisywane. Mówiac inaczje 
podpisywanie w obecnym ifrastruktórze nie daje wystarczajacego poziomu 
pewnisci że nikt niepowołany się do tego nie dostaje. Niewątpliwie 
podpisywanie zasobół bezie trobione z osobnego punktu całego schematu 
narzędzi. Najlepiej zreszta byłoby to zrobić tak żeby żaden z nas nie miał 
możliwości bezposredniego dostępu do zasobów z których odbywa się 
podpisywanie (chodzi o możliwie maksymalne wyeliminowanie czynnika 
"ludzkiwgo" w tej procedurze). jak to dokałdnie w szczegółąch zrobic 
jeszcze nie wiem ale nie wątpie że jest to mozlwie do zrobienia.

> > 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!

Wszystko co zadziała w ramach wsólnego podzbioru funkcjonalnosci. Jasne że
niektóre rzeczy nie bendą się zachowywać dokładnie tak samo ..  choćby
linkowanie z jakimś zestawem funkcji z libc jednym czy drugim przypadku
będzie powodować produkcję różenj wielkosci zasobów wynikowych czyli
choćby tego właśnie nie będziesz w stanie wytestowac do końca ale beziesz 
w stanie wytestować na pewno jakiś innyc zbiór funkcji czy choćby pozwoli 
Ci to na wsepne oszacowanie ilosci miesca jakie będzie potzrebne.
 
> > 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ć?

Łaj not ? Nie musisz od razu wykonywac prób na żywej partycji. Zacżąć 
mozan od choćby pliku wygenerowanego z użyciem dd (choćby i bardzo duzego 
o ile bedzie to plik z dziurami po to żeby sprawdzic do jakich rozmiarów 
wolumetu takie e2fsprogs beda poprawnie działać. W ten sposób z Andrzejem 
Krzystofoficzem znaleźliśmy jakiś czas temu błąd w ext2.mkfs na axp na 
urządzeniach mających rozmiar powyżej 2TB mając do dyspozycji dysk tylko 
16GB. Co wiecej taki wolumen z dzirami dawało sie podmontować i zapisać 
nawet na tym jakeiś pliki co powodowało alokowanie fizycznie miejsca na
dysku (taki pusty wolumen 2T założony na pliku zajmował fizycznie coś koło 
2.5GB). Błąd akurat był i glibc i mkfs do ext2 ale już dość dawno zostało 
to poprawione w obu miejscach.

Tak czy inaczje wszystko robić można i trzeba robic z głową. Z 
konktretnego podejścia bendą wynikać konkretne konsekwencje i oczekiwanie 
że w obu przypadkach (uClibc i glibc) zachowywać się bezie to zawsze 
dokąłdnie tak samo jasne ze nie ma najmniejszego sensu.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*