desktop-file-utils, ldconfig (Re: SPECS: gimp.spec - R post, postun: desktop-file-utils)

[Jakub Bogusz]

On Tue, Apr 12, 2005 at 04:43:33PM +0200, Kamil Kosiński wrote:
> Dnia 12-04-2005, wto o godzinie 13:46 +0200, Tomasz Pala napisał(a):
> > On Tue, Apr 12, 2005 at 08:05:22 +0200, Fryderyk Dziarmagowski wrote:
[...]
> > > > Dla mnie każdy _niepotrzebny_ pakiet wart jest dyskusji.
> > > 
> > > "Mamy przymknąć"? jest Was więcej? _niepotrzebny_ ? ależ jest jak
> > 
> > Tak.
> Tak pewnie. Powinniśmy jeszcze warunkowo uruchamiać update-mime-database
> no i oczywiście scrollkeeper-update, bo przecież bez uruchomienia ich
> programy będą równie dobrze działać.
> 
> Po jakąś cholerę w gimp.desktop jest pole MimeType, prawda?
> 
> Zobaczmy jak to robimy w przypadku innych programów:
> a) pakiet zawiera dokumentację gnomeową - odpalamy scrollkeeper-update i
> dajemy R(post,postun): scrollkeeper.
> 
> b) pakiet zawiera typy mime - odpalamy update-mime-database i dajemy
> R(post,postun): shared-mime-info.
> 
> No i jeszcze c:
> c) pakiet zawiera MimeType w desktopie - odpalamy
> update-desktop-database i dajemy R(post,postun): desktop-file-utils !!!

Pakiet zawiera strony info - fix-info-dir uruchamiane jest _warunkowo_
(tylko jeśli istnieje).
Pakiety z *.desktop nie wymagają applnk przy instalacji.
Pakiety z fontami nie wymagają wszelkich możliwych programów do
regenerowania katalogów fontów dla różnego oprogramowania - fontpostinst
(sam w sobie z minimalnymi zależnościami) uruchamia je warunkowo.

O ile takie zależności w programach typowo gnomowych mnie nie
obchodziły, to gimpowi (będącemu aplikacją GTK+, nie GNOME) nie
przystoją.

IMO wystarczy uruchamianie tego update* warunkowo (jeśli istnieje)
+ uruchamianie w %post desktop-file-utils (może być pod warunkiem
[ "$1" = "1" ]), żeby się wygenerowało przy doinstalowaniu po
wcześniejszym zainstalowaniu programów dostarczających takie pliki.


BTW: jeszcze odnośnie zmian zw. z nowymi makrami - zaniechałbym zamiany
-p /sbin/ldconfig na jednoliniowe skrypty /bin/sh z wywołaniem
/sbin/ldconfig. Powoduje to nadmiarowe: wywołanie fork/exec przy
(de)instalacji i zależność od /bin/sh w pakiecie.
Ponadto pomijanie /sbin/ldconfig w %postun przy upgrade nie jest dobre:
- przy downgrade zostaje zepsuty symlink soname do nowszej, usuniętej
  wersji biblioteki, zamiast do właśnie zainstalowanej starszej (tak
  samo, jak po wywaleniu dynamicznego postshella przy downgrade glibc -
  ćwiczyłem wczoraj, bardzo fajny efekt, polecam - tylko nie wylogowywać
  się przed uruchomieniem ldconfig)
- nie jestem pewien, czy przy upgrade do wersji z nowym soname nie
  zostanie zbędny zepsuty symlink dla starego soname


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/