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