kloczek: SPECS XFree86.spec

[Marcin 'Qrczak' Kowalczyk]

Sat, 20 May 2000 22:24:21 +0200 (CEST), Tomasz Kłoczko <kloczek w rudy.mif.pg.gda.pl> pisze:

> Moi zdaniem to dobrzę, że jeżeli wiem według jakich załozeń pakiety są
> tworzone i że są one takie a nie inne, bo jeżeli widze jaką wetrsję
> pakiewtu mamm przed nosem to ma ona takie, a nie inne własności.

Tego dokładnie i tak nie wiadomo: binarny pakiet A w wersji 1.1
kompilowany z biblioteką B w wersji 2.2 różni się od pakietu A
w wersji 1.1 kompilowanego z biblioteką B w wersji 3.3.

Nie zawsze mamy całą dystrybucję pod ręką, żeby zainstalować razem
wszystkie pakiety, które do siebie pasują. Ja na przykład łączę
się przez modem i instaluję pakiety pojedynczo; ważne żeby pakiet
kompilował się nie tylko w określonym środowisku. Co ma tę zaletę
dla samego PLD, że więcej zależnych pakietów pozostanie poprawnych
kiedy środowisko PLD wyewoluuje.

Bardzo dobrze, że RPM umożliwia określanie zależności, ale jeszcze
lepiej, kiedy dana zależność nie jest potrzebna.

> XF nie jest pakietem małym .. jest wręcz jednym z największych
> pakietów.

Właśnie dlatego bardzo nie na rękę mi są rozbudowane zależności
XFree od innych rzeczy. Ściągnięcie XFree kosztuje, niewygodnie być
zmuszonym do przekompilowania XFree kiedy coś, od czego XFree zależy,
się zmieniło - po czym okazuje się, że w międzyczasie środowisko tak
bardzo się zmieniło, że dana wersja XFree zupełnie się nie kompiluje
z innych powodów.

> Zawsze możesz mieć dwie wersje speca lub wziąć podstawową po to żeby
> wykomentować sobie jedną czy dwie linijki (cały spec przecież na w tej
> chwili podnad 70KB tekstu).

I tak właśnie robię; w tej chwili mam zainstalowane 34 pakiety, które
oznaczyłem sobie literą "q" w Release, czyli że musiałem coś zmieniać.

Czasem nie potrafię dojść, jak coś dostosować, i daję spokój
kłopotliwemu pakietowi, który nie jest mi bardzo potrzebny.

Im więcej sytuacji, kiedy nie trzeba tego robić i pakiet sam się
dostosowuje do środowiska - albo kiedy można go dostosować do
środowiska bez grzebania w specu - tym lepiej.

> Kolejny przypadek. Nie zauważasz, że użytkową wartość ma dopier
> kompilat. Ten jeżeli dobrze został zaprojektowany i zmodularyzowany
> typowo nie będzie wogóle wymagał rekompilacji.

O ile mamy te same wersje bibliotek, z których to korzysta.

Biblioteki Oracla miałem bardzo mocno łatane z powodu niezgodności
z glibcem-2.1 (z podmianą odwołań do glibca w nich na glibca-2.0).
Różnie to bywa.

Poza tym to nie pomaga. Jeśli libphp3 jest linkowane z dziesięcioma
bazami danych, to pewnie wymaga ich istnienia do uruchomienia, nawet
jeśli ich w danej chwili nie używa (nie wiem, jak akurat php3, może
używa ldopen, ale tak jest zazwyczaj; jeśli nie php3 to coś innego).

Poza tym wolę ściągnąć źródło, które później przekompiluję z nowym
glibcem / nowym kompilatorem / z optymalizacją na nowy procesor, albo
do którego ściągnę nowsze łaty i speca pozostawiając tar.gz bez zmian,
albo w którym coś poprawię żeby było kompatybilne z nowym środowiskiem,
niż binarkę z którą nic takiego nie można zrobić.

Kiedyś ściągałem głównie binarki, a potem cierpiałem kiedy nie mogłem
przekompilować z inną wersją biblioteki. Teraz ściągam głównie źródła,
a binarki tylko kiedy nie uda mi się skompilować źródeł.

> OK .. na jakie ? Widzisz jakieś rozwiazanie które byłoby do przyjęcie
> w odniesieniu do zasobów które mogłby być potem używane więcej niż
> na pojedynczej maszynce ?

IMHO wystarczyłoby, żeby w czasie kompilacji RPMa można było ustalać
parametry zależne od pakietu; domyślne wartości dają to co mamy teraz.
Tak żeby dla N kombinacji przełączników nie musiało istnieć 2^N
pakietów z powielonymi tymi samymi źródłami, ani żeby nie narzucać
jedynie słusznej konfiguracji.

Trywialny przykład zastosowania: nie chcę generować dokumentacji,
bo sgml-tools i pasującego do nich TeXa mam w proszku. Albo program
przychodzi z graficznym konfiguratorem, a człowiek nie ma Xów
i nie potrzebuje konfiguratora.

Pewnie da się to lepiej zaprojektować; nie wymyśliłem, jak konkretnie.
W każdym razie nie zgadzam się, że jest bardzo dobrze i nie trzeba
zastanawiać się nad zmianami.

Pakiety w tar.gz mają zwykle mnóstwo opcji w ./configure. RPM
znakomicie ułatwia ustalenie sensownej propozycji, ale przy okazji
uniemożliwia wszelki wybór.

-- 
 __("<    Marcin Kowalczyk * qrczak w knm.org.pl http://qrczak.ids.net.pl/
 \__/              GCS/M d- s+:-- a23 C+++$ UL++>++++$ P+++ L++>++++$ E-
  ^^                  W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK                  5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-