[Aptitude-devel] Bug#782871: apt (1.0.9.8) prevents aptitude handling forget-new properly.

[Hae-woo Park]

[Since bug 782871 and 782777 are merged, so I replied to both 782871@
and 782777 at .]

Thank you so much for your kind and detailed explanation, David.

I agree that this bug is really weird.
Actually I _roughly_ checked the diff between 1.0.9.7 and 1.0.9.8
before submitting the bug.
However it was my first time to check the diff in the Debian git
repository, so I thought I missed some changes.
As you told, it seems that the changes should not cause this kind of problem.

Anyway let me explain more.
In my case, I have only sid repository in my sources.list,
while the other reporters said that they had experimental as well.
However the package I have the problem on includes libgcc-4.9-dev
which is mentioned in bug 782777.

IMHO, if there're really small change lists between 1.0.9.7 and 1.0.9.8,
then we can test with patching changes one-by-one.

Thanks.



2015-04-19 19:00 GMT+09:00 David Kalnischkies <david at kalnischkies.de>:
> Control: reassign -1 aptitude
> Control: forcemerge 782777 -1
> Control: affects -1 apt
>
> On Sun, Apr 19, 2015 at 01:00:59PM +0900, Hae-woo Park wrote:
>> Recently I upgraded the following packages from 1.0.9.7 to 1.0.9.8:
>> apt, apt-utils, libapt-inst1.5, libapt-pkg4.12. (I am using sid.)
>>
>> After then aptitude could not handle 'forget-new' (and 'markauto'?) properly.
>> When type 'f' (or 'M') for those instruction in aptitude, it seems working;
>> but after restarting aptitude the status went back.
>> Note that the 'markauto' issue was tested only with 'new' packages.
>>
>> So now I've rolled back those 4 packages,
>> and aptitude properly forgets the new packages by 'forget-new'.
>
> This wierdness is discussed over at aptitude with #782777, so I am
> merging with it and let you guys figure it out because I can't reproduce
> it here with "pure" apt(-mark) and this aptitude thingy is pure black
> magic for my eyes and ears (on of these days I might start it).
>
>
> From what I read there it isn't clear to me that a downgrade actually
> fixes things. It seems more to "fumble around" stuff so that it pops up
> someplace else.
>
>
> My biggest problem with it is through that nothing in the vincity of the
> autobit handling changed in 1.0.9.8. Not even close to it.
>
>
> The closest is maybe "parse specific-arch dependencies correctly on
> single-arch systems", but that just because it is the binary cache
> creation changed, which is state potentially shared between different
> versions of libapt, but is reshuffled on 'update' and at least partly
> with every change to the dpkg/status.
>
> I didn't invalidate the cache with a version bump, which from a (very)
> theoretical standpoint is incorrect, but that just means you are
> effected by the bug this commit is fixing until after the cache is
> invalidated next (given that just one package satisfying the criteria
> exists at all in all of Debian, that isn't as bad as it might sound
> – especially as the fix is for jessie and this one package is sid only).
> That is working the other way around, too, through as a downgrade isn't
> breaking it again instantly either. What I can see is that the two
> reporters who provided the information are single-arch systems, so they
> would be effected by this bug, for multi-arch systems nothing changed.
>
>
> Now, all that being said, this bears no relation to 'new' nor 'auto' as
> this is about dependencies being created incorrectly. At the most its
> "removing" packages as this bug created package structures with a bad
> name so they couldn't be found later, but that also means these bad
> packages never had a version belonging to it and I doubt aptitude
> considers those as new (and they are gone now, not added, so if
> anything, 1.0.9.8 would fix it…).
>
> But yes, its the best I got, even through I have no idea what could be
> it as the other fixes I would consider even less likely to influence the
> outcome of aptitude than the current moon phase:
> - apt-key changes do not effect aptitude at all
> - VectorizeString is called by aptitude only in mkdir_parents,
>   which is itself never called by aptitude…
> - WriteApportReport is disabled in Debian by default, called only by
>   libapt itself and only as a reaction to a dpkg error while stuff is
>   installed. Also, its a crash fix…
> - pkgAcquire::Item::Mode is another crash fix, a crash theoretically not
>   happening and indeed never happening for 5 years in C++ code. Only
>   python3 seems to manage to trigger it. Also only acts while stuff is
>   being fetched from the interwebs.
> - https is, well, a seperate binary never called directly by aptitude,
>   nor does it see the communication with it. Used also only while
>   fetching stuff from the (encrypted) interweb.
> - a typo in the commandline parsing of apt-get.
>
> And that was it, all 7 changes in 1.0.9.8.
>
> Fun fact: This mail has more lines than 2 times the amount of changed
> code lines (which itself counts changes twice as one line added and one
> line removed) in the diff between 1.0.9.7 and 1.0.9.8.
>
>
> Best regards
>
> David Kalnischkies