suck

[Tomasz Kłoczko]

On Sat, 27 Jan 2001, Paweł Kołodziej wrote:

> Dnia Sat, Jan 27, 2001 at 03:22:15PM +0100, Maciej 'Agaran' Pijanka napisał(a):
> > On Sat, 27 Jan 2001, Tomasz Kłoczko wrote:
> > > Na ftp jest zapewne jeszcze sporo takich kłaków. Jest to wynik braku
> > > narzędzia które służyłoby do wychwytywanai pakietów które nie mają
> > > spełnionych zależności. Coś takiego mogłoby być uruchamiane podczas
> > > regenowania plików indeksowych na tema z nawet automatycznym przesuwaniem
> > > takiech pakietów do /test i generowaniem gdzieś jakeigoś raportu dlaczego
> > > tak się stało.
> > > Jezeli ktokolwiek miałby chęć coś w tej materii zrobić to napewnoe będzie
> > > to mile widziane.
> > 
> > 
> > takie cos istnieje.. ztcp dobrek pracowal nad tym..
> 
> :) dodal do wucha opcje -D. (ja nawet tego jeszcze nie
> kompilowalem, ale dobrek podsylal jakis czas temu liste pakietow z
> zepsutymi zaleznosciami, wiec powinno dzialac).

Wygląda na to, że wuch w obecnej postaci nadaje się już do
spakietiowania. Czyli bendę mógł popróbować na team. Czy da się w ten
sposób zweryfikować dowolna architekture niezależnie od architektury
systemu na którym sie to uruchamia ?

Przy okazji w wuchu nie działa jesze i18n bo w kilku miejscach trzaba
będzie poprzerabiać nieco źródła. IMHO przydałanby się jeszcze żeby wuch
używał standardowego pliku konfiguracyjnego (powiedzmy
$(sysconfdir)/wuch.conf) i żeby uruchomienie go bez parametrów powodowało
jakby był uruchamiany z "-d /". Przydałoby się także żeby w pliku
konfiguracyjnym mżnabyło używać jako makra bierzącej nazwy architektóry.
Dorobienie tego nie będzie trudne, a napewno mocno poprawi wartość
całości.

Inne zmiany bendą wymagały zapewne konsultacji w grupie co do wogóle
funkcji, wyglądu i sposoby zachowania po to zeby to potem wspólnie
implementować. Na razie wuch to przedewszystkim narzędzie do sprawnego
instalowaia/upgrade pakietów. Funkcje przeglądania, weryfikacji, usuwani
apakietów są imho jeszcze nadal w powijakach i tzraba bedzie nad tym
mocniej popracować. Kto wie czy pozostałe funkcje nie możnaby zapakować w
moduły ładowane dynamicznie robiąc może podwaliny pod jakąś ogólna
aplikację do wspomagania konfigurowania/zarządzania systemem. Ale to
wymagałoby silniejszego przemyślenia takiego szkieletu.

IMHO powoli możnaby zaząć myslenie/dyskusję na ten temat.

Tak czy inaczej w tych rozważaniach przez cały czas warto pamietać, że
wuch ma być jednym z ważniejszych elementów instaaltora i jako taki w
swego rodzaju jądrze powinien zostać prostym. W tym sensie pójście w
modularność włacnie z tym żeby moduły mogły być np. używne niezaleznie od
tego czy bendą pracować w aplikacji graficznej czy znakowej mogłoby być
dobrym rozwiązaniem.

Jedno co mnie cieszy to to, że wydaje mi się, że wuch jest znacznie
szybszy od apta choć i tak próba wykonania np. upgradeu ~70 pakietów przy
zainstalowanych ponad 1.5 tyś. powodowała tak potworne rzężenie, że mam
wrażenie, że coś jest nie tak w ogólnym działaniu tego co jest w librpm
i/lub że winny za takie zachowanie jest czy to kiepski backend bazy czy
też jego nieoptymalne używanie. Jezeli byłby za to odpowiedzialny backend
bazy to kto wie czy nei wartoby sie zacząć rozgladać za innym (np. rdbm
http://www.math.fu-berlin.de/~leitner/rdb/)

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*