TAGowanie zakazane.

[Jakub Bogusz]

On Mon, May 26, 2003 at 08:49:17AM +0200, Tomasz Kłoczko wrote:
> On Sun, 25 May 2003, Paweł Gołaszewski wrote:
> > On Sat, 24 May 2003, Tomasz Kłoczko wrote:
> > > > > Oczywiście. Nie muszę tego wiedzieć żeby robić to dobrze ponieważ
> > > > > kryteria poprawności wynikają z wzgledów czysto technicznych, a nie
> > > > > z ustalenia dla kogo to jest robione.
> > > > He, he. Ciekawe jak zdefiniujesz te "wzgledy czysto techniczne" przy
> > > > sprzecznych (a w kazdym razie kolidujacych) celach... Stad, nadal
> > > > uwazam, ze pytanie _dla kogo_ nie jest bezprzedmiotowe.
> > > Zależnie od konretnych warunków danego zasoby powinno się dać to zrobić
> > > :) Wypadek z tym so wpadło w updates/security ma jednak czysto
> > > techniczne podłoże .. czyż nie ? :o)
> > 
> > Tego nadal nie rozumiem.
> > Przy twoim modelu mniej by wpadło do updates/security ??? Niby jakim 
> > cudem?? Pomijam "pomysł" z robieniem jakis_moduł-fixed, bo to nie o to 
> > chodzi.
> 
> Obecnie kernel-* są budowane z kikua pakietów.
> Po za samym kernel*src.rpm udział bierze tu jeszcze kilka czy kilkanaściw 
> w sumie innych src.rpm-ów. Z tych pozostyałych NIE SĄ budowane wyłacznei 
> modułu. Więcej .. czas budowanai modułów to tylko mały ułamek czasu 
> potzrebnego na zbodowanei tego.

W przypadku pakietów które pamiętam budowanie nie-modułów trwa krótko
(np. svgalib - moduły to może z 1-2% plików, ale całość buduje się parę
minut).
W przypadku lirca moduły to zdecydowana większość czasu.
I jest to prawie na 100% już tylko czekanie na zbudowanie, a nie na
buildlog, co tym razem się wywaliło.

Ponadto budowanie oddzielnie userspace i modułów, które nie weszły
(jeszcze nie weszły lub nie mają wejść) do waniliowego jądra może
doprowadzić do rozjechania obu części - kto po uaktualnieniu userspace
miałby zadbać o uaktuanienie kernel.spec? Liczba chętnych/mogących
pracować przy wielkim kernel.spec jest mniejsza niż przy mniejszym.

> > A przygotowanie takiego kernela-kobyły trwałoby, obawiam się, znacznie 
> > dłużej...
> 
> FIZYCZNIE nie moze trwać dłuzej.

Przy pominięciu tak nieistotnego szczegółu, jak praca dewelopera?

> x - czas potrzebny na zbudowanie wsyztkiego z kernel.spec,
> y - czas potrzebny na zbudowanie modułów kernelowych nie pochodzacych z 
>     kernel.spec
> z - czas poztrzebny na zbudowania plikacji które powstaja z kilku 
>     pakietów z których przy okazji produkowancyh jest kilka modułów.
> 
> Prosta matematyka: x+y+z nie może być mniejsze od x+y (wszytkie te 
> liczby wieksze od zera).

Czas uaktualniania łat do kernel.spec rośnie wraz z ilością/rozmiarem
łat aplikowanych w specu. Zmiana nawet jednej linii może powodować
konieczność uaktualniania co najmniej jednej łaty. Nawet jak już się
wszystko aplikuje, to nie znaczy, że od razu zbuduje się poprawnie.


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/