glibc.spec z HEAD popusty

[Jakub Bogusz]

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/