Dwa tematy.

Paweł Kołodziej pawelk w pld.org.pl
Pon, 18 Wrz 2000, 22:28:29 CEST


Dnia Mon, Sep 18, 2000 at 04:20:43PM +0200, Tomasz Kłoczko napisał(a):
> 
> Tak dalej na marginesie problematyki zwiażanej z operowaniem na pakietach.
> 
> Ważna jest w tym wszystkim także kolejna rzecz czyli sprawne akualizowanie
> zasobów. Chodzi o wykorzystywanie tocfile. W tej chwili jest nawet już o
> tyle lepiej, że tocfile jest kompresowany.
> 
> Po dociągnieciu tocfile ma się pełny zasób informacji umożliwiających w
> zorientowaniu sie co pakiety zawierają, a taże jakie są miedzy nimi
> zależniości. Mając tocfile możan off-line wytypować bezpostrednio listę
> plików do ściągniecia.
> 
> Spakowałem tocfile do i386 przed chwilą i wyszło mi 1554547 bajtów
> (~1.5M). 

Nie wiem jak to zrobiłeś, ale u mnie tocfile (z 1779 pakietów (mirror z
przed kilku dni)) ma 16Mb a spakowany (gzip -9) 4.6 Mb.

> Zapewne przed spakowaniem możnaby generować pliki różnicowe za
> pomocą xdelta co przy wszelkich aktualzacjach pozwoliłyby na dociegnięcie
> raz pliku tocfile, a potem róznic które miałyby po paręnaście KB. Jakby
> sie uprzeć to dzień w dzień moząńby nawet na jakąś lisę w uuencode wysyłać
> taki plik różnicowy po to żeby w .procmailrc coś takeigo wypakowywać i
> aktualizować własny tocfile po to żeby mieć pełny wgląd na bierząco w to
> co jest dostępne i w jakiej wersji (itd).

IMHO bardzo dobry pomysł.

> Platformę do wydłubania czegoś co miałoby być nawet sprawnieszym (IMHO) od
> apt (jeżli chodzi o zaciaganie informacji o pakietach) już mamy (i takiej
> platformy jak na razie nie dorobiła sie zadna dystrybucja bazująca na
> rpm-ach).

AFAIK mandrake ma cos w stylu tocfile, i jakieś primitywne nardzędzie do
upgreatowania.

> Brak jest różnych narzędzi które by to wykorzystywały.

To fakt. Myśłe że należało by się poważnie zastanowić jakie dokładnie
narzędzia są nam potrzebne. Rozumiem że chodzi o coś do updatowania
systemu. Ale na jakiej zasadzie ma to działać. Czy ma to być update
powiedzmy minimalny (np. chce nowego mutta, ale ma być zrobione to tak
żeby zmiany dotyczyły jak najmniejszej ilości pakietów), czy raczej
maksymalny (chce wszystkie pakiety które mam teraz, ale w najnowszych
dostępnych wersjach), a może sensowny okazał by się update, nazwijmy go
połowicznym, w którym updatowany jest przykładowy mutt, wszytkie pakiety
których on wymaga (nawet jeśłi nie jest to konieczne ze względu na
spełnienie zależności), i dla każdego z tych updatniętcyh pakietów
procedura jest ponawiana (one stają się przykładowym muttem), a może jakiś
inny (jaki ???)

> Nawet mi który ma bardzo szybki dostęp do ftp.pld.org.pl wygenerowanie za
> pomocą rpm-updater listy pakeitów które mogę zaktualizować zajmuje
> parędziesiet minut (czasmi do ca. dwudziestu) gdy tymczasem to powinno
> trwać sekundy.
>  
> W sumie pierwsza iteracja takiego narzędzia mogłaby być rozwinięciem
> skryptu rpm-updater z PLD-docs.

Rozwijanie tego jako skryptu ma bardzo poważną wadę: rpm nie daje
możliwości wygrzebania z tocfile potrzebnych infomacji o poszczególnych
pakietach. Pozatym odpowiedzi kod w C już praktycznie istnieje (patrz
CVS: installer/pldi/rpmmenlib)

[ciach]

> 
> Powyższe nakreśla dwa narzędzia które niemal żywcem mają szanse być
> częścia instalatora. Wyodrębnienie tego w osobne programy powinno wpłynąć
> na zwiekszenie zrównoleglenia prac nad samym instalatorem .. ergo
> przyśpieszenia prac nad nim.

Większość elementów instalatora (poza tymi funkcjonalnie powiązanymi)
tworzy w miare autonomiczne całości, więc nie ma sztucznych przeszkód
uniemożliwiajączych ich rozwój. IMHO brak jedynie ludzi którym chciało 
by się przy tym podłubać.
 
> Jeżeli możnaby prosić osoby pracujace nad instalatorem o to żeby
> spróbowały wyodrębnić sama wybieraczkę pakietów i konfigurator do
> interfejsów sieciowych tak żeby można było zaczać dopracowywać to już
> neizależnie od instalatora.

Od kilku dni pracuje właśnie nad usamodzielenieniem wybieraczki i modułu
instalującego. Myślę że w Bardzo Bliskiej Przyszłości(tm) pierwsza
alpha-alpha powinna być dostępna (na bootkietce, jako alternatywa dla 
prowizorki). Na razie służy to wyłącznie do instaalcji a nie upgrade'u.

Pewien problem stanowi emewntualne wyodrębnienie tego w osobny modół CVS'u,
bowiem wszystkie częśći instalatora używają pewnych wspónych,
specyficznych bibliotek (pldilib i trurulib), które do tej pory są
rozwijane w ramach modułu installer.


> Ta pierwsza aplikacja (wybieraczka pakietów)
> już sama w sobie zawiera dość nowatorskie rozwiązania (zapewne mało kto to
> widzał :)

A owszem, jest całkiem wygodna :).

-- 
Paweł Kołodziej 
pawelk w pld.org.pl 



Więcej informacji o liście dyskusyjnej pld-devel-pl