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