Le lundi 30 mars 2009 à 16:13 +0200, Raphael Hertzog a écrit : > 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.
Argh :( > 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 ? Not in the first case, but it was really ugly. Looking back at it, it should have used another package instead of alternatives. It wouldn’t work at all today with the upcoming changes in python-support. For the case I’m looking at currently (gnome-icon-theme), it would work without any change if you simply activated the corresponding file trigger, since there is already one here precisely to regenerate the cache if needed. This looks like a really elegant solution to me. > 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 ? IMHO that should be /usr/share/dpkg if you go down that route. That could also be a way to make alternatives more robust, by entirely migrating to a stateless format where you’d just dump links in /usr/share/alternatives/alternative-name/priority_name instead of running update-alternatives in postinst/prerm. Cheers, -- .''`. Debian 5.0 "Lenny" has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `- me that if you don't install Lenny, he'd melt your brain.
signature.asc
Description: Ceci est une partie de message numériquement signée
