On Thu, Jan 17, 2002 at 06:00:10PM +0100, Tomasz Kłoczko wrote:
> 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.
hmm, to może czy prawie może?
> 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).
Hmm... niedługo będzie już 3.1 i 3.0 czeka los 2.95, więc z gcc 3 chyba
nie ma co zwlekać. (aha, comment from /me 3.1 pewnie będzie przez jakiś
czas nie do użytku biorąc pod uwage ilość zmian).
> > 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.
jeżeli tak twierdzisz...
> 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.
[snip]
Ja nie mówie o osobnym chroocie na installer (to jest dobry pomysł,
IMHO), ale o konieczności posiadnia chroota przez człowieka, który
będzie chciał z tym coś robić.
> > > 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.
Do wstępnego testowania skryptów nie ptrzebuje żadnych programów BOOT,
to co jest w normalnym systmie mi wystarcza. Natomiast czasem muszę
coś konkretnego sprawdzić (czy grep z busybox obsługuje opcję taka i
taką, i czemu wraz z nią robi SEGV etc), wtedy potrzebuje binarki
*dokładnie* takie jak na bootdisku.
> > > 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.
Ja mówie, że takie e2fsprogs właduje mi się do /sbin. I to mi się nie
podoba. Podobnie kernel-BOOT czy cokolwiek innego.
> 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.
IMHO można to zrobić tak:
podpakiety, powiedzmy embed (chociaż BOOT też nie jest złym wyjściem,
ale jest może trochę mylące), które ładują się do
%define _embedpath /usr/lib/embed (do makr rpm'a)
%{_embedpath}/{bin,lib,whatever}
embed/usr/ chyba nie będzie potrzebne?
są budowane z bcond, ale domyślnie on (żeby lądowały na ftp).
i linkowane *statycznie*, dynamiczne, jeśli komuś się chce, jako
*NIESTABILNE* do brancha. Ok?
jak nie będzie sprzeciwów, zajmę się tym.
--
: 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