Budowanie zale?nych od siebie pakiet?w

[Tomasz Kłoczko]

On Tue, 24 Jul 2001, Paweł Sakowski wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > O ile jakaś poprawka dotyka plików nagłówkowych to tego typu zmiana będzie 
> > dotyczyć reszty pakietów. W kupie czy nie tego typu szczegóły wyjdą i ta. 
> > O ile wyjdą to sumaryczyny czas budowania pakietów bezie niewiele wiekszy 
> > niż dla całosći.
> 
> Czas ten się praktycznie nie zmieni, pod warunkiem, że megajądrem
> zajmowałaby się jedna osoba. A tak czas trzeba będzie pomnożyć przez
> liczbę osób pracujących nad aktualizacją -- bo zamiast tego, że osoba #1
> dwa razy przekompiluje jądro, osoba #2 svgaliba, etc, wszyscy będą
> kompilować wszystko.

Nie robiłeś jeszcze nic przy kernelu to mozesz nie wiedzieć, (więc 
powttórzę po raz kolejny), że RAZ WPROWADZAONA POPRAWKA NIE 
WCHODZI W INTERAKCJE Z NOWYMI MODYFIKACJAMI. Jeżeli już to ktoś kto dodaje 
nowego patcha jest zobowiazany nanieść to tak żeby nowy kawałek nakładał 
sie beż bulu. Tak było dotad i nie widże żeby to miało się w jakiś sposób 
zmienić. Co do praktyki .. to zajmować się beą tym dokładnie Ci którym 
będzie na tym zależeć (nie mniej ni więcej). Pakiet kernela jest sam w 
sobie trudny i skomplikowany. Niemniej to co można by z nim dodatkowo 
zgrupować w sposób radykalny wyżej tej poprzeczki jzu nie podnosi.
Dużo bardziej podniesie się popzreczka z tytułu przejścia 2.2 -> 2.4 niż z 
tytułu dołozenie (czy w starej czy w nowej wersji) reszty modułowych 
zasobów.

Tak czy inaczje z racji tego, że ALSA i lirc są stosunkowo autonomiczne
(nie budują się w drzewku źródeł kernela .. mają swoje własne, a moduł do 
masq wymaga jednolinkowej poprawki do Makefile i zapewne tak samo będzie 
z svga) dorzucenie tego co mamy po za kernelem obecnie NIESPOWODUJE 
zwiekszenia trudności nakładanai kolejnych poprawek.
Może teraz dotrze do wsdzystkich coś co disiaj (po dniu odpoczynku) widże 
i jestem w stanie opisywaćbardziej jednoznacznie).

I jeszcze jedno. Ja już swoje racje wyłożyłem. Prosze nie dyskutować ze
mna czy łapać mnie za słowa, czy z tym co już napisałem dzisiaj. Jeżeli
ktoś coś chchce wnieść coś nowego to tylko w postaci KONKRETNEJ PROPOZYCJI
rozwiązania. W pzreciwnym wypadku bedziemy dreprtać w miejscu szarpiąc się 
nawzajem. Nie twierdże, że pomysł zgrupowania zasobów modułow kernela 
jest jedyny czy też doskonały ale jak na razie nie ma niczego co byłoby w 
obecnej chwili równie proste i kompletne.

[..]
> > i niemal jestem peien tego że jeżeli raz dołożyłbyś patcha do kernela na 
> > moduł od lirc to juz byś sie wiecej tego nie dotykał.
> 
> Ja takim optymistą bym nie był. Sam pisałeś, że interfejs się
> zmienia.

Masz rację. W miezyczasie przyjrzałem się dokłądniej lircowi i po za 
stwierdzniem że pakeit w tej chwili nie nadaje się do kompilacji na 2.2 
(%files nie jest jszcze dostosowane .. ale to mały szczegół) stwierdzięłm 
że jest on równie autonomiczny jak alsa.
W przypadku tak autonomicznych zasobów nie ma sensu dążyć do pełnej 
integracji ze źródłami kernela (wykonaja to przędzej czy później 
mainteinerzy tych zasobów) ale nadal jest IMHO sens zgrupowanai tego przy 
budowaniu.

Proponuję jeszcze raz żebyśmy sie wspólnie nad tym zatanowili.
Jeszcze raz kernel nie jest łątwym zasobem. Ma on wysoki samoistny poziom 
trudności. Jest do tego zasoben niezmiernie ważnym dla dystrybucji jako 
całosci. Nie chcę sie upierać przy tym czy innym rozwiazaniu ale o ile nie 
przynajmnei jna razie nei znajdziemy innego lepszego rozwiazania mozę sie 
okazać, że nie tylko ja zacznę oprtować za zgrupowanie tego w jedną 
paczkę. Prosze mi wierzyć też mi sie to nie do końca podoba ale podchodże 
do tego pragmatycnie .. nie widze w tej chwili innego lepszego 
rozwiazania. Moze ktoś je za kawałek wymyśli (obu) i uratuje dzięki temu 
choć niejako estetyczne kwestie tego co musimy tak czy inaczje rozwiązać.

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*