Package: dpkg
Severity: wishlist

Hi,

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.

Thanks for considering,

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,

Le lundi 30 mars 2009 à 16:13 +0200, Raphael Hertzog a écrit :

Argh :(

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.

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,

It seems at least logical to go towards this solution in the long term
but I don't think it's currently doable. At least not without
prior-changes to dpkg-trigger.

Guillem, your advice would be welcome here.

Cheers,

Hi Sylvestre,

Sylvestre Ledru wrote:

There is a patch at <http://bugs.debian.org/638236#10>.  Anything
more flexible will require infrastructure that does not exist.
What do you think should be done?

Thanks,
Jonathan