Ac (Re: SPECS: duke3d.spec (HEAD))

[Witold Filipczyk]

On Mon, Apr 14, 2003 at 03:26:02PM +0200, Tomasz Kłoczko wrote:
> On Mon, 14 Apr 2003, Jakub Bogusz wrote:
> [..]
> > W Ra to trwało około roku od prawie-feature-freeze...
> > Teraz pakietów jest jeszcze więcej.
> 
> Sporo może zależeć od automatyki do operowania na pakietach i zleceniach.
> Tak czy inaczej nie zamierzam dawać szerszego dostępu do tych kawałków 
> tejże o ile nie będa one przezemnie mocniej wytestowane.
> 
> Sporo zależeć będzie od automatycznego przenoszenia pakietów z ready do
> drzewka podstaowego które ma być robione automatycznie na podstawie
> wyników programu o jakim rozmawiałem już kilka razy z Pawłem Gajdą. Paweł
> nie ma najwidoczniej albo czasu albo jasnej i gotowej koncepcji na to jak
> to konkretnie zrealizować. W tej sytuacji nie za szkodzi jeżeli przypomnę
> teraz jeszcze założenia według których powininno pracować owo narzędzie.
> 
> Otóż owo narządko powinno dostawać na wesjściu ścieżki do zindeksowanych 
> katalogów drzewka podstawowego i do ready. Na tej podstawie powinno
> wypluć dwie listy:
> 
> - listę pakietów które można przenieść z ready do drzewka podstawowego po 
>   przeniesieniu których i usunięciu starszych wersji pakietów (lub ich
>   przeniesieniu do archiv) całość nadal będzie spójna,
> 
> - listę tych pakietów które przeszkadzają w drzewku podstawowym w 
>   przeniesieniu reszty zasobów z ready.

Tu jest schemat działania.

Rozpatrujemy zbiory pakietów RPM.
Dany zbiór jest spójny jeśli można go zainstalować w całości bez błędów.
Synonimem 'spójny' jest 'zamknięty ze względu na zależności'.

Wyróżniamy pakiety trzech typów:
- typ I (mainstream), pakiety niekonfliktujące z niczym, nie obsoletujące
- typ II, pakiety konfliktujące, pakiety obsoletujące
- typ III, pakiety wymagające pakietów typu II

Pakiety typu I utworzą jeden zbiór, każdy z pakietów typu II będzie należał
do innego zbioru.
Z każdym takim zbiorem skojarzymy bazę RPMa.

Dla każdego pakietu typu II lub III w oddzielnym pliku zapisujemy,
do którego zbioru należy.
Pliki typu II będą należały do jednego zbioru.
Plik typu III mogą należeć do więcej niż jednego zbioru.
Do danego zbioru należą takie pakiety, aby zbiór był spójny

(Jeżeli wśród pakietów typu III są konflikty, to mamy problem.
Mnożą się zbiory, ale schemat jest wystarczający)

Upgrade wygląda tak:
Jeśli pakiet(y) jest typu I, to:
- na kopii bazy mainstream sprawdzamy, czy pakiet się poprawnie zupgrejduje
(poldek --just db).
Jeśli tak, robimy upgrade na bazie mainstream i wrzucamy pakiety na FTP.
poldek --just db --keep.
Jeśli nie, będzie wiadomo dlaczego.
(Pakiet jest typu I, jeśli nie ma dla niego pliku z nazwami zbiorów
albo plik jest pusty w zależności od implementacji.
Plik pusty jest lepszy, bo można rozróżnić pakiety, które już są na FTP
od tych, których nie ma - brak pliku)
Oczywiście pakietem typu I może być tylko pakiet, którego wszystkie zależności
są typu I.

Jeśli pakiet jest typu II, to:
- na kopii bazy mainstream sprawdzamy, czy pakiet się zupgrejduje
Jeśli tak, to na kopii bazy do której pakiet należy sprawdzamy
czy się zupgrejduje.
Jeśli tak, to robimy upgrade na orginale.
I przerzucamy pakiety na FTP jak wyżej.

Jeśli pakiet jest typu III, to:
- sprawdzamy na kopiach bazy mainstream i wszystkich baz do których
pakiet należy, czy się zupgrejduje.
Jeśli tak, to robimy upgrade na orginałach tych baz, oczywiście poza
mainstream i wrzucamy pakiety na FTP.

Bazy RPMowe zajmują dużo miejsca, ale tak naprawdę, to nie muszą one istnieć
cały czas.  Wystarczy, że dla każdego zbioru będzie istniał plik tekstowy
ze spisem zawartości.
Test upgrade'u będzie polegał na zainstalowaniu pakietu + to co należało
wcześniej do zbioru.
Upgrade na dopisaniu pakietu do zbioru.

Instalacja == --justdb

Oczywiście można to robić ręcznie, semi-automatic albo full-automatic
w zależności od implementatora.
W każdym przypadku jest to lepsze niż to co było do tej pory.

-- 
PLD could go far, if they listen what I said ;-)
Witold Filipczyk
<witekfl w poczta.gazeta.pl>