Wolna amerykanka w PLD?

[Rafal Cygnarowski]

W liście z ?ro, 09-04-2003, godz. 18:00, Pawel Wilk pisze: 
> On Wed, Apr 09, 2003 at 02:46:02PM +0200, Rafal Cygnarowski wrote:
> 
> > - co chcesz przechowywac w tym "rejestrze" poza sciezka do konfiguracji
> >   programu?
> 
> w przyszłości także inne sciezki, np. data_dir opisany w drafcie do HOME-ETC,
> czy tmp_dir, czy inne ścieżki.. także właśnie przyszedł mi taki pomysł, że
> można tam trzymać także różne ustawienia, które potem będą ładowane do
> zmiennych środowiska przy starcie powłoki, np.:
> 
> env.LANG = pl_PL
> env.NNTPHOST = news.icm.edu.pl
> 
> i mamy z głowy sytuację taką, że dla różnych powłok zmienne środowiskowe
> umieszczamy w różnych plikach rc ze względu na różnice w składni exportu.
> Ofkors wymaga lekko zmodyfikowanych powłok.
mozna to zrobic bez modyfikacji powlok

> Celem switches jest uspójnienie gospodarki prostymi ustawieniami i przełącznikami.

nie raz mialem problem z systemem plikow. Cieszylem sie zawsze, gdy
blad dotknal, np. dokumentacji do programow, gorzej z programami ale
jesli juz maszynka wystartowala to reinstalacja programu nie byla 
w koncu tak ciezka. Jak padlo na konfiguracje to cieszylem sie, ze nie
mam do czynienia z windowsem, bo uszkodzenie rejestru w duzej czesci
przypadkow konczylo sie reinstalacja systemu. Odtworzenie pojedynczych
plikow zawsze jest latwiejsze i nie zamienie tego na nic innego.

[ciach]

A teraz kilka moich spostrzezen.

PLD dorobilo sie juz setek programow. Z reguly kazdy z nich posiada
wlasna skladnie plikow konfiguracyjnych. O ile widze szanse na
powodzenie projektu HOME_ETC, to wdrozeniu tego o czym pisales daje 0%
mozliwosci. Mantainerzy sa na prawde leniwi. Nawet sobie nie zdajesz
sprawy z tego jak bardzo. A kaz im zmieniac cos co juz maja zrobione i
dziala im 'tak' dobrze!

Jak dla mnie rozwiazaniem moglby byc dobrze przemyslany konfigurator,
ktory tworzylby konfiguracje (dowolnego) programu w postacji xml-a (wiem
znowu ten xml...). Na podstawie napisanego wczesniej szablonu .xsl
dokonana zostalaby transformacja do wlasciwego pliku konfiguracyjnego.

Wezmy na ten przyklad wspomniane wyzej zmienne powloki.

<pldconfigfile>
	<envvariable name="HOME_ETC" value="etc"/>
	<!-- i tak dalej... -->
</pldconfigfile>

po przejsciu przez csh.xsl generowalby inny skrypt niz po bash.xsl...
zle? Bez modyfikacji czegokolwiek. Dodatkowa zaleta xml-a jest taka, ze
IMHO daloby sie pominac tworzenie plikow .rpmnew przy updacie paczki
(hint. patrz fwbuilder)...


-- 
Rafal Cygnarowski
rafi w pers.pl