install

[Tomasz Kłoczko]

On Wed, 21 Mar 2001, Paweł Kołodziej wrote:

> Dnia Wed, Mar 21, 2001 at 10:49:06AM +0100, Dariusz Karolczak napisał(a):
> > 
> > ----- Original Message ----- 
> > From: "Tomasz Kłoczko" <kloczek w rudy.mif.pg.gda.pl>
> > To: "gawarim pa polski" <pld-devel-pl w pld.org.pl>
> > Sent: Wednesday, March 21, 2001 10:42 AM
> > Subject: Re: install
> > 
> > 
> > > 
> > > Nie trzeba podawać przewidywalnego czasu. Wystarczy przestać pleść bzdury
> > > o tym, że to co jest jest w stu procentach wystarczajace otwierając tym
> > > samym (w głowach) drogę do dalszych zmian.
> > > 
> > 
> > Powiem krotko dzieki takiej polityce wlasnie mamy prowizorke + wuch + automatolek
> > a nie mamy instalera (dzieki bardzo jesli zmiany maja byc robione dla zmian to
> > dla mnie jest to po prostu bez sensu i tyle).
> 
> imho bardzo dobrze, ze niemamy monolitycznego instalatorta.

Przypomnę jeszcze raz, żę BYNAJMNIEJ NIE JEST TO PRZYPADKOWE. Mówiąc
inaczje jest to w pełni zamierzone i świadome. Powody takiego pospowania
pozwolę sobie złożyć do kupu ponieważ do tej pory były one już wymieniane
ale osobno przy okazji różnych dyskusji:

1) reużywalność.
   Widać to przy wuchu, który nie jest spec aplikacją wyłącznie na
   potrzeby instalatora ale także aplikacja stanadalone która jest
   użyteczna w trakcie dalszej instalacji systemu.
   Jeżeli dołożymy do tego apliacje typu presizer do podziału dysków czy
   aplikacje wspomagająca zarządanie meta/multi devami to mamy na początek
   kilka palikacji których nie ma w innych miejscach, a które współcześnie
   staja sie coraż bardziej potrzebne. Jezlei dołożyć do tego palikację
   która wspomaga konfigurowanie zainstalowanego oprogramowania, która w
   trakcie ściągania i instalacji wybranych wczęsniej pakietów mogłaby być
   już do użycia wtrakcie kiedy normalnie się w zasadzie czeka aż całość
   się skończy to mamy prawie komplet.
   Za tego typu podejściem przemawia także to, że przez to, że
   poszczególne czesci tego co jest na instalce są normalnycmi aplikacjami
   owe kawałki oprogramowania bedą sie rozwijac własnym życiem wzbogacając
   z czasem to co się dzieje instalatorze i co udosepnia ten kawałek
   softu.

2) kickstart.
   Jeżeli każda z aplikacji składowych instalatora jest możliwa do użycia
   wsadowo, nieinterakcyjnie to zamiast bawić sie tak jak w RH w tworzenie
   specjalnego kawałka softu zarządzajacego bezobsługową instalacją według
   zadanych z góry parametrów to odpada nam pisanie takeigo kawałka softu
   na rzecz generatora skryptu i instalaki która bezie mogła działać w
   takim reżimie.

> Natomiast prosze zwrocic uwage na fakt, ze z obecnych skladnikow mozna
> zlozyc kilka roznych wersji instalatora modularnego:
> 
> ash + prowizorka
> ash + wuch
> automatolek + wuch 
> automatolek + prowizorka
> 
> mi osobiscie taki model (kilka wymiennych modulów) bardzo odpowiada.

Dokładnie. Niemniej jest jrszcze jeden szczegół wyraźnie przez nas
zaniednbywany. Chodzi o to, że takie komplety gotowe powinny poprostu
powstawać. Na razie przez rok w tej materii zmieniło się dość nie wiele.
Nadal nie ma odpwiedniego środowiska w którym możnaby manipulować tymi
składnikami według rzyczenia i porzeb.
Mówiąc inaczej powinniśmy mieć kompletny z przynajmniej szczatkową
dokumentacją moduł w cvs w którym wydanie polecenia make wyprodukuje
kompletny obra dykietek startowych. jak to jest teraz przyznam, że nie mam
pojęcia. Na pewno nie jest to nigdzie choćby szcżatkow udokumentowane, a
od tego wychodzi, że trzeba zacząć.

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*