SPECS: glibc.spec (HEAD)

[Radoslaw Zielinski]

Tomasz Trojanowski <tomek w uninet.com.pl> [08-01-2003 09:52]:
> On Wed, 8 Jan 2003, Radoslaw Zielinski wrote:
>> Ja sobie z większością rzeczy, prędzej czy później, poradzę.  Ale
>> propaguję Linuksa i PLD wśród ludzi, którzy sobie (jeszcze) nie radzą.
> No i tu napiszę trochę o założeniach. Otóż podstawowym i najważniejszym 
> założeniem PLD, jest robienie dobrze sobie. Robi je grupa ludzi którzy tej
> dystrybucji używają w pracy, w domu, w szkole... gdziekolwiek. I cokolwiek 
> robią, robią to (a przynajmniej w założeniach - powinni) dla siebie, bo 
> akurat czegoś potrzebują. 

Po pierwsze: to założenie jest bardzo ładne, zdrowe i wogóle.  Ale IMHO
nie należy go traktować zbyt dosłownie.  W przeciwnym razie nigdy nie
powstałby np. instalator, prawda?

Po drugie: upraszczając tego typu rzeczy (do poziomu, w którym może
poradzić sobie początkujący użytkownik), ja robię dobrze sobie.  To po
prostu leży w moim interesie.

[...]
>> Instalacja okazała się nieco bardziej skomplikowana, niż rpm -U:
>> wcześniej zainstalowany był alsa-driver-devel, który wrzuca swoje *.h do
>> /usr/include/linux/.  ,,Dlaczego "nie można utworzyć pliku: (...) jest
>> katalogiem"?''
> Znowu o założeniach. Nie można zakładać, że PLD musi być zrobione tak, 
> żeby mógł go używać każdy, bez jakiejkolwiek wiedzy o zasadach na jakich 

Nooo, akurat wymagania, żeby pakiety nie instalowały plików w różne
miejsca (w tym zupełnie przypadkowe, jak /usr/src/linux/) w zależności
od tego, co aktualnie jest zainstalowane nie nazwałbym ,,robieniem tak,
żeby mógł używać każdy''.

>>>> 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.
>>> Kolejna bzdura. To nie jest żadne założenie, tylko fakt wynikajacy z
>>> przyjetego sposobu budowania pakietów. Natomiast przyjetym jest
>> Czyli co, przypadek?
> Nie, raczej nie przypadek. Otóż fakt, że glibc jest kompilowany na 
> builderach w otoczeniu jądra dytrybucyjnego, wynika z właściwości procesu 
> budowania. Muszą być jakieś nagłówki, więc dlaczego nie dystrybucyjne.

Ty to nazywasz ,,właściwości procesu budowania'', ja -- założenie
(skoro zostało to zrobione świadomie).

> Tyle o builderach, natomiast gdziekolwiek indziej nie zakłada się że glibc
> jest kompilowany (czy też *skompilowany*) w otoczeniu nagłówków 
> dystrybucyjnych. A wprowadzenie takiego założenia człowiekowi który i tak 
> ma problemy z podstawowymi rzeczami na pewno nie pomoże, a innym tylko 
> utrudni pracę, chociażby przez zmuszanie go do rozwalanie bazy zalezności 
> przez stosowanie "--nodeps".

Chyba nie nadążam.  Przecież już od -r1.258 nie ma zależności od kernela
dystrybucyjnego.  Owszem, jest BR na bcondzie -- BR dla zapominalskich,
nie wiedzących o takiej zależności i automatów, oraz aby wyeliminować
przypadki, a bcond dla tych, którzy wiedzą, co robią.

Nie ma potrzeby stosowania --nodeps; po zmianie, którą wykonał wrobell
już w żadnym przypadku.  (Chociaż nadal uważam, że R: g-d=>g-k-h powinna
istnieć.)

>>>> 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).
>>> Ditto. rpm -U kernel-headers jest jeszcze mniejszym problemem.
>> Na pewno czytałeś ten wątek?  Zawartość pakietu kernel-headers może
>> nijak mieć się do nagłówków, potrzebnych przy aktualnym budowaniu
>> czegokolwiek.
> Whatever. Mogłem napisać rpm -U coś-tam-coś-tam

To ja już nie wiem, o co Ci chodzi (jeśli coś-tam-coś-tam == g-k-h).
Nadal uważasz, że powinienem wycofać wszystkie zmiany?

[...]
> Dlatego, moja rada na przyszłość, *zawsze* zakładaj, szeroko pojętą,
> dobrą wolę współdyskutanta.

Nie skorzystam.  Wolę zakładać, że to, co ktoś pisze, jest przemyślane.
I że jeśli ja jestem w stanie opanować się nawet, gdy po 21:00 skończą
mi się papierosy, to inni też mogą.

-- 
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/9d3fee1e/attachment.bin