filon: SPECS rpm.spec

[Tomasz Kłoczko]

On Tue, 18 Sep 2001, Filip Kaliński wrote:
[..]
> > Po zastanowieniu sie doszedłem do wniosku, że to jednak jest do
> > cofnięcia.
> > Konsekwencją teog musiałby być zniknięcie BuidRequires dla ac/am w 
> > pozostałych specach, a te informacje sie jednak przydają cocby do 
> > oszcowania tego które pakeity po zmianach w ac/am benda narażone na to
> > ze 
> > przestana się budowac.
> > Także za kawałek już nie czakając na filona usunę te regółki.

> No trudno, mam inne zdanie, ale nie będę się już kłócił, widocznie
> taki już los biednych ac/am

Zastanów się jeszcze raz nad tym. Obecność tych informacji w specach 
przyda się. Ergo: nie należy prowokowaźć sytuacjai w których możnaby 
pomijać tego typu zależności.
To wynika wyłacznie z tego. W pierwszym momencie byłem niemal pewien, że 
ta amian była w złym kierunku ale nie potrafiłem nawet sobie sam tego 
uzasadnić było to tylko wewnętrzne/podświadome przekonanie o 
niepoprawnosci) i dlatego nie posłąłem tej zmainy od razu do 
pzrebudowania. Po kilku dniach byłem w stnie wyartykułować konkretny 
argument przeciw który IMHO wystarcza żeby obiektywnie zblokować tego typu 
zmianę tak żeby inni (w tym takze i Ty :) nie mieli wątpliwości co do 
takeigo kroku. Zastanów się nad tym a zapewne dojdziesz do podonbnego 
wniosku :)
Jeszcze raz (jak to przy tego typu zmianach zwkle bywa) to nie jest próba
wytkniecia błędu komuś (Tobie) tylko blokada pewnego kierunku zmian w
wyniku przemyślenia dokąd to może prowadzić. Czyli nie traktuj tego 
osobiście (kazdy może się mylić czy też mieć chwile w których wpada na coś 
co nie było dobrze przemyślane a co w pierwszej chwili na takowe wyglądało 
:)
Poprostu trzeba się zastanawiać nie tylko nad doraźnymi konsekwencjami ale
także tymi długofalowymi. Obecność kompletnych i w miarę jednoznacznych 
regół BuildRequires to jest cos co my dostzregliśmy jako pierwsi jako 
pozytywny efekt. Dzisiaj dokłądnie do tych samych wniosków fochodza ludzie 
z MDK i RH. To tylko potwierdza, że jest to poprawny kierunek. Kwestia 
tylko w tym że my jesteśmy dość rygorystycznie i na dłuższa metę mamy w 
związku z tym lepsze szanse utrzymania zasobów w dobrej (lepszej niz inni)
kondycji.

Apropo podpatrywania :)
snie zajrzałem sobie do mkinitrd z rawhide. "Wpadli" na ten sam pomysł co 
my z bsp [1] (tam to się nazywa nash) ale "niestety" nie poszli dalej w 
kierunku pełnej modularyzacji kernela. Swoja droga w modyfikacji z CNV do 
mkinitrd jest komplet modyfikacji do LVM (chyab tego nie mamy :) i 
mozanby to zaadaptować do geninitrd.

Tak czy inaczje. Przyglądają się nam .. w tym sensie nie powinniśmy mieć
już żadnych skrupułów w importowaniu różnych goodies od innych.
Kwestia tylko w tym że potenacjalnie trzeba będzie zwrócić w dłuższej
perspektywie wiekszą uwagę na koordynowanie analizowania tego co 
wprowadzaja inni.

[1] właśnie zauważyłem że stało się mniej więcej po liście wigeta i moim
na k-l opisujacym bootowanie z "gołego" kernela i initrd z użyciem bsp ..
przypadek ? :)

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*