Dwa tematy.

[Jarek Woloszyn]

[środa, 20 wrzesień 2000], Tomasz Kłoczko napisał(a):

> > > 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ć.
> > 
> > IMHO wybieraczka powinna pokazywac to co mamy w systemie teraz,
> > a pakiety dostepne w nowszych wersjach pokazywac z jakims ,,ptaszkiem''.
> > Dorobienie flagi ,,nowsza wersja'' na liscie pakietow wybieraczki
> > umozliwia automatycznie stworzenie nowej grupy pakietow do upgradu,
> > na ktorej mozna sobie to powybierac.
> 
> IMHO ptaszek to za mało/to jest mało przejrzyste. Dobrze jakby wybierane
> pakiety dało się oddzielić w osobna grupę/listę. Tak jak w sklepie ..
> bierzesz koszyk i zaiwanaisz między półkami, a na koniec do kasy z
> wózkiem. Ten sposób wydaje mi się ergonomicznieszy. Miejsca na terminalu
> nawet 80x25 chyba powinno wystarczyć na taka ekstrowagancję.

W tej chwili cos takiego jest juz zrealizowane przy instalacji. Tzn. sa 3
grupy:

- wszystkie pakiety
- pakiety wg grup rpma
- pakiety wg grup instalatora (www server, workstation... itp)

do tego jest jedna grupa w ktorej pokazywane sa pakiety ,,wybrane''.
Wczoraj nad tym troche myslalem i mozna analogicznie zrobic grupy
z pakietami zainstalowanymi, nie zainstalowanymi, przeznaczonymi do upgrade.
Gdyby rozwinac tocfile.lst o jakis dodatkowy znacznik, to mozna by bylo
dodatkowo zaznaczac pakiety, ktore koniecznie trzeba zupgradowac, bo
wyszedl jakis exploit. Wtedy mozna dodac opcje, ze te pakiety sa aktualizowane
co noc, a reszta jak juz sobie admin zazyczy.

> Uruchamiając aplikację w trybie automatycznego sprawdzania tego co może
> być zaktualizowane przy takim podejściu IMHO jest to o niebo
> przejrzystrze (a o dziwo żadne narzędzie chyba nie próbuje stosować 
> tej taktyki). W drugim okienku wartoby mieć juz tylko listę tego czego sie
> nie ma zainstalowanego (to co jest zainstalwoane jest mniej ważne, a ten
> byk IMHO został popełniony w przypadu dselecta).

w tej chwili jedna czesc ekranu to lista pakietow, druga to informacje o
pakietach (wielkosc, itp.). Ale mozna to zrobic na tej samej zasadzie co
mc. mamy dwa panele - w obu liste plikow. i mozna sie swobodnie pomiedzy tymi
grupami poruszac. W jednym panelu miec np. to co wlasnie wybralismy, w drugim
to czego jeszcze nie mamy w systemie.

> [..]
> > Ja bym sie sklanial do minimalnego upgradu. Jezeli chcemy zrobic upgrade
> > mutta, to instalacje nowych bibliotek powinny robic zaleznosci. 
> 
> Uważaj bo pojęcie "minimalnego upgradu" w takim wypadku możesz zahaczać o
> fuzzy logick. IMHO powinna być tylko opcja upgrade'u bez dalszych
> przymiotników. KISS .. KISS Jarek :_)

:)
czyli robima to najprosciej. pakiet ktory chcemy aktualizowac, robi
aktualizacje tego co mu jest potrzebne z niespelnionych zaleznosci.

> > > 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.
> > 
> > Jak skonczysz to sprobuje dorobic do tego opcje upgrade. 
> 
> Ta kwestia szczerze mówiać dała mi największy "load" pod czaszką i dlatego
> z odpowiedzia na kwestie jaką Paweł zachaczył odkładałem soebie nie
> odpowiadajac od razu na list.
> Na ile te biblioteki odbiegaja od ncurses/slang ?

one nie majac nic wspolnego ze slangiem. 
pldilib to zbior funkcji udostepniajacych jakis jednolity interfejs do roznych
rzeczy potrzebnych instalatorowi. np. jest zbior funkcji do otwierania pliku
i w tej bibliotece funkcje sie martwia czy plik jest na lokalnym fs, czy na
ftp. dodatkowo jest tam obsluga lilo, modulow, montowania dyskow, itd.
Po prostu to co nie ma nic wspolnego z interfejsem uzytkownika jest tam.
W ten sposob dopisanie kolejnego modulu do instalatora to glownie zabawa
wlasnie slangiem(newtem). Latwiej jest pozniej takie cos rozwijac.

trurlib obsluguje struktury danych. z readme:
  a) xmallocs czyli opakowania dla funkcji [ma,ca,rea]lloc, strdup oraz free.
  b) makroinstrukcja n_assert(), analogiczna do assert(), z tym, że
      zamiast abort() wołająca funkcję wskazaną przez nas.
  c) Parę użytecznych struktur danych:
      - samo realokująca się tablica wskaźników na cokolwiek
      - lista wskaźników na cokolwiek
      - hash (key, value)
      - dbhash (key, value) - opakowanie dla funkcji libdb (man dbopen)

Takze znowu nic wspolnego ze slangiem. 

Sam interfejs oparty jest na newt (tak jak instalator rh) + newt-addon,
pisana przez nas, ktora jest glownie potrzebna wybieraczce, bo udostepnia
bardziej skomplikowane listy.
Nie jestem pewien czy cos jeszcze tego bedzie uzywac. Jak nie to mozna to
kompilowac statycznie (tak jak teraz). 

W tej chwili nasunelo mi sie jeszcze ze wybieraczka moze byc zrobiona jako
biblioteka (tak jak teraz) i pozniej wersja standalone bedzie zawierala
tylko czesc inicjujaca wszystko z instniejacej bazy rpm, a w instalatorze bedzie
wkompilowana w calosc. Chodzi mi o to ze w instalatorze wybieraczka moze byc
uruchamiana pare razy - mamy mozliwosc dowolnego przechodzenia miedzy
etapami instalacji. Taka mozliwosc jest teraz. Tylko czy jest to potrzebne?

> Na ile ich utzymywanie jest rzeczywiście zasadne ?

Na trurlibie opieraja sie wszystkie struktury danych - 
przynajmniej w wybieraczce.


-- 
 ( Jarek Woloszyn ) ( yossa w pld.org.pl ) ( the GNU generation )
 ( HomePage http://dione.ids.pl/~yossa ) (  ICQ UIN: 1922941  )
                              

___________________________
polish  linux  distribution
-> http://lists.pld.org.pl/