parę sugestii dot. rpmmen

Wto, 30 Mar 1999, 17:16:36 CEST

On Sat, 27 Mar 1999, Paweł Kołodziej wrote:

> [sobota, 27 marzec 1999], Paweł Gajda napisał(a):

> > 
> > 1. Uczytelnienie kodu 
> >  - ident -kr (wcięcia, spacje wokół operatorów, itd) 
> 
> dobra, ale postuluje indent -kr -i 8 

Ponieważ rpmmen jest osobnym pakietem, a kwestia wcięć 
jest natury ,,religijnej'', więc nic mi do tego :-)

> >  - myślę, że lepiej było by nie operować na statycznych zmiennych,
> >    tzn:
> >    zbiór funkcji operujących na TPkgSet i dopiero w osobnym
> >    module zrobić statyczne zmienne. Przede wszystkim ułatwia to 
> >    zrozumienie kodu => IMO ułatwia jego rozwijanie.           
> nierozumiem, poprostu nie rozumiem powyższego zdania. Naprawdę staram się
> zrozumieć, ale nie mogę... mógłbyś trochę przybliżyć (jakiś bardziej
> konkretny przykład)

ok, np. zamiast:  
 preparetoinstall() ->  preparetoinstall(TPkgSet *pkgs)
 void select_from_file(char *) -> TPkgSet *select_from_file(char *)

Dlaczego tak:
- po prototypie widać WE/WY funkcji => o wiele łatwiej
  analizować taki kod. 

  Jak chciałem zablokować czytanie coinst.rpm musiałem przyjrzeć się
  po drodze każdej wołanej funkcji, bo nie wiedziałem,
  która co(i czy w ogóle) modyfikuje w rpmmen_pkgs. 

  O ile Ty wiesz, jak to działa, to dla osób, które chciałyby
  w jakiś sposób to rozwijać IMHO przeszkodą będzie właśnie
  konieczność analizy całości, żeby prześledzić co się gdzie 
  dzieje z pkgset. 

- można tworzyć wiele pkgsetów
- można taki kod łatwo opakować w klasę C++  

Podsumowując, chodziło mi o zrobienie 2 modułów: 

- jeden (powiedzmy pkgset.c) bez żadnych statycznych zmiennych 
  z funkcjami typu:

jakaś_funcja(TPkg*, ...)
jakaś_funkcja(TPkgSet*,...)

- drugi, który do manipulowania pkgset'em używał by pierwszego
(i robił to co teraz: otwierałby bazę, czytał tocfile, itd)  

Mam nadzieję, że zbytnio nie zagmatwałem.

Aha, myślę, że trzeba jakoś informować usera o błędach podczas
instalacji. Obecnie jak ją puścimy to przeleci całość nie informując, 
że np. nic się nie zainstalowało(używam rpmmenUI_run()) 

> >  - funkcje inicjujące set_src, set_dst itd udostępniłbym pod 1:
> >    rpmmen_init(src, dest)   
> Właściwie to set_src będzie w iontf, więc IMHO możę pozostać rpmmen_set_dest

Pisząc 'itd' myślałem jeszcze o rpmmen_opendb(), czyli o udostępnieniu  
wszystkiego w 1 funkcji.  

Hmm, czy warto wyrzucać ,,obsługę'' src (rozumiem, że chcesz tak
zrobić) ? IMHO nie, bo narusza to spójność: dlaczego kto inny ma się
tym martwić? Podaję modułowi źródło,cel i każę instalować. 

W ogóle może docelowo warto zrobić strukturę kat. podobną do RH:

 -- RPMS
 -- inststuff
     - tocfile
     - grupy_pakietów_do_selektora
     - coś_tam_jeszcze 

> > - zauważyłem, że rpmen potrzebuje pkgsel i na odwrót, 
> >   IMHO nie powinno to mieć miejsca.
> tzn. rpmmenlib nie potrzebuje pkgssel'a, potrzebuje go jednynie rpmmenUI.c
> który jest używany jedynie w rpmmenExample.c. nie bardzo mam pomysł, co z
> tym zorbić, chyba jednym wyjsciem było by rozdzielenie rpmmenUI_run() na
> rpmmenUI_run1() i rpmmenUI_run2() i potem:
> rmpmenUI_run1();
> pkgsel()
> rpmmenUI_run2();
Pogubiłem się w powyższym ;-) 
IMHO po prostu: jeden przykład do liba, drugi przykład do pkgsel.   

[o coinst]
> 
> ta funkcja powstała raczej na użytek testów/jako przykład co trzeba zrobić,
> aby zaznaczyć pakiet do instalacji. To taki mój wszesny "selektor pakietów"
> i oczywiście nie musi być w wersji ostatecznej. Jednak i tak niektóre
> pakiety powinny być pre-zaznaczone, a skoro tak, to dlaczego nie użyć do
> tego tej funkcji ?

Hmm, do tego - o ile mówimy o tym samym - to miała być docelowo grupa
Base/Req w pakietach. 

