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