aptitude pkgstates gets corrupted

[Sergio Callegari]

Binary package hint: aptitude

On four different machines (one 32 bit, two 64bit), I am recently experiencing corruptions in the package status database private to aptitude, namely /var/lib/aptitude/pkgstates.

This results in a crazy behavior of aptitude, that starts thinking that many packages are broken when in fact they are not. For instance.

aptitude install
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
The following packages are BROKEN:
  apturl gnome-app-install libgpod4 libgpod4-nogtk mysql-server-core-5.1 rsyslog wine1.2
The following NEW packages will be installed:
  acl binutils-static emacs22 emacs22-bin-common emacs22-common firefox-3.0-branding gcj-4.3
  gfortran-4.3 gij gnome-mount imagemagick-doc klogd libavutil-unstripped-49
  libboost-regex1.34.1 libboost-serialization1.34.1 libfame-0.9 libgcj9-0-awt libgcj9-dev
  libggi-target-x libggi2 libgii1 libgii1-target-x libgmyth0 liblrdf0 libpolkit-gnome0
  libpvm3 libsmbios2 libsoprano-dev libwxbase2.6-0 libwxgtk2.6-0 mysql-server-core-5.0
  nvidia-180-kernel-source nvidia-180-libvdpau policykit-gnome pvm python-gconf
  python-gst0.10 python-launchpad-integration python-pyorbit python-sexy sysklogd
  ttf-bengali-fonts ttf-kannada-fonts ttf-oriya-fonts ttf-telugu-fonts update-motd wine
  wine-gecko

This is very very dangerous, because, following up with its crazy diagnosis, aptitude starts suggesting actions that can completely break a system.

And the crazyness of aptitude can be very easily seen by considering that for apt-get, synaptic and all the other front-ends to dpkg everything is just fine.

Interestingly, aptitude starts reporting as broken either packages that are installed and packages that are not installed. If one tries an

aptitude remove <package that is not installed but is reported as broken>

then aptitude does nothing, but the behavior of aptitude after this sanifies a bit.

removing /var/lib/aptitude/pkgstates completely fixes the issue.

In the "wrong" pkgstates, it looks like many entries are just weird. For instance, installed packages are indicated as unseen, and after pkgstates is removed and re-generated, for many packages the state is then different.

I tend to think that bug reports 477468 and 39497 are in fact caused by this very problem, so I suggest marking those as duplicate of this one.

ProblemType: Bug
Architecture: amd64
Date: Wed Jan 6 12:47:37 2010
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: aptitude 0.4.11.11-1ubuntu6
ProcVersionSignature: Ubuntu 2.6.31-16.53-generic
SourcePackage: aptitude
Uname: Linux 2.6.31-16-generic x86_64

[Sergio Callegari (callegar)]

... the beginning should have been "on four different machines (one 32bit, *three* 64bit).

I was forgetting to say that all result from upgrades from jaunty. None is a fresh install.

[Sergio Callegari (callegar)]

The thing re-happens whenever synaptic is used to install/remove something.

So, if aptitude is conflicting with synaptic and apt-get, please let it be marked clearly as such.

[Sergio Callegari (callegar)]

I guess that invalidation of the bug comes after the long time elapsed since its initial reporting and the subsequent inactivity.

Since reporting, I have simply stopped using aptitude, moving to apt-get, so I do not have any test case, nor I know if the bug is still valid.

However, I wonder if before declaring the bug invalid, the logic in aptitude has been evaluated with respect to the possibility of something changing behind his back in the installed packages due to the usage of another package manager.

If aptitude only relies on its own view of the installed packages (which might not reflect the actual situation of the installed packages due to the use of another package manager between two aptitude invocations) then its usage can become dangerous and IMHO the users should at least be warned about it.

[Sergio Callegari (callegar)]

Just checked...

This bug is NOT fixed.

running

aptitude install

on my current system, which is perfectly up to date according to apt-get, synaptic, apper, muon, the ubuntu update manager, whatever, provides the usual crazy output:

The following NEW packages will be installed:
  anthy-common byobu{b} cl-asdf common-lisp-controller{b} cpu-checker docbook-xsl-doc-html fancontrol gcj-4.6-jre-lib hal-info icc-profiles-free
  kdebase-workspace kdegraphics-libs-data kpackagekit{b} lib32bz2-1.0 lib32ffi6 lib32ncurses5 lib32ncursesw5 lib32nss-mdns lib32tinfo5
  libaccess-bridge-java libbcmail-java libgnome2-common libgnuinet-java libgnujaf-java libgnumail-java libitext-java libreoffice-common{b}
  libreoffice-emailmerge{b} libreoffice-style-human{b} libreoffice-style-oxygen{b} python-foolscap python-serial python-twisted-core{b}
  python-twisted-names python-twisted-web qdbus{b} sni-qt system-config-samba texmacs-extra-fonts ttf-dejavu ttf-sazanami-mincho ubufox xfonts-100dpi
The following packages are RECOMMENDED but will NOT be installed:
  libaccess-bridge-java-jni libexttextcat-data python-openssl python-pam tmux
