parę sugestii dot. rpmmen

[Paweł Gajda]

On Thu, 1 Apr 1999, Paweł Kołodziej wrote:

> [wtorek, 30 marzec 1999], Paweł Gajda napisał(a):
> 
> > On Sat, 27 Mar 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ę? :-)


> > 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()) 
> 
> Komunikaty o błędach są logowane przez log_message, ale można to również
> wyrzucić na ekran (może takie okiengo po całości instalacji, czego się nie
> udało zainstalować ?)

Ja byłbym za pytaniem usera czy chce instalować dalej po każdym
błędzie, jest to IMHO b. eleganckie, aniżeli np. po tych 50 MB
ściągniętych z sieci obwieszczenie mu, że się jednak nie udało.



> 
> > 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ć. 
> 
> ale, źródło podajesz przez wcześniejcze iointf_chroot

Teraz tak, ale to IMO nie najlepszy pomysł. O wiele lepiej 
robić to jawnie -> mniej kłopotów ze zrozumieniem programu.



> > Hmm, do tego - o ile mówimy o tym samym - to miała być docelowo grupa
> > Base/Req w pakietach. 
> Eee.. to napewno jest dobry pomysł? Taka grupa może być dość obszerna, i w
> jej skaład mogą wchodzić pakiety o różnej tematyce, może jednak lepszym
> pomysłem jest zrobieie pliku z pakietami niezbędnymi, a w grupach pakietów
> zostawić informację i ich tematyce ?

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. :-)
  


> > 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'')
> A ja wiem, odzielny katalog jakoś średnio mi się podoba, to już lepiej spis
> tych pakiecików i np. będą one miały selected=7 (liczba wzięta z sufitu).
> Jeśłi pakiety były by w różnych katalogach, to dochodzi jeszce iointf_chroot
> gdzieś podrodze, lub coś w tym stylu. Może jednak lepiej poprostu zrobić
> spis tych pakietów ? 

Czy nie za dużo z tym zabawy?  Dopóki nie ma tej podgrupy, to IMO
najprościej zrobić base/.  Unikamy też w ten sposób obsługi takiego
pliku-listy => mniej kodu <=> jest to lepsze :-)
   
Nie wiem dokładnie o co chodzi, ale już kiedyś wspominałeś coś o
selected=64, teraz selected=7 (dostaję gęsiej skórki;-) 
IMO to powinny być zdefiniowane stałe(o ile teraz nie są).  


> > Coś takiego trzeba zrobić. Może na razie przyjmijmy, 
> > że rpmmen wymaga przekierowania stdout, stderr i się tym 
> > nie przejmuje ?  
> 
> Nie bardzo. Przecież użytkownik chciałby mieć linijkę z postępem instalacji
> pakietów, a to jest średnio wykonalne gdy stdout jest przekierowane do
> pliku. dlatego w UIrpmmen_progress stdout jest teraz na chwilę przekierowywany
> na ekran, a potem znowu do pliku.
Jasne. Podsumowując:
- dopóki nie zrobię tej redirect_stdout(), zostaje tak jak jest. 
- przekierowanie stderr jest robione wcześniej 



> > > 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!:-). 
> 
> chodzi tylko o to że przejeczałęś to (chyba) indentem, i przez to diff to
> był prawie cały rpmmen. Ale już chyba wiem jak sobie z tym poradzić :)

Tak, to indent, powinno pomóc(jak już pewnie wiesz) diff -w 
Poprzednio odpowiedziałem nie na temat... ale plama ;-(


Paweł
-- 
mailto: mis w k2.net.pl