* Bill Allombert bill.allomb...@math.u-bordeaux1.fr, 2012-09-20, 18:50:
I've just tested 665 packages that use update-alternatives.
122 of them removed an alternative on upgrade.
Could you report bugs ?
I don't think we should be filing bugs before there's consensus _how_
exactly to fix
Jakub Wilk jw...@debian.org writes:
I don't think we should be filing bugs before there's consensus _how_
exactly to fix them.
In prerm:
if [ $1 = remove ] || [ $1 = deconfigure ] ; then
update-alternatives --remove tf /usr/bin/tf5
fi
is correct I think. The possible invocations of
On Sun, 2012-09-23 at 10:03:29 -0700, Russ Allbery wrote:
In prerm:
if [ $1 = remove ] || [ $1 = deconfigure ] ; then
update-alternatives --remove tf /usr/bin/tf5
fi
is correct I think. The possible invocations of prerm are:
prerm remove
old-prerm upgrade new-version
Guillem Jover guil...@debian.org writes:
A deconfigure happens for three reasons, Configure + Depends (other
package removal), Breaks and M-A:same instances syncing.
That's the only problematic and tricky maintainer script case I see,
because due to the way dpkg and apt (or other frontends)
* Colin Watson cjwat...@debian.org, 2008-03-12, 10:00:
I recently ran into this yet again, with a set of packages (scim et al)
calling update-alternatives --remove in 'prerm upgrade', and thereby
breaking user configuration on every upgrade. I do not think that the
issue has got significantly
On Thu, Sep 20, 2012 at 05:00:27PM +0200, Jakub Wilk wrote:
* Colin Watson cjwat...@debian.org, 2008-03-12, 10:00:
I recently ran into this yet again, with a set of packages (scim
et al) calling update-alternatives --remove in 'prerm upgrade',
and thereby breaking user configuration on every
On Tue, 18 Mar 2008, Ian Jackson wrote:
Steve Langasek writes (Re: Bug#71621: Policy on update-alternatives still
needed):
On Sat, Mar 15, 2008 at 05:25:56PM +, Ian Jackson wrote:
* retain the manual configuration but simply not use it when
then user's manual selection
Steve Langasek writes (Re: Bug#71621: Policy on update-alternatives still
needed):
On Sat, Mar 15, 2008 at 05:25:56PM +, Ian Jackson wrote:
* retain the manual configuration but simply not use it when
then user's manual selection is unavailable.
That sounds more promising to me
On Sat, Mar 15, 2008 at 05:25:56PM +, Ian Jackson wrote:
Colin Watson writes (Bug#71621: Policy on update-alternatives still needed):
Based on the analysis I did back in 2000, which I think is still largely
sound, I think that policy should recommend that 'update-alternatives
--remove
Colin Watson writes (Bug#71621: Policy on update-alternatives still needed):
Based on the analysis I did back in 2000, which I think is still largely
sound, I think that policy should recommend that 'update-alternatives
--remove' must not be called in any of prerm upgrade, prerm
failed-upgrade
reopen 71621
thanks
I recently ran into this yet again, with a set of packages (scim et al)
calling update-alternatives --remove in 'prerm upgrade', and thereby
breaking user configuration on every upgrade. I do not think that the
issue has got significantly better in the 7.5 years since I
11 matches
Mail list logo
