Budowanie zale?nych od siebie pakiet?w

[Paweł Sakowski]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Zauważyłem takze, że już choćby Ty nie
> zauważasz tego, że po takiej zmianie bałagan z niespójnością zasobów
> modułów zniknie raz na zawsze.

Podobnie znikną ltmodem i lirc. Bo ja będę musiał rzucić to w cholerę

> > No i zastanów się chwilkę.... czy tu jest tylko jedna osoba które umie
> > logicznie myśleć?
> 
> Zauwazam to. Żauważam takze to że podczas tego myślenia łatwo przecjhodzi 
> się do porżadku nad tym co wymieniam (ergo: jest to logiczna jak 
> najbardziej analiza faktów ale w zakresie neikompletnym).

No to przejdźmy na fakty. Jakie problemy stwarza rozbicie jądra i modułów
na kilka pakietów? Słownie jeden: zdarza się, że zasoby się
rozsynchronizują przez przebudowanie jądra a modułów nie. Rozwiązania są
dwa: łączenie speców lub zautomatyzowanie przebudowy modułów po jądrze. To
drugie już było proponowane, i to w bardzo konkretnej formie; są osoby
chętne, żeby to zrobić. Owszem, twoje rozwiązanie jest prostsze i szybsze,
ale ma też poważne wady: Każdy, kto będzie chciał coś robić przy modułach,
musi się uzbroić w duużo cierpliwości i miejsca na dysku. Doświadczenie
uczy, że próbując coś poprawić w specu robi się ok. 5 przebudowań. Mnożąc
to przez jakieś 6 godzin (strzelam, bo się nigdy nie doczekałem) budowy
jądra dostajemy 30 godzin, czyli trzy dni z życia normalnego
człowieka. Spędzisz tyle z nową wersją ltmodem? Bo ja nie. Zatem efektem
ubocznym takiego postępowania byłoby postępujące zamrażanie dystrybucji --
przynajmniej w przypadku utrzymywanych przeze mnie lirca i ltmodema, do
których po włączeniu w jądro już bym się nie dotykał.

> Po drugie nie jest to moja idea. Jest to *czyste rozwiniecie* tego co 
> Janek kiedyś zrobił i co *do dzisiaj się dobrze sprawsdza*

I następnym krokiem byłoby pewnie zintegrowanie glibca (też zależy od
wersji jądra)? W pewnym momencie trzeba przestać i ten moment już
nastąpił.

> Mam też namacalne skutki tego że brak tego podejhścia
> skutkuje tym że mamy te zasoby rozjechane, a przy przejściu na 2.2.19 
> sporo czasu alsa nie była także zaktualizowana (nawet nikomu nie 
> chciało się podbić rel pakietu żeby zasygnalizować że przebudowanie 
> jest potrzebne).

Daj mi dostęp do builderów, a za tydzień będziesz miał gwarancję, że to
się nie powtórzy i za jądrem będzie przebudowywane wszystko, co tego
wymaga. I to bez utrudniania życia ludziom od modułów.

> Błędem moim było w tym wypadku to że wciągnąłem się w dyskusję publicznie.
> Powinienem to skonsultować z przykładowo Jankiem i Arturem (czyli 
> osobami które wiedzą sporo o zasobach których dotyczy sprawa bo same
> brały aktywny udział w ich preparowaniu czyli kernel i alsa) i co
> najwyżej tylko te osoby przekonywać. W sytuacji kiedy miałbym 
> dgotową poprawke (której sporządzenie zajełoby mi mniej czasu niż ta cała
> dyskusja) przekonywać mógłbym żywym zasobem (byłoby to juz bardzo łatwe).

Oj, tylko proszę bez takich machiavellizmów. Z tego, co pamiętam to tą
dystrybucję robimy zbiorowo. Stawianie ludzi przed faktem dokonanym
(czyt. uzurpacja) raczej nie pasuje do takiego modelu pracy. Mimo, że
jesteś osobą najintensywniej się tu udzielającą.

+--------------------------------------------------------------------+
|   In God we trust. All others must   :            Paweł Sakowski   |
|  present a valid X.500 certificate.  :   <pawel w sakowski.eu.org>   |
+--------------------------------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
Filter: gpg4pine 4.2 (http://azzie.robotics.net)

iD8DBQE7XJqgNJmavqlTkb0RAub7AKDv9tvdXvfS2CKREAkfI+610OF1SgCgnQkA
1kajnQWZthuIubqyjNYOwYI=
=pig0
-----END PGP SIGNATURE-----