2.2 vs 2.4 -- propozycja

[Tomasz Kłoczko]

On Sun, 22 Jul 2001, Jacek Konieczny wrote:

> On Sun, Jul 22, 2001 at 05:39:15AM +0200, Tomasz Kłoczko wrote:
> > [..]
> > > > - inne pakiety zawierajace moduly do kernela - jezeli powiedzie sie pomysl
> > > > przeniesienia tych moduloz nvidii,alsy,bttv itp itd do kernela to problem
> > > > zniknie.
> > > 
> > > Już misiek pisał, wciskanie tego w pakiet z kernelem jest bez sensu.
> > 
> > Napisał nieco inaczej. Napisałe, że zajmie dużo czasu o ile zmieni się
> > tylko np. alsa. Argument "czasowy" jest ale po drugiej stronie też jest
> > argument związany z łatwością utrzymywanai integralności zasobów i
> > nieprowokowaniem sytuiacji w których mamy na ftp pakiety do kilku wersji
> > kernela.
> 
> Pakiety z kernelem już są bardzo trudne do utrzymania, ze względu na
> olbrzymią ilość rzeczy tam władowanych. Jak się tam wrzuci wszystko co
> ma moduły do kernela, to chyba rozwój tego zostanie całkiem zachamowany.

Jacek .. nie jest trudno. Nie wypisuj takich rzeczy, bo to nie jest jednak 
prawda. Kernel jest o tyle tylko specyficzny że jego głównym elementem 
skąłdowym od stronny źródeł są patche. Jak juz raz jest to uporządkowane 
to dokąłdnia kolennych poprawek nie jest trudne. Wyglada to mniej wiecej 
tak samo jak z XFRee86. Piewszą wersja tego pakeitu była dopracowywana 
relatywnie długo. Potem było prościej.
Na pewno nie bezie tak że dołozenie alsy czy tych dwuch dodatkowych 
modułów do kupu zwiększy mocno stopień komplikacji. Popatrz na kernele w 
innych dystrybucjach. Tam p[o mimo braku czy też obecności alsy w pakeicie 
kernela główny ciężątr spoczywa na tonach patchy i choćbyś nie wiem jak 
stawał na głowie to tego ani nie unikniesz ani nie zakłócisz tym w 
twydatny spodób zgrupowaniem wszystkich modułów w jednym pakeicie 
źródłowym.

> No i na np. nową wersję alsy w RPM też się nie będziemy mogli doczekać,
> bo jest mało osób, które będą w stanie coś takiego zrobić --- już w tej
> chwili przekompilowanie kernela 2.4 mnie przerasta (kilka godzin
> kompilacji i w końcu miejsca na dysku brakuje, a mam tam kilkaset MB).

Komuś zawsze do tej pory zależało żeby to skompletować. Brak osób które 
maja odpowiednio duże doświadczenie żeby to skompletować nie ma zwiazku
wprost z zgrupowaniem całosci w jeden pakiet.
Alsa i te dwa moduły są na tyle oddzielne że npotencjalnie nie beą 
wchodzić w droge innym patchiom.

> Gdyby wszystko co się da było w osobnych pakietach wszystko byłoby
> znacznie prostrze.

Dalczego mówisz o czasie przyszłoym ? przecież w tej chwili tak mamy i nie 
jest prościej. O ile dołożysz kolejnego patchza to nioemal pewne jest że 
nei wyejdzie on w interakcje z tym co potencjalnei mozan zgrupować.
Pomyśl jeszcze trochę ..

> Przygotowanie takiego IPSEC --- chwilka: przerobic
> SPECa do ipsec, sprawdzić czy się kompiluje i działa. Gdy jest to w
> kernelu, nawet nie chce mi się w to bawić. Sama ALSA też długo się
> kompiluje, ale jak wyjdzie nowa wersja mogę sobie szybko speca
> uaktualnić (zwykle nie muszę, bo ktoś inny zdąży to zrobić). W kernelu
> pewnie długo by jakaś historyczna wersja została.

Nie kompiluje się długo. Zmiesz sobie czas. Zmierz czas kompilacji 
kernela.

> A jaki problem z utryzmaniem osobnych pakietów? Trudno puścić je
> wszystkie na builder za kernelem? 

Przecież nie chodzi o utrzymanie pakeitów źródłowych. Jeszcze nie dotarło 
do ciebie że chodzi o to żbey mieć w jednej serii wypriodukowane mozliwie 
wszystkie pakeity z binarkami mmodułów.

> IMHO najlepiej by było umieścić wersję  kernela w rel., jak ktoś już
> wspominał. To byłoby przydatne nawet przy kernelach tej samej serii.

Jeszcze raz. Dołożenie asly spowodukje wydłuzenie całosci o czas mneij 
wiecej potzrebny na skompilowanie modułów pcmcia-cs bo ilo0ść modułow i 
źródeł jest tu porównywalna. Alsa oddzielowna sprawia kłopoty bo nie przez 
to że nie wychodzi regularnie razem z kernelem wylatyje z użytku. moduł 
zdo svgsa przez byka w źródłach svglib jest generowany w tej chwili nie 
dla 2.2 tylkio dla 2.4.

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*