SPECS: glibc.spec (HEAD)

[wrobell]

On Sat, Jan 04, 2003 at 08:26:48PM +0100, Radoslaw Zielinski wrote:
> wrobell <wrobell w ite.pl> [04-01-2003 19:01]:
> > On Sat, Jan 04, 2003 at 06:25:12PM +0100, Radoslaw Zielinski wrote:
> [...]
> >> 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.
> >             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Niepodoba mi się to z prostego powodu. Kernel by PLD zawiera
> > około 100 nałożonych patch-y, które potencjalnie mogą
> > ingerować także w asm,linux. Co innego gdyby glibc było kompilowane
> > na oryginalnym jajku i dostarczane nagłówki pochodziłyby z oficjalnego
> > kernela. Wtedy, _ewentualnie_ możnaby było się zastanawiać nad odpowiednimi
> > wymogami (nic nie ujmująć chłopakom od PLDzianego jajka).
> 
> Jeśli ingerują, to tym bardziej taka zależność jest uzasadniona.  Przecież
> reszta oprogramowania ma współgrać z tak właśnie kompilowanym glibcem.
Nie jest uzasadniona, ponieważ mogę chcieć korzystać z wartości dostarczanych
przez inny kernel i glibc nie ma tu nic do tego.

> Moje zmiany w glibc.spec są tylko konsekwencją przyjętego w PLD założenia,
> że glibc jest kompilowany z nagłówkami dystrybucyjnego jądra.

Nic nie upoważnia Ciebie do wysnucia takiego wniosku na tej podstawie.

[...]

> >> [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.
> > Jak już wspominałem, elastyczność ma swoje wady i zalety.
> > Tylko dlatego, że dla Ciebie jest to problem, nie znaczy,
> > że masz prawo pozbawiać mnie tej elastyczności.
> 
> Miej pretensje do RPMa, nie do mnie.
> 
> A skoro już piszesz o ,,prawach''...  Ty też nie masz prawa do narzucania
> braku pewnej zależności w imię swojego problemu z jakimś rzeźbieniem
> (o ile jedno --nodeps i dwa wywołania ln są problemem).

Problem w tym, że to _ty_ chcesz coś zrobić mniej elastycznym. Nie ja.

Proponuję usunąć zależność glibc-devel od glibc-kh i przy instalacji
glibc-devel wyświetlać komunikat o tym, że dana osoba powinna zainstalować
sobie albo kernel-headers (jeśli są tam odpowiednie linki w /usr/include)
albo glibc-kh albo ręcznie zrobić odpowiednie linki.

    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/7876663f/attachment.bin