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 <da...@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
signature.asc
Description: Digital signature
