Control: severity 328616 important Control: tags 328616 + confirmed Control: forcemerge 328616 -1
Hi Bernhard, 2011-11-10 14:08 Bernhard Schmidt:
Package: aptitude Version: 0.6.4-1.2 Severity: normal Dear Maintainer, I already asked for this on the debian-users mailinglist and got replies from people having the same issue http://permalink.gmane.org/gmane.linux.debian.user/421736 I have a weird problem where my google foo is failing me (although I guess it has been seen more than once before). Long story short, I have a configuration management software (puppet) that purges selective packages on each run (among others os-prober). It is (by default) using apt for this task. When I execute aptitude interactively on one of those handled servers after that, it always wants to reinstall os-prober. It does not show so in the listing, but it says 'Will use 193 kB of disk space' and shows os-prober in the 'Packages to be installed' block after pressing 'g'. I have to deselect it there manually with '-' or ':' to get rid of it forever. It seems to be related with the Apt::Install-Recommends setting, if I set that to False the behaviour is gone. But I like recommends for now. It is easily reproducible on both Squeeze and Wheezy: # apt-get install os-prober # aptitude (see that there is nothing to do) # apt-get purge os-prober # aptitude (see that it wants to install os-prober) I have not seen an explicit bug for it, but the 816 open bugs on aptitude are somewhat hard to browse. Is this a known issue or works-as-designed?
I do not blame you for not finding duplicates among the 816 open bugs at the time :-) But I think that this problem is a duplicate of #328616, from at least 2005 (exactly 10 years ago today). Aptitude has a different database for saving the state of packages, and considers it more authoritative than dpkg's. So what I believe that happens above is that: 1) "apt-get install" adds the dpkg to dpkg-status as "selected to install" 2) the first invokation of aptitude reads this, and registers it in its internal db as "to install", as if it was marked as such within aptitude 3) then "apt-get purge" removes it from dpkg-status, so the selected state for this package is "unknown" (dpkg does clean-up and doesn't keep the package around as "to purge" or some such, once it has been purged) 4) the second run of aptitude thinks that the package was marked as "to install" in a previous run of aptitude, because the package is "unknown" to dpkg, and so wants to install it again I don't think that it's related to Install-Recommends, because I have the option disabled but I can reproduce it anyway. I don't know why it worked different from you when disabling Apt::Install-Recommends, maybe it was the interleaving order in which aptitude read the status of the dpkg db. But the bug is reproducible for other people irrespective of this setting. So I hope that I am not wrong and I am merging the bug reports; but it would be great if you keep an eye on this, and if/when the bug is closed you can confirm whether it fixed the problems that you are observing. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
