kloczek: SPECS XFree86.spec

[Tomasz Kłoczko]

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

> Sat, 20 May 2000 16:23:45 +0200 (CEST), Tomasz Kłoczko <kloczek w rudy.mif.pg.gda.pl> pisze:
> 
> > Rozwiazanie ze sprawdzaniem w %prep obecnosci odpowiednicj plików
> > nagłówkowych jest IMHO do przyjęcia ale nie moze być jedoczesnie do
> > przyjęcia to, że w zaleznosci od tego czy te pliki są czy nie to
> > np. włacza sie automatycznie łatanie na agp czy nie, bo to byłoby już w
> > sprzecznosci z założeniem początkowym którego trzymanie sie IMHO jest
> > jednak rozsądne, bo lepiej być o czymś ostzeżonym, że coś będzie nie tak
> 
> Mam instalować łatę AGP na jądro, której nic nie będzie używać,
> tylko po to żeby skompilować Xy, które też nie będą u mnie używać AGP?
> Bez sensu.

To nie jest bez sensu. Zauważ, że pakietów takich o tak wygórowanych
żądaniach jest kilka na kilka tysiecy.

> RPMowi przydałby się jakiś mechanizm alternatywnych konfiguracji
> jednego pakietu źródłowego. Niech to ma odzwierciedlenie w wersji
> pakietu binarnego, wszystko jedno - założenie jedynie słusznej
> konfiguracji nie zawsze się sprawdza.

Marcin przecież to wszystko zależy nie od rpm-a który ma takie anie inne
własności i tóre dopieoro w otoczeniu konkretnych regół pakowania okazują
się _dopiero_ wadami bądź zaletami. W oderwaniu od ych reguł są to tylko
cechy.

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.

To co mówisz mówisz przedewszystkim z włąsnego punktu widzenia, a
co więcej mówisz to dlatego bo coś Ci nie pasuje ale też jestem
niemal przekonany o tym, że nie do końca przeaalizwoałeś ten konkretny
przypadk.

Jeżeli chcesz żeby ten punk podzielali inni to możesz próbować to forsować
o ile jego przyjęcie bedzie dla innych także korzystne. XF nie jest
pakietem małym .. jest wręcz jednym z największych pakietów. Zwykle też
najbariej połatanym i jednocześnie generujacym sporą ilość podpakietów
izależnosści. W takij sytuacji która jest wyjątkowa ciężko nie otrzeć się
o coś co będzie kłopotliwe i prawie pewne jest to, że idealnego
rozwiażanai można nie znależć. W takeij sytuacji trzeba ważyć w rękach to
co ma wady i co am tych wad wiecej.

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

> Kiedy kompilowałem PHP3, musiałem mnóstwo rzeczy wyłączać, bo nie będę
> instalował fafnastu baz danych tylko po to, żeby skompilować PHP3
> i używać go wyłącznie z Oraclem.

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.

> Nie pasuje do założeń RPMa? Zmienić założenia RPMa, a nie dostosowywać
> rzeczywistości do nieodpowiednich założeń.

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 ?

Druga sprawa. Zapominasz, że każde uogólnienie ma swoje granice. W
sytuacji szykowania systemu pod klucz do specjalnych poruczeń ilość
zasobów szykoanych _specjalnie_ na taką maszynkę i nie mających w zasadzie
zastosowań na innych systemach będzie wprost proporcjonalna do
nietypowości założeń jakie będziesz kompletował w trakcie szykowania
systemu.

Jeszcze inaczej. Wiele apliakcji w tej chwili potrafi korzystać z baz
danych łącząc sie z jednym z typowych motorów baz danych. Żeby nie
rozdymać samych binarek żeby wspierały wszystko co się da wymyślono moduły
które są zależne od bibliotek służących do komunikacji z konkretnym typem
mortora bazy. I to jest wspaniałe bo mając tak zmodularyzowana aplikację
jestem w trakcie kompletowanai systemu o dość szetrokiej palecie możliwych
końcowych włąsnosći optymalnie dobrać to co ma być zaiinstalowane bez
rekompilacji która np. Tobie nie powinna sprawić kłopotu ale jednocześnie
będzie na pewno dłużej trwała niż proste dobranie zestawu pakietów.

Kiedy zasób istnieje i jest on prawidłowo przyszykowany to koniczność
rekompilacji pojawia sie tylko w dwuch przypadkach: błąd w pakiecie i gdy
wychodzi nowa werasja źrodeł. We wszystkich innych przypadkach
kompilowanie wszyskiego z palca i to nawet podpierajac sie rpm-em i specem
do pakietu jest często stratą czasu o ile pakiet jest poprawnie
zaprojektowany co do formy jaką otrzymuje w pkietach wynikowych.

To wsyztko to są prewne konsekwencje kompromisów. Kompromisów które nawet
dla użytkownika takiego jak Ty powinny być do przyjęcia. Zauważ, że
ściagasz zasób modemem. Ale sciągnięcie nowych źródeł (czyli w jednej z
dwuch sytuaji kiedy jest konicznosć rekompilacja) będzie bardzie kosztowne
niż dociągnięcie pakietu X serwera i kilku dodatkowych z bibliotekami i
innymi rezeczami (mowa przez cały czas o XF). W sytuacji kiedy jest bład,
a masz maszynkę w domu poczekanie jeden dzień na to ąz nowe Xy się
przekompilują na builderach po to żebyś mógła zassać kompilaty nie będzie
dla Ciebie gardłowe, a i będzie też mniej pracochłonne.
Powyższa sytuaja na pewno nbardzo dobrze pasuje do XF. W przypadku małych
pakietów choćby dla sporyu warto sobie coś pokompilować (po to żeby nie
wyjść z wprawy :) ale też i w tej całej masie pozostałych pakietów to co
ma miejsce przy XFree86, util-linux, e2fsprogs czy moze jeszcze kilku
innych _wogóle_ nie będzie maiło miesca. W sytuacji kiedy jeden z tych
kilku newralgicznych pakietów rzeczywiście bedzie potzrebny w formie
tworzonej we=dług innych założeń zawsze masz dosep do źródłowej postaci i
tu możesz robić co Ci tylko przjdzie do głowy.

Jeszcze raz. To co teraz wyszło na jaw nie dotyczy większości pakietów
tylko niewielkiego ich zbioru (ułamka pojedynczego procenta) więc nie ma
sensu naginać za bardzo ogólnych założeń tylko po to żeby mieć super
reguły na szysktkie pakiety bo za kawałek jeszcze się okaże się że
jesteśmy w potrasku tych regół (i to na wąłsne życzenie niejako), a po
drugie w tym akuta przypadku też za dużo nie masz do stracenia. I
potrzecie jezeli coś ma się zmienić to pamiętaj że tylko pod wpływem
argumentów a nie dla samego zmieniania. Kwestia tylko w tym, że jak na
razie po to żeby mieć w pakiety wynikowe pewnych własnościach mamy w
tej chwili dwa alternatywne rozwiazania które są w miarę rozsądne
z których i tak żadne nie jest idealne.

W takim razie pozostaje pytanie czy znasz jakieś rosadne trzecie wyjście ?
Czy jesteś w stanie choć nakreślić kształt takiego rozwiazania po to żeby
dalej można było sensowanie prowadzić dyskusję ?

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/