kloczek: SPECS XFree86.spec

Nie, 21 Maj 2000, 12:38:48 CEST

On 21 May 2000, Marcin 'Qrczak' Kowalczyk wrote:

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

Jakoś tego nie widzę. Na pewno nie ma to miejsce w przypadku XF. Skupiasz
sie na jakimś ogólnym prezypadku gdy tymczasem XF i powiazanie z połatanym
kernelem na etapie (tylko) budowania jest wyjątkiem.

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

No to w tym wypadku czeka Ci w przypadku ściagania źródeł po pierwsze dwa
razy dłuzesze ciągnięcie. Po drugie jeżeli juz chcesz to mozesz ściagnać
dodatkowo patcha do agpart, który ma parędziesiąt KB.

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

Przez cały czas odnoszę wrażenie, że nie mówisz o XF.

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

Tylko kierunek tych zależności jest inny. Otóż od XF jest zależnych dużo
pakiewtów i to nie chodzi o zależność od X serwera co od bibliotek. Samo
XF jest zależne od małej ilości rzeczy w tym i na etapie budowania także.
To czy użyjesz libów z wersji XF 3.3.5, 3.3.6 czy 4.0 to prawie jest
obojętne. Tu się od dłuższego czasu mało co zmienia.

> > 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ć.

Co to za pakiety i jakiego typu są to zmiany ?
Moze to jest coś co powinno się naleźć w ogólnie używanych pakietach ?

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

Na razie Oracle nie mam pod łapą i chyba mało kto ma to. Możemy założyć,
że z tego powodu już tylko backendy do O nie bedą za często budowane (może
nawet wcale).

> 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ć.

Marcin piszesz o tym co wolisz. A co to ma do rzeczy ? Mnie interesuje co
masz do powiedzenia w sprawie kilku pakietów których budowanie zależne od
połatanej wersji kernela. Odnosze wrażenie, że jednak nie przyjrzałeś sie
tym przypadkowi ani temu co już napisałem na tyle wnikliwie skoro jeszcze
masz jakeiś wątpliwości. Piszesz przez cały czas o czymś zupełmnie innym.

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

Odpada. Kompilacja pakietu jest procesem kompletnie nieinteraktywnym.
Ustalać to się ustala ale na etapie pisania speca. Wydawało mi się, że kto
jak ko ale Ty powinieneś to już wiedzieć.

[..]
> Trywialny przykład zastosowania: nie chcę generować dokumentacji,
> bo sgml-tools i pasującego do nich TeXa mam w proszku.

TeX jakiego mamy jest raczej w porządku.

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

Nadal nic ciekawegio nie zaprponowałeś w odniesieniu do powiązań plików
nagłówkowych kernela i tych kilku pakietów. Nadal siedzimy tylko w kręgu
tych dwuch możliwości jakie już były opisane.

Nadal nie zauważasz tego, że mowa o zależnościach przy budowaniu. nadal
nie zauważasz że powstała dodatkowa zależność od konktretnego połatanego
kernela. Nadal nie zauważasz wreszcie tego, że pakeity binarne XF są dużo
mniejsze niż źródła. Nadal niezauważasz tego że niezależnie od tego czy XF
bedzie miało wsparcie do agpart to kompilatów X serwera SVGA będą mogli
używać chyba wszyscy nie zauważając tej dodatkowej zalezności.

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

XFree86, kernel i tych kilka pakietów pod powyższe niepodpada. Marcin do
jasnej zejdź na Ziemie i zacznij rozmowę na temat. Albo skończmy ten
wątek.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*

___________________________
polish  linux  distribution
-> http://lists.pld.org.pl/