Propozycja

[Tomasz Kłoczko]

On Mon, 21 Sep 1998, Pawel Gajda wrote:

> Witam
> 
> Mam taka propozycje, by wzorem np Debiana wprowadzic pewna zasade.
> Krotko mowiac, polegaloby to na tym, ze ktos kto zglosi sie do
> rpm-owania danego programu ,,opiekowalby sie'' nim dalej.
> Na jego e-mail zglaszane bylyby problemy, propozycje itd.

Nie może to być regółą. Ów maintaining w Debianie jest jedną z rzeczy
które zabijają jej rozwój. Jestem bardziej za modelem, w którym istnieją
osoby kontaktowe w danym temacie lub pakietach ale bynajmniej nie mogą one
być do ominięcia i nie może być wręcz nakazu zwracania się najpierw do
osoby o zawężonym polu operowania. Nie możan doprowadzić do sytuacji, w
któej ktokolwik z nas byłby osąbą kluczową.

> Takze on bylby odpowiedzialny za wypuszczanie rpm-ow z najnowszymi
> wersjami pakietu.

Ciężko. Dlaczego ? Widzisz już chyba drugi czy trzeci raz z z rzędu co
tydzień buduję wszystko od nowa i przy takim zestawieniu wyvchidzi całkiem
sporo błedów czy niedopracowań. Pakiet żeby był poprawny i solidny wymaga
przebudowania w całym środowisku.

Wczoraj zrobiłem następującą rzecz:

$ cd SRPMS; rpm -U *
$ cd ~/rpm/SPECS
$ rm -f *.spec
$ cvs update *
$ # eycja ~/.rpmrc i zmienienie pola Distribution z "PLD 0.0 (tornado)" na
# # "PLD 0.01 (tornado)"
$ rpm -ba -v *.specs -quiet

Na tym etapie wyszło wyszło mi klika błędów związanych z tym, że nie
wszystkie wcześniejsze poprawki trafiły do CVS, a także okazało się, że
kilka pakietów nie chciało się poprawnie przebudować "z kapcia".

Po tym wszystkim podpierając się:
# rpm -qa --qf "%{DISTRIBUTION}\t%{NAME}\n" | sort

Wymieniałem wszystkie pakiety na nowo przekompilowane wersje przez:

# rpm -U --force --replacefiles <pakiet>.*rpm

Po takiej podmiance .. jeszcze raz:

$ cd ~/rpm/SRPMS
$ rpm --rebuild *

I tu wyobraź sobie że wyszły jeszcze dodatkowe błędy.

Może kilaka szczegółów jakie wczoraj wyszły:

- nie można budować pakietów najnowszego gnome mając zainstalowane stare
  wersje (0.13, 0.20),
- wyszedł mi w drugim przebiegu błąd w e2fsprogs (linki /usr/lib/lib*so
  wskazywały na /tmp/e2fsprogs-1.10-7-root/lib/lib*so.*.*


> Gdyby stwierdzil, ze nie moze juz dluzej zajmowac sie tym programem,
> niezwlocznie zglaszalby to na liste i szukaloby sie nastepnego
> jelenia :-)
> Pomysl moze taki sobie, ale mysle, ze zmniejszyloby to pewne zamieszanie
> zwiazane z tym, ze nie zawsze wiadomo kto i co (i czy w ogole) robi.
> 
> Czekam na druzgocaca, ale konstruktywna krytyke :-)

Dobra to podsumowanie tylko:

* nie można narzucić odpowowiedzialności na osobę robiącą pakiet gdy część
  błędów wychodzi w pełnym środowisku w jakim wszystkie pakiety są jeszcze
  raz przebudowywane hurtem,
* osoba robiąca pakiett jest w stanie dobrze wytestować pakit o ile będzie
  wszystko kompilować w dokładnie takim samym środowisku jak inni.

Zachowanie drugiego warunku jest ciężkie technicznie. Może można by
udostępnić w jakiejś postaci (skrypt ?) procedurę podmieniającą pakiety z
ostatniego buildu (?) co może rozwiązqałoby sprawę ale taki sirodek
techniczny nie jest jeszcze w nacszej dyspozycji.
W świetle powyższego kluczową osobą staje się osoba pakująca całość
hurtem. W tej chwili takimi osobami są Wojtek (devel) i ja (stable).
Każda inna osoba, która będzie chciała potem wskoczyć na powyższe miejsca
będzie musiała zachowywać takie warunki działania jak opisałem powyżej.
Inaczej .. poprost cała robota będzie OKDR.

Jeżeli ktoś ma jakieś spostrzeżenia co do powyższego to niech się nie
krępuje.

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*