Kształt instalatora

Śro, 11 Kwi 2001, 13:16:46 CEST

On Wed, Apr 11, 2001 at 12:49:20PM +0200, Rafał Kleger-Rudomin wrote:
> Michal Moskal <malekith w pld.org.pl> writes:
> Ja już zacząłem robić takie coś bez xml bo imho sprawa jest zbyt prosta 
> i xml jest tu niepotrzebny.
> Natomiast przydałby się bardziej do metakonfigów.

Prosta, nie prosta... XML rocks :> Chociaż może masz rację.

> > Teraz odpowiedzi na kilka pytań. 1. Dlaczego XML? Bo taka moda ostatnio :)
> > A poważnie, bo jest samoopisujący, można fajnie zagnieżdżać sekcje,
> > a poza tym patrz 2. 2. Dobra, XML, ale jak ty to chcesz na bootdisku
> > upchnąć? Ano używając super-hyper-iwriiten-on-purpose-scripting-languge(tm)
> > by /me. Oczywiście wszyscy znają moje upodobanie do tego typu rozwiązań :^)
> > W zamierzeniach używanie tego języka ma doprowadzić do usunięcia
> > z bootdisku awk'a i ash'a -> czyli pozyskania ~150k miejsca. 
> > (sed|grep zostanie raczej w busybox, żeby user mógł go sobie używać z 
> > lash command line). Język, zgodnie z sugestią Łukasza (który chyba nie
> > mówił tego poważnie :^), nazywa się doozy, w takim też module należy
> > go szukać w CVS. W środku jest opis, czytać najlepiej zacząć od pliku
> > rc-inetd.doozy, który zawiera skrypt rc-inetd dla rlinetd, z duuużą
> > ilością komentarzy. (dzięki Rafał za sugestię :) Można również użyć
> > skryptu mkdoc (jest w doozym, więc trzeba najpierw zrobić doozego - make),
> > żeby stworzyć opis builtinów. Nie wszystkie są już opisane :<
> > Na przykładzie tego pliku można łatwo stwierdzić, że doozy nie jest
> > zbyt szybki. Ale i tak jest o rząd wielkości szybszy od shella, który
> > musi robić ciągłe forki i execi (n.p. dla seda).
> 
> Asha i tak się nie pozbędziemy, może awka.

Czemu?

> Szybkość nie ma tu najmniejszego znaczenia.

No wiem, tak sobie tylko dukam :>

> Michał ja prawdę mówiąc myślałem że doozy to będzie tylko taki
> support tool - konwerter do poszczególnych konfigów, a nie samdzielne 
> narzędzie. Widziałem to tak że metakonfigurator jest napisany w shellu
> i tylko wywołuje 
> # doozy jakiś_konfig_xml szablon_doozy >wyjściowy_config
> tzn masz zbiór metakonfigów, po jednym np na każdy pliczek który trzeba wygenerować
> (/etc/fstab, /etc/aliases itd)

To nie przejdzie. To znaczy configi sa znacznie bardziej skomplikowane,
i.e. prosty template nie nada. Zobacz rc-inetd.doozy i zastanów się
jakby to wyglądało z template tylko...

> To ja to widzę inaczej, 
> mamy trzy główne moduły:
> 
> 1. UI do przygotowywania pliku z opisem instalacji dla instalatora
>    ew również do przygotowywania metakonfigów
> 2. Wsadowy instalator
> 3. Metakonfigurator
[snip] 
> Teraz o interaktywności: interaktywny byłby pkt 1.

Hmm... a co jeśli czegoś brakuje? Wiesz, wygodnie byłoby zdefiniować
sobie 90% konfiguracji a coś tam dopowiedzieć potem. To by chyba wykrył
dopiero validate... Chyba, że to ma być duuuży config z polami już
wypełnionymi, ale IMHO pytania byłby lepsze.

> Mam nadzieję że nie będzie szoku :)

:>

-- 
: Michal ``,/\/\,       '' Moskal    | |            : GCS {C,UL}++++$
:          |    |alekith      @    |)|(| . org . pl : {E--, W, w-,M}-
:                                  |                : {b,e>+}++ !tv h
: Current project:  http://aleph-0.dhs.org/ywindow/ : PLD Team member