How should update-alternatives be called in maint. scripts?
I'd appreciate it if someone who knows how update-alternatives is
*supposed* to be used could read through bug 38584 and say who's
Briefly, I consider the alternatives and priorities a package installs
to be "static" information; configuration should be done by changing
symlinks in /etc/alternatives and so causing update-alternatives to
switch the link in question to manual mode when it next tries to
On the other hand, the author of the "update-ispell-dictionary" script
in the ispell package seemed to think that it was okay to
- have all ispell dictionaries installed with the same priority
- manipulate the priorities afterwards to effect configuration changes
- parse the output of "update-alternatives --display" to work out how
to do this.
all of which seems highly suspect and quite evil to me.
The way I've implemented yada's alternatives-handling is simply to call
"update-alternatives --install" in the postinst, and
"update-alternatives --remove" in the prerm, with no guards. My
correspondent thinks I should guard the "--remove" command such that it
doesn't run when the package is being upgraded -- many packages do it
this way. I don't think this would be appropriate for yada; it would
cause problems when a yada-built package stopped providing an
alternative that an older version provided.
On the other hand, the way I'm doing it at the moment causes problems
for packages trying to install ispell dictionaries using yada's
alternatives handler. My reaction to this is "update-ispell-dictionary
is B.A.D., work around it by hand". Luckily, yada doesn't force
alternatives to be installed using its own alternatives handling
Is there anyone here who feels qualified to give an authoritative
ruling on all this?
[Please CC me on the discussion, since I'm not subscribed to
My web page: <URL:http://www.debian.org/%7Ecpbs/>
PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2