SPECS: glibc.spec (HEAD)

[Tomasz Trojanowski]

On Sat, 4 Jan 2003, Radoslaw Zielinski wrote:

> wrobell <wrobell w ite.pl> [04-01-2003 13:20]:
> > On Sat, Jan 04, 2003 at 01:58:32AM +0100, radek wrote:
> [...]
> > Poniższe dotyczy pakietu glibc-devel.
> >>  Requires:	%{name} = %{version}
> >> -Requires:	kernel-headers = %(rpm -q kernel-headers --queryformat '%{VERSION}')
> >> +Requires:	%{name}-kernel-headers = %{version}-%{release}
> > Trudno jest mi prześledzić obecnie cały wątek na temat powyższego wymogu.
> 
> > Czy może mi ktoś (radek, qboosh?) podać zestawienie argumentów za powyższą
> > zmianą? [1]
> 
> ,,Sure thing.''
> 
> Budowanie glibca zależy od obecnych w systemie nagłówków jądra.  Część
> plików nagłówkowych [1], dostarczanych przez glibc-devel, a stosowanych
> przy budowaniu innego oprogramowania, także włącza nagłówki jądra.  Aby
> zapewnić, że dany pakiet, korzystający (bezpośrednio czy pośrednio) z
> tych plików, zbuduje się niezależnie od dostępnej w /usr/src/linux
> wersji jądra czy fantazji grzebiącej w tym katalogu osoby [2], należy
> dostarczyć dokładnie tych nagłówków jądra, z którymi budowany był glibc.

Jezu, przecież budowanie glibca, ma miejsce na builderach i na nich 
zapewnione są odpowiednie nagłówki jądra, "inne oprogramowanie" też jest 
budowanie na builderach. Zatem powyższe to żaden argument w przypadku gdy 
instalujesz tylko i wyłacznie pakiety dystrybucyjne.

W przeciwnym wypadku, kiedy robisz rpm -e kernel, to już raczej wiesz co 
robisz. Tylko dlaczego należy to ludziom utrudniać, przez jakieś głupie 
zależności, albo wprowadznie osobnych pakietów dostarczajacych nagłówki.

Dodanie {,Build}Requires: kernel-headers, niczego nie wnosi. Niczego. Więc 
najlepiej wycofaj te wszystkie zmiany i prześpij się z tym jeszcze kilka dni.

> [2]  /usr/src/linux jest do grzebania, prawda?  Ja straciłem ładną
> chwilę na zorientowanie się, dlaczego nie buduje mi się pewien pakiet,
> który budował się wcześniej bez żadnych problemów.  Okazało się, że
> kilka dni wcześniej wykonałem `make mrproper`, co spowodowało usunięcie
> dowiązania symbolicznego, na które wskazywał /usr/include/asm.

To tym bardziej, źle swiadczy o Tobie skoro komunikaty typu:

In file included from /usr/include/signal.h:307,
                 from gbacktrace.c:34:
/usr/include/bits/sigcontext.h:28: asm/sigcontext.h: No such file or directory

nic Ci nie mówi

> > [1] problem niespełnionych zależności mnie nie interesuje ponieważ
> > pld ma być elastyczną dystrybucją i nie narzucać sztywnych rozwiązań
> > (jakim jest np.: wymóg dystrybucyjnego jajka, albo jedynie słusznego mta)
> 
> Już przecież nie wymaga dystrybucyjnego jajka.  W tej zmianie nie chodzi
> o ,,jedyniesłuszność'', tylko o prawidłowość rozwiązania.

Bzdura. Wydaje mi się, że jednak chodzi o jedyniesłuszność skoro 
zasłaniasz się jakimiś nieistniejącymi założeniami.

Pozdrawiam

-- 
Tomasz Trojanowski (tomek w uninet.com.pl)

"Between depriving a man of one hour from his life and depriving him of
his life there exist only a difference of degree." (FH, Dune Messiah)