Dopóki jej nie ma, to IMHO najprościej zrobić tak, jak jest 
teraz: osobny kat. z pakietami base. Wszystko z base/tocfile  
jest ,,zaznaczone'' (i nie może zostać przeż juzera ,,odznaczone'')

Jak się już pojawi ta grupa, to problem zniknie.      

> (nie wiem co maiłeś na myśłi pisząc o weryfikacji - ta funkcja nieczego nie
> weryfikuje, ona tylko zaznacza które pakiety mają być zainstalowane)

ops, racja, pomyliłem się.

> > - ponieważ inst korzysta też w innym miejscu z rpmliba(cpio.gz) to
> >   przekierowanie stderr robię wcześniej, czy na stdout rpmlib 
> >   też pisze ?   
> tylko jeśli w skryptach pakietów są jakeś echa na stdout. W wersji 0.1.7
> zarówno stderr jaki i stdout są "sprytnie" przekierowywane do pliku. Ale
> jeśli stderr są przekierowywane już wcześniej to proponuję zrobić funkcję
> redirect_out(int i); i jeśli i==1 to stdout jes przekierowywane do pliku, 
> i==-1 stdout z powrotem na konsole, a i==0 to zamknięcie pliku do którego
> było przelkierowywanie, coś jak redirect_out z rpmmenUI.c tylko że
> przekierwowyane będzie jedynie stdout. Jeśli się zgadzasz to IMHO tak
> funkcja powinna wlecieć do pldiliba.

Coś takiego trzeba zrobić. Może na razie przyjmijmy, 
że rpmmen wymaga przekierowania stdout, stderr i się tym 
nie przejmuje ?  

> > Zauważyłem, że instalacja base wymaga dosyć sporo pamięci
> > (zajętość skacze z 700 kB do prawie 3 MB), m.in. 
> > dlatego, że cały tocfile jest wczytywany do ramu. 
> > Dla base (100 pakietów) to jeszcze ujdzie, ale jak będzie ich 
> > 500-600 ? Zastanawiam się, czy nie warto robić
> > indeksu odczas czytania tocfile. Co o tym myślisz ?  
> 
> Nie bardzo rozumiem o co ci _dokładnie_ chodzi z tym indeksem. W każdym
> razie, do np, dokładanie paietów z zależności potrzebne są wszystkie
> nagłówki. Tak więc i tak muszą być wszystkie na raz w pamięci. Można się

Hm, jeżeli tak, to indeks można sobie darować.   

> zastanowić co można z nagłówków zapisywanych w tocfile wywalić (jakie pola),
> ale narazie nic mi nie przychodzi do głowy. A i tak w czasie gdy jest 
> uruchamiany rpmmen, to jest już po ustawianiu partycji, więc można by już
> podmontować swap, ewentualnie zrobić plik ze swapem na partycji na którą
> instalujemy.

swapon ma user do wyboru(swapfile robiony ,,po cichu'' to IMHO
przesada), chyba trzeba będzie tę możliwość zaakcentować :-) 

> > Zmieniłem dosyć mocno pldilib, na czym Ty głównie ,,ucierpisz''.
> > Zaktualizowałem opis iointf'a, także nie powinno być ze zmianą 
> > wielkich problemów, jeżeli by jednak, to albo pytaj, 
> > albo ja machnę łatkę i Ci podeślę. 
> myślę, że sobie poradzę

fajnie, zajrzyj jeszcze do misc.c, może zainteresuje Cię parę 
funkcji (mkdirhier(), buildpath()).  

> > Jestem też w stanie wziąć udział w robieniu wyżej postulowanych 
> > poprawek, wymaga to jedynie Twojego ,,błogosławieństwa'' :-) Więc jak ? 
> Nie wiem jak bardzo ci się spieszy. Jeśłi potrzebjesz tego na wczoraj, to
> zrób, jeśli czwartek wieczorem to wystarczająco wcześnie to ja to zrobię.

Aż nadto, aż tak się z tym nie pali. 

> 
> PS. Zorbiłem sobie diff'a między tym co wylądowało w pldi a wersją
> ,,orginalną''. 99% to były zmiany w układzie kodu, więc nie byłem w stanie
> odsiać zmian merytorycznych od stylistycznych :(

Znaczy się... uznałem, że nie warto dla samego rpmmena zachowywać 
zgodności wstecz(wyżej oferuję pomoc w przejściu!:-). 

IMHO zyskał na tych zmianach cały lib. Zmiana konwencji nazewniczej 
to już moje widzimisię, chociaż i tu IMHO zostały usunięte 
niekonsekwencje.

W iointf(bo chyba to Cię głównie interesuje) nie zmieniłem dużo,
usunięte są błędy i powtórzenia kodu. Inaczej się go inicjuje, 
no i są 3 nowe funkcje 

- ioi_errstr() (dla fs jest to strerror(errno)) 
- iointf_chroot()
- iointf_getroot()

Przy okazji: 
W ttest.c jest błąd w funkcjach test_iointf_*(), 
wołana jest ioi_errstr() w razie niepowodzenia iointf_init(). 

Paweł