suck

Paweł Kołodziej pawelk w pld.org.pl
Pon, 29 Sty 2001, 14:04:55 CET


Dnia Mon, Jan 29, 2001 at 11:47:53AM +0100, Tomasz Kłoczko napisał(a):
> 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"

na końcu pliku ???

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

Jasne. Ale dotychczas stan obecny byl utrzymnywany niejako siwadomie.

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

Faktycznie jest conflib.

> W razie czego parser powinno się dać napisać w kilku linijkach
> flexa/yacca.

Mozna. Ale czy warto ? Jakos nie widze zastosownia do makr.
No chyba że przewidujesz ogormny rozwoj tego programu...

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

Jeszcze wygodniejsze ? ;)

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

Nie podejmuje sie pisania interfejsu uzytkownika.  Natomiast jesli bedzie
jakis ochotnik (malekith ???) to chetnie przygotuje stosowne API.

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

Akurat w procesie instalacji wuch jest dociagny z medium z pakietami, i
rozpakowyany na dysku na ktorym bedzie przeprowadzana instalacja, więc
jego wielkośc z tego wzgledu nie jest krytyczna.
natomiast oczywiście łatwiej jest trzymać w ryzach coś, co jest mniejsze.

> Moze co najwyżej zawierać kilka funkcji które bęnda
> użyteczne dla modułów.

Jakiego typu moduły widzisz (przegladanie, instalacja pakietów,
konfiguracja sieci, demonow ??? tego typu ?)

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

W pełni się zgadzam.

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

Nie chodzilo mi o samą nazwę. Miałem raczej na myśłi ideę i kawałek kodu
który został na tę okoliczność stworzony (AFAIR przez Sebastiana).

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

Tzn. że ktoś zaznacza jakis pakiet, i juz od tego momentu rozpoczyna się
w tle procedura wyszukiwania zaleznosci ? Jakoś nie jestem przekonany.
Na razie poza przyśpieszweniem (Jeśłi dzisiejszy patch malekitha na rpm'a
dziala, to IMHO powinien zostać jak nakszybciej wrzucony do dystrybucyjnego
rpm'a a ten wyslany na buildery -- umożliwi to _znaczace_ przyśpieszenie
zależności w wuchu'). Poza tym pozostaje kwestia pokazania userowi do
wyboru kilku pakietow np. demonow smtp -- tu niestety tez pez poprawki w 
rpm'ie sie nie obejdzie.

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

:)

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



Więcej informacji o liście dyskusyjnej pld-devel-pl