test -> ready [02/12/03 #2]

[Paweł Gołaszewski]

On Thu, 4 Dec 2003, Mateusz Korniak wrote:
> > > > To, że się robi rpmnew to jest problem właśnie, jeżeli postać
> > > > configuracji się zmienia...
> > > Ale on się chyba robi tylko jeśli admin pozmieniał plik
> > > konfiruracyjny, tak ? Jeśli tak, to znaczy że domyślny mu _nie_
> > > odpowiada i _nie_ można go przykrywać nowym domyślnym. Coś źle
> > > rozumiem ?
> > Tak, źle rozumiesz. Miałem zainstalowany program, w którym zmieniłem
> > cośtam w konfigu. Po upgrade mi to _nie działa_ . To jest zła
> > sytuacja, a już niedopuszczalna w stabilnej linii. Takie rzeczy zawsze
> > powinny być poprawiane triggerami. O ile to jest tylko możliwe.
> A możesz pociągnąc dalej wyjasniena, konkretnie, co miałby robić ów
> magiczny trigger w kontekście jak poniżej ?

Jest kilka możliwości:
- najlepsza - skrypt dostosowujący konfig do aktulnej składni/postaci.  
  Najtrudniejsze i realizowalne tylko w prostych przypadkach tak
  naprawdę...
- komunikat, że usługa nie działa, że zmienił się config i trzeba ręcznie
  zrobić zmiany - niedopuszczalne w stabilnej linii...
- podmiana configa wyedytowanego na czysty, nowy i komunikat, że tak jest
  zrobione. Zaleta: usługa działa (byle jak, ale działa). Wada: config
  jest czysty... Też raczej nie akceptowalne w stabilnej linii, ale i tak
  jest to lepsze niż wcześniejsza opcja.

> Zmieniła się filozofia pracy pakietu na tyle stary plik konfiguracyjny
> nie działa z nowym pakietem.

Na czym polegają owe różnice?
Najlepiej na przykładach...

> Robiona jest aktualizacja w systemie w którym ów stary plik
> konfiguracyjny jest zmieniony.

Taką systuację cały czas zakładamy...

-- 
pozdr.  Paweł Gołaszewski 
---------------------------------
worth to see: http://www.againsttcpa.com/
CPU not found - software emulation...