suck

Pon, 29 Sty 2001, 11:47:53 CET

On Sun, 28 Jan 2001, Paweł Kołodziej wrote:
[..]
> > 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 ?

W każdym pliku który będzie miał ciagi znaków podlegające
umiędzynarodowieniu na pocżatku sekcji dołączanych plikół nagłóewkowych
trzeba bezie dodać:

#include <config.h>

i na końcu:

#include "defines.h"

Po takiej modyfikacji nap. w src/UInewt.c masz coś takiego przy
kompilacji:

rpmmenlib/rl/rpmio_internal.h:384: warning: static declaration for `fdFileno' follows non-static
batch.c: In function `batch_run':
batch.c:17: warning: unused variable `tmppk'
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/rpm/ -Irpmmenlib -Ipkgssel
-Iother -Inewt-addon -DLOCALEDIR=\"/usr/share/locale\"    -g -O2 -Wall  -c
-o UInewt.o `test -f UInewt.c || echo './'`UInewt.c
In file included from rpmmenlib/rpmmen.h:15,
                 from UInewt.c:20:
rpmmenlib/rl/rpmio_internal.h:384: warning: static declaration for
`fdFileno' follows non-static
UInewt.c: In function `UIcb_conflict':
UInewt.c:229: invalid initializer
UInewt.c:231: invalid initializer
make[1]: *** [UInewt.o] Błąd 1

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

To powinno być proste. W sumie chyba wystarczy zadeklaować wartość
początkową zmiennej przechowującej tą ścieżkę. Czyli zmiana z tego cp
pamietam powinna być jednolijkowa.

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

IIRC mamy chyba nawet conajmniej jedną taką.
W razie czego parser powinno się dać napisać w kilku linijkach
flexa/yacca.

> > 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 i tak porozwiązywałbym rózne dobiazgi które są do poprawiania. W
międzyczasie w miarę zapoznawania się z kodem można bezie to lepiej
przemyśleć. Np. przydałoby sie wygodniejsze wychodzenie z programu :)

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

Jakieś elementy przeglądania są :)
IMHO przydałoby się w miedzyczasie dopracować jakieś menu programu. Może
operownaie na konfiguracji czy też lepszą skalowalność tego co jest na
ekranie w zależności od rozmioaru terminala.

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

IMHO jest to do wykonania. LC jest poprostu paskudnie napisany i zapewne
dlatego mało kto z bardziej zaawansowanych użytkowników ma cheć przykładać
do tego rękę. Sam szkielet musi mały. Powiedziałbym nawet ultra mały - ze
względu na instalator. Moze co najwyżej zawierać kilka funkcji które bęnda
użyteczne dla modułów.

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

Tak czy inaczej zmiany tego typu mogą i muszą być ewolucyjne (o ile na to
się zdecydujemy). Pierwszym krokiem musiałby być opracowanie zestawu
funkcji do obsługi interfejsu. Drugim mogłoby być wydzielenie interfejsu
do modułów i modularyzacja obecnej obsługi pakietów. Potem możan będzie
myśleć o innych modułach. Tak czy inaczej nie śpiesyzłbym sie z tym. To
musi być zrobione naprawdę na spokojnie żeby było dobre. Na razie mamy
wyraźną potrzebę narzędzia bedącego czapą na rpm-a.

> > Ale to
> > wymagałoby silniejszego przemyślenia takiego szkieletu.
> 
> To napweno. BTW kiedys byl pldconf...

IMHo nazwa wuch jest lepsza. IMHO dobieranie nazw mających zwiazek z nazwą
dystrybucji jest jakimś błedem który sygeruje jakieś zamkniecie sie
wyłacznie na problematykę danej dystrybucji. Tak jest np. z debconf czy
różnymi narzedziami typu drake<cośtam> z MDK.

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

I to jest dobre.

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

Nie wiem czy nie przydałoby sie tu coś wątkowego co sprawdzałoby w wątku
zależności tego co zostało zaznaczone i resztą w razie czego raportujące w
osobnym okienku jakieś wydażenia (głośno myślę).

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

Tak czy inaczje pośpiech jest tu mało wskazany. Co nagle to po diable.

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*