SPECS: glibc.spec (HEAD)

[wrobell]

On Sat, Jan 04, 2003 at 06:15:19PM +0100, Tomasz Pala wrote:
> On Sat, Jan 04, 2003 at 17:42:51 +0100, wrobell wrote:
> 
> > > Argumentem jest taka zależność. Podaj argument przeciwko [1].
> > 
> > 1. aplikacja korzystająca z sg3 (scsi generic 3), może być kompilowana
> > z glibc-em budowanym w otoczeniu kernela 2.2.x, ale musi być kompilowana
> > z nagłówkami jajka 2.4.x (brak w/w zależności bardzo mi ułatwiał
> 
> Może ja czegoś nie wiem, ale czy jeśli ustawisz jako pierwsze
> -I/usr/src/include to nie będą one miały priorytetu?

Czyli muszę zacząć kombinować i dla każdej dystrybucji (bo tak naprawdę
brak tu standardu IMHO) rzeźbić?

> > kompilowanie niektórych programów ponieważ nie musiałem sam sobie
> > przekompilowywać glibc-a w czasach gdy używałem glibc z Ra i jajka 2.4.x;
> 
> Ja używam Ra i kernela 2.4.x. I widziałem już różnice w działaniu, gdy
> kompilowałem z nagłówkami 2.4.x zamiast 2.2.x.

Ale ja nie twierdzę, że tak nie jest. Elastyczność ma swoje wady i zalety.
Tylko dlaczego mam zostać pozbawiony wyboru?

> > 2. w przypadku byka w nagłówkach jajka np.: 2.4.19, jestem zmuszony do czekania
> > kilku dni na przekompilwanie glibc, zamiast sobie po prostu nałożyć łatę
> > z 2.4.20 na źródła kernel-a
> 
> Analogicznie można powiedzieć, że w przypadku byka w nagłówkach glibcach
> trzeba czekać kilka dni na jego przekompilowanie, zamiast używać
> nagłówków z nowego. Jednak tej zależności nikt nie proponuje urwać.

popatrz jak często zmienia się wersja glibc, a jak często kernela

dodatkowo zazwyczaj korzystasz z najnowszej wersji glibc, natomiast
z jajka tego, które Ci najbardziej odpowiada (różnorodność wersji,
dostawców (aa, ac, oryginalne), linii rozwojowych (2.0, 2.2, 2.4, 2.5.x))

kernel jest specyficznym przypadkiem, dlatego powinna zostać elastyczność

[...]

    wrobell <wrobell w ite.pl>
-------------- następna część ---------
Załącznik, który nie był tekstem został usunięty...
Name: nie znany
Type: application/pgp-signature
Size: 189 bytes
Desc: nie znany
Url : /mailman/pipermail/pld-devel-pl/attachments/20040626/b11fc0a3/attachment.bin