Michael Biebl writes ("Re: triggers wishlist"):
> Sune Vuorela wrote:
> > Maybe having the trigger enabled dh_foo fill in misc:Depends with a
> > versioned dependency on a trigger aware dpkg ?
>
> If I read the triggers documentation correctly, the situation is a
> bit different (please correct my, if I'm wrong. I just quickly
> glanced at triggers.txt) update-icon-caches/update-desktop-database
> would have to be made triggers-aware and install a triggers control
> file (e.g. interest /usr/share/icons or interest
> /usr/share/applications [1])
That sounds reasonable.
> A package installing icons or a desktop file, would remove all calls to
> dh_desktop/dh_icons (that's why cdbs kde.mk/gnome.mk would have to be
> updated to remove the dh_desktop/dh_icons calls). The triggers would be
> activated by installing files into the above directories.
Yes.
> An alternative would be, to keep dh_desktop/dh_icons around, to provide
> backwards compatibility (if triggers-aware dpkg is installed, they would
> be simple no-ops, otherwise they would behave as before).
Yes.
> [1] Will changes to subdirectories (e.g /usr/share/applications/kde)
> also lead to a trigger, or would one have to register all subdirectories
> recursively?
Yes, from the documentation:
File triggers have names of the form
/path/to/directory/or/file
and are activated when the specified filesystem object, or any object
under the specified subdirectory, is created, updated or deleted by
dpkg during package unpack or removal. The pathname must be absolute.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
