Debian Bug report logs - #521813
u-a: Please allow hooks after selecting an alternative

Reply or subscribe to this bug.

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: submit <submit@bugs.debian.org>

Subject: dpkg: [U-A] please allow hooks after selecting an alternative

Date: Mon, 30 Mar 2009 11:02:48 +0200

[Message part 1 (text/plain, inline)]

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,
-- 
 .''`.      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 (application/pgp-signature, inline)]

Message #12 received at 521813@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Josselin Mouette <joss@debian.org>, 521813@bugs.debian.org

Subject: Re: Bug#521813: dpkg: [U-A] please allow hooks after selecting an alternative

Date: Mon, 30 Mar 2009 16:13:49 +0200

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/

Message #17 received at 521813@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: Raphael Hertzog <hertzog@debian.org>

Cc: 521813@bugs.debian.org

Subject: Re: Bug#521813: dpkg: [U-A] please allow hooks after selecting an alternative

Date: Mon, 30 Mar 2009 16:28:43 +0200

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, inline)]

Message #22 received at 521813@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Josselin Mouette <joss@debian.org>, 521813@bugs.debian.org

Subject: Re: Bug#521813: dpkg: [U-A] please allow hooks after selecting an alternative

Date: Mon, 30 Mar 2009 17:15:55 +0200

On Mon, 30 Mar 2009, Josselin Mouette wrote:
> > 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.

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,
-- 
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/

Message #31 received at 521813@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Sylvestre Ledru <sylvestre@debian.org>

Cc: 576972@bugs.debian.org, 521813@bugs.debian.org

Subject: Re: lapack: update-alternatives breaks application linking

Date: Sat, 16 Jun 2012 03:03:18 -0500

Hi Sylvestre,

Sylvestre Ledru wrote:

> I will be very happy to have help (or a patch) for this bug.

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

Send a report that this bug log contains spam.