SPECS: glibc.spec (HEAD)

[Radoslaw Zielinski]

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.

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.  W kwestii
zmiany tego stanu zgłoś się do kogoś innego.

> A co do fantazji... to na moich komputerach mogę robić co chcę i nic
> Ci do tego.

Ty chyba po prostu nie rozumiesz tego, co ja piszę.  Może spróbuj
przeczytać jeszcze raz, co?  Bo zarzucanie mi, że przyczepiam się do
Twojej aktywności na Twoich maszynach, zwłaszcza na przykładzie tego,
co napisałem, jest absurdalne.

>> [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).


Tak żeby zakończyć tę dyskusję:

1. Czy da się zagwarantować, że pakiet (glibc-fake-kernel-headers),
udostępniający jakąś właściwość wirtualną (glibc-kernel-headers =
wersja_glibc-release) nie zostanie przypadkowo zainstalowany z zależności
zamiast właściwego (glibc-kernel-headers)?

2. Jak zbudować taki pakiet (zawierający dwa dowiązania) z glibc.spec?
Rozwiązanie djurbana z zsh.spec (tworzenie ich w %post) niespecjalnie
mi się podoba... ;->

-- 
Radosław Zieliński <radek w karnet.pl>
[ GPG key: http://radek.karnet.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/aab21c2f/attachment.bin