[Aptitude-devel] Bug#710587: Bug#710587: aptitude: unable to purge a package

[David Kalnischkies]

On Wed, Sep 09, 2015 at 11:23:49AM +0100, Manuel A. Fernandez Montecelo wrote:
> 2015-09-09 7:07 GMT+01:00 David Kalnischkies <david at kalnischkies.de>:
> > On Tue, Sep 08, 2015 at 03:40:20PM +0100, Manuel A. Fernandez Montecelo wrote:
> >> Is this with multi-arch enabled?  gnotski is now a transitional package,
> >> arch all, added on 25 May 2013 (very close to when the bug report
> >> happened), it must have been arch-dependent before.
> > […]
> >> So I am not sure about what was wrong at the time, but I think that this
> >> bug is not present anymore.
> >
> > This sounds like this bug:
> > https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=016bea8214e1826b289025f03890f70a5805db87
> > Note that it is only in /experimental, so with /unstable it should be
> > reproducible if its really this issue.
> 
> Thanks for the input, David.  I also think that this is the cause of
> this bug report.
> 
> In experimental... do you mean that it's been only added in apt-1.1,
> never released to unstable yet?  By the date I thought that it made it
> to the last stable release, Jessie.  Or is it one of these changes
> that you requested but weren't approved by the release team?

Yeap, it is only in 1.1 with the 'twist' that I never asked the release
team partly because it wasn't important and partly because I simply
forget it.


> The original systems where this was found already changed state, and
> at least in one they use unstable and experimental.  The last report
> was in in 2014, more than a year ago, and the submitters didn't
> consider this a problem anymore (so I assume that it got fixed in
> their system somehow, possibly because they use the experimental
> versions; or maybe they purged by hand by dpkg and forgot about it,
> or...).

The worst thing which can happen is that you can't purge the package
which you had previously removed only with a program using buggy libapt.
In the worst case, usually it will work.  The bug in the code is that it
does only look at the first source of each version if this source is the
dpkg/status file (= that is the "now" archive and the only place
a package with only configuration files left on disk can be).  So, this
easily fixes itself with time e.g. by the release of a new package
version – as a new version will be in the archive, the only source for
the old version left is the dpkg/status file, so even the buggy code
finds the correct architecture (even a broken clock is right twice
a day).


> I think that it's better to leave it closed, but is is good to confirm
> that this issue was very likely the cause behind it.

Feel free to keep the closed bug on your score card – after all you did
the bulk of the triage work and I am not THAT desperate to win to start
stealing done bugs. ;)

I was just commenting in case you stumble over another instance of this.
I have the feeling that apt users are trained to use "dpkg -P" for
purging previously removed packages as apt didn't support this for quite
a while (something like squeeze I think, so "new feature" in apt terms
– as the bug is a caused by multiarch the bug should at least exist
since squeeze).  Given that this "always" worked for aptitude I guess
your users don't have the same training and hence encounter this more
often. Case in point: This bug has a merged duplicate already.


Best regards

David Kalnischkies
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/aptitude-devel/attachments/20150909/4ddd970f/attachment.sig>