STABLE - podstawy (100 linii)

[Witold Filipczyk]

Witajcie,
Jest parę spraw które trzeba by ustalić, ale wcześniej należy ustalić kto i jak ma je ustalać.
Proponuję system (ustalania) demokratyczny, wiem, że nie jest to doskonałe, ale jest to metoda
którą znamy w miarę dobrze.
A więc najpierw są zgłaszane "kandydatury".
Później w drodze głosowania wybiera się jedną z nich.
Najlepiej będzie chyba gdy będzie to zrobione za pomocą formularza www i jakiegoś skryptu CGI.
Pierwszy, który się zgłosi do zrealizowania tego będzie też liczył głosy. 


Po pierwsze trzeba ustalić kiedy ma zostać wypuszczona wersja 1.0 STABLE.
Bez określenia tego terminu praca będzie się wlokła i daleko nie zajedziemy.
Zresztą chyba każdy student wie kiedy się kończy sesja egzaminacyjna.
 

Pytanie1:Kiedy ma być wersja STABLE?
--------

Proponuję termin w okolicach Computer EXPO.  (Lepsza wersja w okolicach Cebit-u).


Co to w ogóle znaczy STABLE?
Ile ma być płytek z binarkami?
Ile ma być płytek ze źródłami?
Jakie platformy?

Jakie są założenia, jakie wymagania?

Wydaje mi się, że płytki z binarkami powinny być przynajmniej dwie wypełnione po brzegi.

Pytanie2: max 650MB czy 700MB na płytce?
--------

Jak już niejednokrotnie pisałem jestem za posortowaniem (uporządkowaniem) qsort-em zasobów.
To znaczy z każdym pakietem trzeba stowarzyszyć liczbę naturalną, tak żeby można było
pakiety ustawić w kolejności instalowania.
Na pierwszą płytkę pakujemy tyle pakietów ile się zmieści, tzn.

`du (1..n)` <= max && `du (1..n+1)` > max

Jeśli pakiety na płytce będą wypalane w takiej kolejności to osiągniemy dodatkowo wzrost szybkości
instalowania (skrócenie czsu).

Z .SRPMS-ami to raczej według alfabetu (nie łamiemy płytek między literami).

Funkcja compar dla qsort-a powinna wyglądać mniej więcej tak:

int commpar(a,b) {
	if (a zależy_od b) return 1;
	if (b zależy_od a) return -1;
	if (a jest_bardziej_przydatny_fajniejszy_ładniejszy_od b) return -1;
	return 1;
} 

Oczywiście jeśli kilka pakietów jest od siebie wzajemnie zależnych powinny mieć w powyższej
funkcji jednego reprezentanta.

O tym który jest bardziej przydatny, fajniejszy, ładniejszy też powinna zdecydować jakaś ankieta.

Przypomnę tylko, że gdy już będzie taka prosta "baza danych" z numerami i zależnościami
instalacja (a nawet update) będzie szybka, prosta i przyjemna.  Przy całym szacunku dla poldka
taka baza będzie też zajmowała dużo mniej miejsca na CD (FTP) i będzie zawierała wystarczająco dużo
informacji potrzebnej do instalacji.


Powtórzę się jeszcze raz: Z każdym katalogiem na FTPie na gałęzi STABLE powinna być skojarzona
baza RPMa, tzn. wrzucanie plików na FTP wiązało by się z uaktualnieniem bazy RPM i tej mniejszej
"z numerami i zależnościami".  Oczywiście powinno to się odbywać na zasadzie transakcji, czyli
instalujemy paczkami,  --nodeps nie wchodzi w grę.  W razie wykrycia poważnego błędu
"odinstalowywało" by się całe paczki (paczka - jeden lub więcej pakietów).

Tak w ogóle nie widzę przeciwskazań, żeby minimalnymi wymaganiami dla instalatora było:
4MB RAM bez swapu.

Prawdopodobnie wymagało by to trochę sztucznych podziałów niektórych pakietów .rpm ,np.
kernel-source, na części np. kernel-source-part1 kernel-source-part2.  Oczywiście poszczególne
częśći wzajemnie od siebie zależne.
Taki podział pozwoliłby także na zaciąganie po kawałku (kiedyś dostałem w Internet Explorerze
błąd, że przekroczyłem czas ściągania).


Pytanie3: Jaki może być maksymalny rozmiar pakietu .rpm?
--------


Koniecznością wydaje się też opracowanie metodologii testowania pakietów.
A powinno się to zacząć od jakości .spec-ów.

Gdzie jest zwięźle i dokładnie (ze szczegółami) napisane jak pisać .spec-i dla PLD.
(aktualny opis wszystkich możliwych do zastosowania makr i ideologicznie słuszny sposób
ich stosowania).
Oprócz tego "co i jak" powinno też być "dlaczego tak, a nie inaczej", bo to zdecydowanie
przyspieszy przysposobienie się.
Tak właściwie to te informacje powinny znaleźć się w FAQ, dlaczego k. nie ma jeszcze FAQ
dla tej listy.


Dobra będę kończył, bo trochę to długie.

Witold Filipczyk