0 packages upgraded, 43 newly installed, 0 to remove and 0 not upgraded.
Need to get 65,1 MB of archives. After unpacking 140 MB will be used.
The following packages have unmet dependencies:
 byobu : Depends: python-newt (>= 0.52.2-11) but it is not going to be installed.
 kpackagekit : Depends: apper but it is not going to be installed.
 qdbus : Conflicts: qdbus:i386 but 4:4.8.1-0ubuntu4.2 is installed.
 qdbus:i386 : Conflicts: qdbus but 4:4.8.1-0ubuntu4.2 is to be installed.
 texmacs-common : Conflicts: texmacs-extra-fonts (<= 0.2) but 0.2 is to be installed.
 libreoffice-common : Depends: ure but it is not going to be installed

....

and so on for hundreds of lines, with crazy suggestions about how to fix the system...

Have this been tried on other systems before invalidating the bug?

[Daniel Hartwig (wigs)]

On 4 September 2012 00:51, Sergio Callegari <email address hidden> wrote:
> aptitude install
>
> on my current system, which is perfectly up to date according to apt-
> get, synaptic, apper, muon, the ubuntu update manager, whatever,
> provides the usual crazy output:

Which release and what version of aptitude?

[Daniel Hartwig (wigs)]

On 4 September 2012 00:51, Sergio Callegari <email address hidden> wrote:
> aptitude install

> The following NEW packages will be installed:
> anthy-common byobu{b} cl-asdf common-lisp-controller{b} cpu-checker docbook-xsl-doc-html fancontrol gcj-4.6-jre-lib hal-info icc-profiles-free
> […]

You are running just “aptitude install” with no other arguments to get
this output? This suggests you have marked/scheduled changes waiting
in aptitude, and that “aptitude keep-all” (or “Cancel pending actions”
in the curses interface) should clear this up.

Otherwise please provide a complete and unedited typescript of the
session (you can use script(1) for this).

[Sergio Callegari (callegar)]

Everything is from precise. Namely

aptitude 0.6.6 compiled at Mar 30 2012 17:19:20
Compiler: g++ 4.6.3
Compiled against:
  apt version 4.12.0
  NCurses version 5.9
  libsigc++ version: 2.2.10
  Ept support enabled.
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 5.9.20110404
  cwidget version: 0.5.16
  Apt version: 4.12.0

To see the 'wrong' behavior I am running just 'aptitude install'

The point is exactly that there should be no marked/scheduled changes waiting in aptitude at this point...

If I clean up the scheduled changes in aptitude, then I work for some time (say 1 month) without using aptitude, but just apt-get, synaptic, or apper and after 1 month I go back to saying 'sudo aptitude install', then aptitude shows that mess, probably due to the fact that it is being confused by something that happened behind it shoulders.

IMHO this is dangerous. If some user says 'sudo aptitude install' and then Y, he risks messing up all of its applications, possibly even loosing his desktop due to the funny ways that aptitude proposes to solve imaginary issues in this case.

[Daniel Hartwig (wigs)]

On 4 September 2012 17:41, Sergio Callegari <email address hidden> wrote:
> If I clean up the scheduled changes in aptitude, then I work for some
> time (say 1 month) without using aptitude, but just apt-get, synaptic,
> or apper and after 1 month I go back to saying 'sudo aptitude install',
> then aptitude shows that mess, probably due to the fact that it is being
> confused by something that happened behind it shoulders.

Curious. I have absolutely never experienced that although I do
intermix use of apt-get with aptitude. There are reports of small
scale problems like this, but they only ever have mentioned one or two
packages which were previously installed/removed by aptitude. I will
attempt to recreate this and look in to it.

Do you have something like apticron or cron-apt installed which may be
scheduling updates with aptitude?

Please attach also the output from:

$ sudo apt-config dump -c /root/.aptitude/config -c ~/.aptitude/config

[Sergio Callegari (callegar)]

Getting back on this late... but the bug is still there as of trusty.

No big deal, though. I have found out that it is sufficient to invoke aptitude via a small script that erases pkgstates every time before running the real aptitude. Sort of removes the advantage of having a cache, but better being correct than being fast.

[Sergio Callegari (callegar)]

Even if I am the only one in this bug, see also

http://askubuntu.com/questions/73868/aptitude-state-is-corrupt-how-do-i-fix-it

I think that people have found out that it is enough to remove pkgstates to have a clear start and simply do not care to report the bug.

[Sergio Callegari (callegar)]

See also

https://lists.debian.org/debian-dpkg/2012/03/msg00063.html

where it says

As above, most of pkgstates is actually private to aptitude. Some of
it is duplicated for convenience, however, aptitude does take measures
to keep in sync. with dpkg/apt when it is started. *Admitedly, this
process fails quite often.* (emphasis is mine)

and

For example, removing a package with apt-get can lead to aptitude
trying to reinstall that package. *Note that aptitude is aware that
the package has been removed, it just mistakenly believes the user has
requested it be installed again.*

So, it looks like aptitude is remembering pending actions, even when they are not anymore relevant or applicable.

IMHO, this 'session' idea of aptitude is quite wrong in itself. You just cannot remember pending actions without having a lock on the package database, preventing others from changing the system state. I suggest modifying the packaging of aptitude to set up a cron script erasing pkgstates every night.