Guillem Jover 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) interact,
> dec
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-ver
Jakub Wilk 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 prerm are:
* Bill Allombert , 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 them.
But I'll post list of affected
On Thu, Sep 20, 2012 at 05:00:27PM +0200, Jakub Wilk wrote:
> * Colin Watson , 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
* Colin Watson , 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 better in the 7.5 ye
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 w
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.
&
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
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
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 origina
11 matches
Mail list logo
