On Mon, 30 Mar 2009, Josselin Mouette wrote: > Some selections of alternatives require updating some kind of cache. > I have already met such an issue in the past (IIRC with a Python > module), and I see it happening again with an icon, see #516566. In this > case, after selecting the alternative, it will not be effective on the > user’s desktop until the icon cache is regenerated. Not regenerating it > leads to an inconsistency. > > Therefore, it would be nice to allow configuring a hook when setting up > an alternative; the hook would have to be run after any manual change in > the selection, avoiding such inconsistencies.
It doesn't seem doable to register the hook when the alternative is created, the file format has not been created with possible extensions in mind. Several questions pops up: 1/ Would running any file trigger based on the path of the modified alternative solve the problems in both cases you have encountered ? 2/ We could have fixed filesystem-based hooks, i.e. execute any program in /etc/dpkg/u-a-hooks/ with alternative-specific arguments every time that an alternative symlink is created or updated. What kind of granularity should we provide if we go towards this solution ? Should it be in /etc/dpkg or in /usr/share/dpkg/ or in both ? Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
