On Mon, Dec 08, 2003 at 09:31:07AM +0100, Jacek Konieczny wrote: > On Mon, Dec 08, 2003 at 09:11:45AM +0100, Arkadiusz Miskiewicz wrote: > > On Monday 08 of December 2003 08:34, Jacek Konieczny wrote: > > > Po co je instalować? Wolę mieć wszystko 64-bitowe. > > Bo masz np. binarkę programu 32bitowego do którego nie ma źródeł, a bardzo Ci > > jest on potrzebny. Co wtedy? > > Np. na PPC też przecież nie pójdzie bez odpowiedniego emulatora. Dla > amd64 można przygotować jakieś compatibility-pack, ale szykowanie całego > systemu dual-arch to nas przerośnie. Gdy było jeszcze trochę binarek > a.out to PLD jakoś sobie z tym radziło (przez odpowiedni > compatibility-pack) mimo że nie robiliśmy pełnego wsparcia dla obu > formatów. Podobnie było ze wsparciem dla libc5. IMHO tędy jest właściwa > droge. > > > > Ja po prostu wolałbym single-arch, tak jak większość supportowanych > > > przez nas architektur, bo z dual-arch po prostu sobie nie poradzimy. > > Też bym tak wolał - pytanie, olewamy 32bitowe binarki? np. taki eagle do > > projektowania płytek drukowanych, gry Loki, jave binarkową itd > > Na razie bym się o to nie martwił. AMD64 to raczej na serwery, a chyba > niczego z powyższych na serwerach instalował nie będziesz.
a) Java? b) Na razie raczej serwery, ale za rok czy dwa? > > > > W FHS piszą o rozkładzie bibliotek na amd64 i ia64 dokładniej. > > > > > > Link? > > http://www.samba.org/~cyeoh/fhs-2.3-beta.pdf > > > > > Twierdzisz, że pozostałe biblioteki wystarczą w jednej wersji i będą > > > z tym działać zarówno aplikacje 32- jak i 64-bitowe? Jeżeli tak, to > > > znaczy że 64-bitowość takiego systemu to po prostu bajka. > > Twierdze, że tylko glibc w jednej paczce zawierał by i 32 i 64bitowe wersje > > bibliotek. Reszte brałbyś z np. Ac dla athlona - to też wymusza /lib64. > > Niemniej jednak nie problem zrobić glibc64+glibc64-devel jako osobne pakiety. BTW: rpm sam sobie ustawia %{_lib} = lib64 dla sparc64; na x86_64 i ppc64 pewnie tak samo jest/będzie. Tylko chyba trzeba %{_libexecdir} poprawić ze sztywnego /usr/lib na /usr/%{_lib}. > No i jak instalacja. Basesystem na wszystkich architekturach zawierałby > "glibc" a na AMD64 "glibc64"? Trochę głupio. > > Jak komuś zależy na aplikacjach 32-bitowych na AMD64, to niech instaluje > wersję athlonową. Musiałaby nie kolidować z wersją x86_64 - czyli z innym %{_lib}. Tylko co z zawartością %{_bindir}? rpm 4.1+ _chyba_ jakoś wspiera instalowanie wersji 32-bitowych obok 64-bitowych. Widziałem, że w rawhide/fedora-devel ELF-y są pokolorowane (32-bitowe z i?86 mają kolor 1, 64-bitowe ia64, x86_64 czy ppc64 mają kolor 2, reszta 0). W changelogu rpm-a zauważyłem jakąś wzmiankę o autorelokacji kolorowanych plików na ia64. Trzeba by to lepiej rozeznać - tędy może być droga. > Zakładam, że jak ktoś instaluje dystrybucję w wersji > amd64, to biblioteki 32-bitowe albo nie są mu potrzebne, ale mają być > jedynie dodatkiem dla kompatybilności. > > > ps. nie narzucam niczego, próbuje tylko dojść do jakiegoś obrazu glibc, który > > można by zacząć wprowadzać na glibc.spec:DEVEL > > Ja bym chciał mieć glibc dla AMD64 na HEAD, ale takie, żeby nie psuło > nic innego. Najpierw DEVEL (czy inny branch), jak się będzie wreszcie budować, to się zmerguje na HEAD. Na razie próby na HEAD doprowadziły do rozwalenia speca. -- Jakub Bogusz http://cyber.cs.net.pl/~qboosh/ __________________________________________________________ nie pytaj co inni zrobili dla pld, pomysl ile sam zrobiles
