parę sugestii dot. rpmmen

[Paweł Gajda]

On Tue, 6 Apr 1999, Paweł Kołodziej wrote:
[..]
> > > > > [sobota, 27 marzec 1999], Paweł Gajda napisał(a):
> > > > 
> > > > ok, np. zamiast:  
> > > >  preparetoinstall() ->  preparetoinstall(TPkgSet *pkgs)
> > > >  void select_from_file(char *) -> TPkgSet *select_from_file(char *)
> > > 
> > > teraz to rozumiem... :)
> > i zgadzasz się? :-)
> 
> tak, oczywiście, to powinno być tak od samego początku.
> Tylko jakoś brakuje mi pomysłu na nazwy. Na razie kod po "ubibliotecznieniu"
> zachował dawne nazwy (rpmmen_install(...) itp.) a w module z zmiennymi
> statycznymi jest pldi_rpmmen_install(..), ale jakoś mi to nie pasuje. Jak
> ktoś by miał jakieś propozycje co do nazw to chętnie posłucham (poczytam)

Proszę bardzo :-) 

Skoro pierwszy moduł jest z operacjami na pkg(set) to:
pkg_dosomething(pkg, ...) 
pkgset_dosomething(pkgset, ...)

albo, podkreślając, że to rpm: 
rpmpkg_*() 

Po prostu: funkcje modułu to odpowiedniki metod podobnej klasy C++, z
tym, że co C i trzeba dodać przedrostek "struktura_", a pierwszy
arg to "struktura*". 

Jeżeli metod jest więcej, to można nawet to rozbić: pkg.c i pkgset.c

Ten drugi może wtedy zostać przy rpmmen_(chociaż to 'mm' to IMHO zmora
dla wzroku, może dasz się namówić na rpmen_ ? ;-)) 


> > 
> > Teraz tak, ale to IMO nie najlepszy pomysł. O wiele lepiej 
> > robić to jawnie -> mniej kłopotów ze zrozumieniem programu.
> dobra. Rozumiem że rpmmen powinien przed odczytem pakietów robić
> iointf_chroot(src), a po odczycie z powrotem uustawiać na dawne miejsce ?.
tak
 

[..]
> > Zaraz, zaraz...  To ma być właśnie grupa(właściwie podgrupa) 
> > zawierająca basesystem, czyli to co _musi_ być zainstalowane.
> > Widzę w tym same zalety. Poproszę o wady. :-)
> 
> Rozumiem że myśłisz o polu Group w rpm'ach ? Jeśłi o czymś innym to poniższe
> jest nieaktualne.
> To zależy od tego jak szeroka będzie ta grupa Base/Req. W tym co kiedyś na
> PLD-list było proponowane w base był cały przekrój programów. I teraz,
> jeśli np. ustalimy że  podstawowym Shellem będzie bash to w jego Group
> zamiast Shell wyląduje Base/Req co mało mówi o "przynależności funkcjonalej"
> pakietu, a taki np. ksh dalej by miał Shell. A tamta lista była dość
> obszerna (coś około 80 pakietów (mówie o liśćie zaproponowanej przez
> Marcina Korzonka, 13 XII tamtego roku)).

No to już wiem jaką to ma wadę... Nie pomyślałem o powyższym. 
Rzeczywiście pozostaje chyba trzymanie listy w pliku, chociaż to IMHO
takie nieładne ;-( 

W takim razie może od razu zrobimy tę strukturę kat. z inststuff/
(wspomniałem o tym 2-3 posty wstecz)? Myślę, że tę listę warto
wrzucić od razu na nośnik źródłowy zamiast na dyskietkę, nie trzeba
będzie za każdym razem, gdy chłopakom zmnieni się ksh na bash zmieniać
flopki. 

Jest do dyspozycji buildpath() i nie trzeba robić iointf_chroot() czy
sklejać stringów, żeby poskakać po katalogach. 

Aha, trzeba zmontować jakieś narządko do budowy tej listy(na podstawie
dumptocf, mogę zrobić), poprzednio wymiękłem przy 4 pakiecie ;-)) 

> Jeśli natomaist w Base/Req miałyby wylądować tylko _niezbędne_ minimum,
> czyli basesystem, filesystem, setup i ewentualnie coś jeszcze to już ma to
> większy sens.

Hmm, tylko i tak potrzebna jest lista -> komplikujemy sobie życie
obsługą jeszcze grupy. Chyba nie warto?  
 
Paweł