suck

[Paweł Kołodziej]

Dnia Sun, Jan 28, 2001 at 12:21:39PM +0100, Tomasz Kłoczko napisał(a):
> On Sat, 27 Jan 2001, Paweł Kołodziej wrote:
> 
> > Dnia Sat, Jan 27, 2001 at 03:22:15PM +0100, Maciej 'Agaran' Pijanka napisał(a):
> > > 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 ?

Tak. Nie powinno byc problemow z weryfikacja dowolnej architektury.
Wystarczy zmiana w source.conf na sciezki do innej architektury

> Przy okazji w wuchu nie działa jesze i18n bo w kilku miejscach trzaba
> będzie poprzerabiać nieco źródła.

Moglbys przyblizyc jakiego typu zmiany sa jeszcze konieczne ?

> IMHO przydałanby się jeszcze żeby wuch
> używał standardowego pliku konfiguracyjnego (powiedzmy
> $(sysconfdir)/wuch.conf) 

Jasne. Plik konfiguracyjny jest w TODO (wlasnie zobaczylem -- nie jest
wpisany -- ale pamietam o nim).

> i żeby uruchomienie go bez parametrów powodowało
> jakby był uruchamiany z "-d /". 

Jak na razie to "-d /" jest pewnego rodzaju wymuszeniem zajzenia do
dokumentacji. No ale chyba faktycznie czas to wywalic. 

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

Znasz moze jakas gotowa bibliotekę do plikow konfiguracyjnych ktora by
oferowala roziwijanie makr i inne wodotryski ?

> 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ć. 

Heh.. jasne. Przedewszystkim trzeba miec pomysl co jest do zrobienia
(czyli uzytkownicy powinni zglaszac czego im brakuje !).

> Na razie wuch to przedewszystkim narzędzie do sprawnego
> instalowaia/upgrade pakietów.

Taki byl pierwotny cel pisania tego (w koncu to kawalek niedoszlego
instalatora).

> Funkcje przeglądania, weryfikacji, usuwani
> apakietów są imho jeszcze nadal w powijakach i tzraba bedzie nad tym
> mocniej popracować.

Mówiąc dokładniej to niema żadnej z tych przez ciebie wymienionych ;).
No moze poza przegladaniem pakietow (IMHO pkgssel (czyli wlasnie
przegladarka pakietow napisana przez Jarka Woloszyna) jest super. No ale
lista todo w sekcji User Interface jest dosc dluga i wcale sie nie
skraca...)

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

Nie bardzo jestem w sobie wyobrazic cos takiego. Tzn. jak probuje to przed
oczami staje mi linuxconf czy cos w tym stylu. Czy wogóle jest potrzeba
zrobienia czegos takiego ? 

Natomiast na bazie wuch'a (jako programu klienciego) prawdopodobnie 
powstanie system opiniowania pakietow przez uzytkownikow (goraco zachecam
to udzialu w dyskusji (ostatnio dosc niklej) na liscie pld-installer)).

> Ale to
> wymagałoby silniejszego przemyślenia takiego szkieletu.

To napweno. BTW kiedys byl pldconf...

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

IMHO pierwszym krokiem powinno byc sprecyzowanie (mozliwie dokladne)
potrzeb.

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

Wlasciwie juz od dosc dawana interfejs uzytkownika jest oddzielony od kodu
robiacego wlasciwe operacje. Moze nie jest to oddzielenie doskonale, ale
calkiem skuteczne.

> 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,

Masz na mysli dokladanie zaleznosci ? Jesli tak (napewno tak) to juz dawno
mialem to znaczaco przyspieszyc (podobna zmiana w prowizorce przyspieszyla
to chyba z 5 razy). Postaram sie to zrobic w najblizszej przyszlosci [1].

> ż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.

Jak najbardziej winnym jest nieoptymalne uzywanie przezemnie. Jedna mala
zmiana i dopiero wtedy jesli dalej bedzie kiepsko to bedzie mozna wieszac
psy  na rpmlib'ie.

> 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/)

[1] w srode mam egzamin (mam nadzieje ze ostatni w tej sesji) i robiac do
tego czasu cokolwiek innego poza nauka narazam sie na wyrzuty sumienia...

-- 
Paweł Kołodziej 
pawelk w pld.org.pl 
,,O ile nam wiadomo, komputer nigdy nie popełnił niewykrytego błędu.''
                                                 -- Weisert