standaryzacja {de}rejestracji ston info i polskie many

Tomasz Kłoczko kloczek w rudy.mif.pg.gda.pl
Nie, 13 Gru 1998, 11:08:36 CET


On Sun, 13 Dec 1998, Tomasz Kłoczko wrote:

> 
> Ano ma to mniej więcej wyglądać tak (przykład na podstawie gzip):
> 
> --------------------------------
> %pre
> if [ $1 = 1 ]; then
>         /sbin/install-info --delete /usr/info/gzip.info.gz \
>         --info-dir /etc/info-dir
> fi
> 
> %post
> /sbin/install-info /usr/info/gzip.info.gz --info-dir /etc/info-dir \
> --entry \
> "* gzip: (gzip).                                 The GNU compression utility."
> 
> %preun
> /sbin/install-info --delete /usr/info/gzip.info.gz --info-dir /etc/info-dir
> --------------------------------

Przepraszam. Powyższe jest nieprawidłowe. Po pierwsze trzeba wyciąć
wszędzie --info-dir. Po drugie ze względu na obecną konstrukcję rpm-a
(bardzo "ciekawą" %$!@), która polega na tym, że przy upgrade są
wywoływane kolejno:

%pre    z nowego pakietu
%post   z nowego pakietu
%preun  ze starego pakietu
%postun ze starego pakietu

trzeba nieco inaczej powyższe skonstruować w gruncie rzeczy trzeba
pozostać przy nielogicznej konstrukcji jaka jest w RH pakietach:

%post
/sbin/install-info /usr/info/gzip.info.gz /etc/info-dir \
--entry \
"* gzip: (gzip).                                 The GNU compression
utility."

%preun
if [ $1 = 1 ]; then
        /sbin/install-info --delete /usr/info/gzip.info.gz /etc/info-dir
fi

Jedyna większa róznica ma polegać na braku parametru --entry przy
wykasowywaniu strony info.

Łatwo zauważyć, że jeżeli np. ktoś zapomni dodać 
"if [ $1 = 1 ]; then .. fi" w %preun poprzedniej wersji pakietu, to może
się okazać, że po poprawnym osadzeniu pakietu w nowym %post, %preun
starego pakietu może wszystko skopać. Jedynym w tym wypadku wyjściem
będzie sekwencja "rpm -e", "rpm -i", co oczywiście niszczy automatyzację
upgradeu pakietu. Wszystko pięknie dopełnia jeszcze to, że dopiero po
wykonaniu wszystkich skryptów tak faktycznie są usuwane stare pliki.

Własnie tego typu błąd zrobiłem w poprzednich wersjach bizona i gzipa.
Przy istalowaniu nowych wersji trzeba najpierw wyinstalować stare.
Nałożenie gzip, bizona z PLD na RH przejdzie gładko.

Ostatnio myślałem ciut nad tym i wydaje mi się, że oprócz przywrócenia
logicznego porządku wykonywania skryptów (%preun ze starego pakietu ->
%postun ze starego pakietu -> %pre z nowego pakietu -> %post z nowego
pakietu) jedynym wyjściem jest przechwytywanie w trakcie działania rpm-a
wszystkie modyfikacje plików (także w procesach potomnych jak choćby
wołane skrypty, np. przez podłożenie funkcji open() tak żeby zachowywała
poprzednie wersje plików) i w razie jakichkolwiek niepowodzeń trzeba
odtwarzać _dokładnie_ stan z przed upgradeu/instalacji. Może ktoś widzi tu
jakieś inne rozwiązanie ?

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*



Więcej informacji o liście dyskusyjnej pld-devel-pl