[Aptitude-devel] Bug#721426: aptitude: packages are sometimes selected for upgrade by default just after aptitude is started

Wed Mar 9 14:14:03 UTC 2016

Control: tags -1 + moreinfo

(Tagging it +moreinfo not necessarily because needing more info from
submitter, but to separate it from the hundreds of other open reports
and to mark it as "needs further consideration", "work-in-progress" or
similar).

Hi,

2016-03-09 11:46 Vincent Lefevre:
>Control: reopen -1
>Control: found -1 0.7.8-1
>
>On 2016-03-01 18:32:44 +0000, Manuel A. Fernandez Montecelo wrote:
>> 2016-03-01 17:43 Vincent Lefevre:
>> > On 2016-03-01 15:02:59 +0000, Manuel A. Fernandez Montecelo wrote:
>> > > 2013-08-31 12:41 Vincent Lefevre:
>> > > > When I start "aptitude" (no arguments, curses interface), packages are
>> > > > sometimes selected for upgrade by default, for no apparent reason.
>> > > > Since this behavior is not documented in the man page, I assume that
>> > > > this is a bug.
>> > > >
>> > > > Such packages are sometimes in a broken state, which is annoying.
>> > >
>> > > Has this been happening in recent versions?  I have not experience this
>> > > behaviour, at least not in the last few months/years.
>> >
>> > I don't think this happened recently. Well, I can't remember,
>> > so that I assume that this didn't happen recently.
>>
>> I assume that if it starts to happen again you or somebody else will
>> report it; so I think that it's better to close this report.
>
>It has just happened again!

Thanks for the follow-up and the detailed analysis, by the way.

>The packages selected by default:
>
>iuA libsmbclient               2:4.3.5+dfsg-3           2:4.3.6+dfsg-1
>iu  libwbclient0               2:4.3.5+dfsg-3           2:4.3.6+dfsg-1
>iuA samba-libs       +28.7 kB  2:4.3.5+dfsg-3           2:4.3.6+dfsg-1
>
>See the attached screenshot.
>
>Before running aptitude, I changed the mirror in /etc/apt/sources.list
>due to Hash Sum mismatch errors (reported as Debian bug 817240), and
>did "apt-get update". But this is probably not related, if the issue
>comes from /var/lib/aptitude/pkgstates, which dates from before the
>previous upgrade (see below).

(I think that this is related in a way, see later).

>The previous upgrade (from /var/log/aptitude):
>
>Aptitude 0.7.8: log report
>Wed, Mar  9 2016 11:16:07 +0100
>
>  IMPORTANT: this log only lists intended actions; actions which fail
>  due to dpkg problems may not be completed.

^ Note message about "intended actions".

>Will install 42 packages, and remove 0 packages.
>346 kB of disk space will be used
>========================================
>[HOLD, DEPENDENCIES] default-jre:amd64 2:1.7-52.1
>[HOLD, DEPENDENCIES] default-jre-headless:amd64 2:1.7-52.1
>[HOLD] fvwm:amd64 1:2.5.30.ds-1.1+local1
>[UPGRADE] clang-3.8:amd64 1:3.8-1 -> 1:3.8-2
>[UPGRADE] clang-3.8-doc:amd64 1:3.8-1 -> 1:3.8-2
>[UPGRADE] firebird2.5-common:amd64 2.5.5.26952.ds4-3 -> 2.5.5.26952.ds4-4
>[UPGRADE] firebird2.5-common-doc:amd64 2.5.5.26952.ds4-3 -> 2.5.5.26952.ds4-4
>[UPGRADE] firebird2.5-server-common:amd64 2.5.5.26952.ds4-3 -> 2.5.5.26952.ds4-4
>[UPGRADE] libclang-common-3.8-dev:amd64 1:3.8-1 -> 1:3.8-2
>[UPGRADE] libclang1-3.8:amd64 1:3.8-1 -> 1:3.8-2
>[UPGRADE] libdebconfclient0:amd64 0.206 -> 0.207
>[UPGRADE] libfbclient2:amd64 2.5.5.26952.ds4-3 -> 2.5.5.26952.ds4-4
>[UPGRADE] libfbembed2.5:amd64 2.5.5.26952.ds4-3 -> 2.5.5.26952.ds4-4
>[UPGRADE] libllvm3.8:amd64 1:3.8-1 -> 1:3.8-2
>[UPGRADE] libnspr4:amd64 2:4.11-1 -> 2:4.12-1
>[UPGRADE] libopencv-calib3d2.4v5:amd64 2.4.9.1+dfsg-1.3 -> 2.4.9.1+dfsg-1.4
>[UPGRADE] libopencv-contrib2.4v5:amd64 2.4.9.1+dfsg-1.3 -> 2.4.9.1+dfsg-1.4
>[UPGRADE] libopencv-core2.4v5:amd64 2.4.9.1+dfsg-1.3 -> 2.4.9.1+dfsg-1.4
>[UPGRADE] libopencv-features2d2.4v5:amd64 2.4.9.1+dfsg-1.3 -> 2.4.9.1+dfsg-1.4
>[UPGRADE] libopencv-flann2.4v5:amd64 2.4.9.1+dfsg-1.3 -> 2.4.9.1+dfsg-1.4
>[UPGRADE] libopencv-highgui2.4v5:amd64 2.4.9.1+dfsg-1.3 -> 2.4.9.1+dfsg-1.4
>[UPGRADE] libopencv-imgproc2.4v5:amd64 2.4.9.1+dfsg-1.3 -> 2.4.9.1+dfsg-1.4
>[UPGRADE] libopencv-legacy2.4v5:amd64 2.4.9.1+dfsg-1.3 -> 2.4.9.1+dfsg-1.4
>[UPGRADE] libopencv-ml2.4v5:amd64 2.4.9.1+dfsg-1.3 -> 2.4.9.1+dfsg-1.4
>[UPGRADE] libopencv-objdetect2.4v5:amd64 2.4.9.1+dfsg-1.3 -> 2.4.9.1+dfsg-1.4
>[UPGRADE] libopencv-video2.4v5:amd64 2.4.9.1+dfsg-1.3 -> 2.4.9.1+dfsg-1.4
>[UPGRADE] libsmbclient:amd64 2:4.3.5+dfsg-2 -> 2:4.3.5+dfsg-3
>[UPGRADE] libwbclient0:amd64 2:4.3.5+dfsg-2 -> 2:4.3.5+dfsg-3

^ These are the versions (I think that they are only shown since
recently, one of the additions of the 0.7 series), upgraded to
"2:4.3.5+dfsg-3".

>[UPGRADE] llvm-3.8:amd64 1:3.8-1 -> 1:3.8-2
>[UPGRADE] llvm-3.8-dev:amd64 1:3.8-1 -> 1:3.8-2
>[UPGRADE] llvm-3.8-runtime:amd64 1:3.8-1 -> 1:3.8-2
>[UPGRADE] mksh:amd64 52b-1 -> 52c-1
>[UPGRADE] nano:amd64 2.5.3-1 -> 2.5.3-2
>[UPGRADE] openssh-client:amd64 1:7.1p2-2 -> 1:7.2p1-1
>[UPGRADE] openssh-server:amd64 1:7.1p2-2 -> 1:7.2p1-1
>[UPGRADE] openssh-sftp-server:amd64 1:7.1p2-2 -> 1:7.2p1-1
>[UPGRADE] pax:amd64 1:20151013-1 -> 1:20160306-1
>[UPGRADE] ruby-domain-name:amd64 0.5.20160216-1 -> 0.5.20160216-2
>[UPGRADE] samba-libs:amd64 2:4.3.5+dfsg-2 -> 2:4.3.5+dfsg-3

^ Same comment as above

>[UPGRADE] x11-common:amd64 1:7.7+13 -> 1:7.7+14
>[UPGRADE] xbase-clients:amd64 1:7.7+13 -> 1:7.7+14
>[UPGRADE] xorg:amd64 1:7.7+13 -> 1:7.7+14
>[UPGRADE] xserver-xorg:amd64 1:7.7+13 -> 1:7.7+14
>[UPGRADE] xserver-xorg-input-all:amd64 1:7.7+13 -> 1:7.7+14
>[UPGRADE] xserver-xorg-video-all:amd64 1:7.7+13 -> 1:7.7+14
>========================================
>
>Log complete.
>
>In /var/log/apt/history.log:
>
>Start-Date: 2016-03-09  11:16:46
>Upgrade: xserver-xorg-input-all:amd64 (7.7+13, 7.7+14), xserver-xorg:amd64 (7.7+13, 7.7+14), llvm-3.8:amd64 (3.8-1, 3.8-2), ruby-domain-name:amd64 (0.5.20160216-1, 0.5.20160216-2), clang-3.8:amd64 (3.8-1, 3.8-2), libopencv-imgproc2.4v5:amd64 (2.4.9.1+dfsg-1.3, 2.4.9.1+dfsg-1.4), libopencv-objdetect2.4v5:amd64 (2.4.9.1+dfsg-1.3, 2.4.9.1+dfsg-1.4), libwbclient0:amd64 (4.3.5+dfsg-2, 4.3.5+dfsg-3), libopencv-video2.4v5:amd64 (2.4.9.1+dfsg-1.3, 2.4.9.1+dfsg-1.4), firebird2.5-common:amd64 (2.5.5.26952.ds4-3, 2.5.5.26952.ds4-4), libclang-common-3.8-dev:amd64 (3.8-1, 3.8-2), nano:amd64 (2.5.3-1, 2.5.3-2), openssh-sftp-server:amd64 (7.1p2-2, 7.2p1-1), libfbclient2:amd64 (2.5.5.26952.ds4-3, 2.5.5.26952.ds4-4), libclang1-3.8:amd64 (3.8-1, 3.8-2), firebird2.5-common-doc:amd64 (2.5.5.26952.ds4-3, 2.5.5.26952.ds4-4), libfbembed2.5:amd64 (2.5.5.26952.ds4-3, 2.5.5.26952.ds4-4), libopencv-flann2.4v5:amd64 (2.4.9.1+dfsg-1.3, 2.4.9.1+dfsg-1.4), libopencv-contrib2.4v5:amd64 (2.4.9.1+dfsg-1.3, 2.4.9.1+dfsg-1.4), libopencv-highgui2.4v5:amd64 (2.4.9.1+dfsg-1.3, 2.4.9.1+dfsg-1.4), libllvm3.8:amd64 (3.8-1, 3.8-2), samba-libs:amd64 (4.3.5+dfsg-2, 4.3.5+dfsg-3), pax:amd64 (20151013-1, 20160306-1), xbase-clients:amd64 (7.7+13, 7.7+14), firebird2.5-server-common:amd64 (2.5.5.26952.ds4-3, 2.5.5.26952.ds4-4), libopencv-calib3d2.4v5:amd64 (2.4.9.1+dfsg-1.3, 2.4.9.1+dfsg-1.4), libopencv-legacy2.4v5:amd64 (2.4.9.1+dfsg-1.3, 2.4.9.1+dfsg-1.4), xserver-xorg-video-all:amd64 (7.7+13, 7.7+14), clang-3.8-doc:amd64 (3.8-1, 3.8-2), openssh-server:amd64 (7.1p2-2, 7.2p1-1), libsmbclient:amd64 (4.3.5+dfsg-2, 4.3.5+dfsg-3), xorg:amd64 (7.7+13, 7.7+14), openssh-client:amd64 (7.1p2-2, 7.2p1-1), llvm-3.8-dev:amd64 (3.8-1, 3.8-2), libopencv-core2.4v5:amd64 (2.4.9.1+dfsg-1.3, 2.4.9.1+dfsg-1.4), mksh:amd64 (52b-1, 52c-1), libopencv-ml2.4v5:amd64 (2.4.9.1+dfsg-1.3, 2.4.9.1+dfsg-1.4), x11-common:amd64 (7.7+13, 7.7+14), libopencv-features2d2.4v5:amd64 (2.4.9.1+dfsg-1.3, 2.4.9.1+dfsg-1.4), libnspr4:amd64 (4.11-1, 4.12-1), llvm-3.8-runtime:amd64 (3.8-1, 3.8-2), libdebconfclient0:amd64 (0.206, 0.207)
>End-Date: 2016-03-09  11:17:13

Apt's log, same versions involved as above.

>Note that the libsmbclient, libwbclient0 and samba-libs packages were
>upgraded in this previous upgrade.
>
>I've also attached the corresponding part of /var/log/dpkg.log
>and /var/log/apt/term.log files.
>
>I have:
>
>-rw-r--r-- 1 9536507 2016-03-09 11:15:43 /var/lib/aptitude/pkgstates
>-rw-r--r-- 1 9526471 2016-03-08 09:38:42 /var/lib/aptitude/pkgstates.old
>
>Note that /var/lib/aptitude/pkgstates dates from before the upgrade.
>Is that correct?

Kind of yes (see later).

>For samba-libs, in pkgstates.old:
>
>Package: samba-libs
>Architecture: amd64
>Unseen: no
>State: 1
>Dselect-State: 1
>Remove-Reason: 4
>
>and in pkgstates:
>
>Package: samba-libs
>Architecture: amd64
>Unseen: no
>State: 1
>Dselect-State: 1
>Remove-Reason: 4
>Upgrade: yes
>
>Ditto for libwbclient0. But for libsmbclient,
>
>Package: libsmbclient
>Architecture: amd64
>Unseen: no
>State: 1
>Dselect-State: 1
>Remove-Reason: 0
>
>and
>
>Package: libsmbclient
>Architecture: amd64
>Unseen: no
>State: 1
>Dselect-State: 1
>Remove-Reason: 0
>Upgrade: yes
>
>respectively.

What's the difference between them?  "Upgrade: yes" is the same in
pkgstates.old and pkgstates, respectively.

(If you mean the "remove reason" might be correct or a small
incorrection but probably without any practical consequence for this
case).

2016-03-09 12:05 Vincent Lefevre:
>On 2016-03-09 12:46:04 +0100, Vincent Lefevre wrote:
>> I have:
>>
>> -rw-r--r-- 1 9536507 2016-03-09 11:15:43 /var/lib/aptitude/pkgstates
>> -rw-r--r-- 1 9526471 2016-03-08 09:38:42 /var/lib/aptitude/pkgstates.old
>>
>> Note that /var/lib/aptitude/pkgstates dates from before the upgrade.
>> Is that correct?
>
>Actually before 20 seconds before beginning of the log report of the
>upgrade.
>
>$ grep -B 7 'Upgrade: yes' pkgstates | grep 'Package:' | sort
>Package: clang-3.8
>[...]
>Package: xserver-xorg-video-all
>
>They correspond to the upgraded packages. This seems to be a bug to
>still have 'Upgrade: yes' after the upgrade.
>
>Shouldn't aptitude have removed the 'Upgrade: yes' after the upgrade?
>(In case of failure, keep only those corresponding to the packages
>that couldn't be upgraded.)

As with the message in the logs, aptitude has an habit to save things or
declare in the logs what it would do, because it's not always clear what
will happen with the tools doing the actual work.

These generic routines saving the state are the same used when one quits
without proceeding with the action, etc, to have "saved actions" for the
next session.

It can also happen that aptitude gets killed at some point between "the
user decides to proceed" and "dpkg does the job", or perhaps the user
"control-c" when asked to "press any key to continue", there are people
doing that (#246672 and #296726).

Did you by some chance do that, or are aware that aptitude crashed after
running dpkg?

It is when aptitude re-reads the state of the system after dpkg actions
(obviously, if not killed) that a new pkgstates might be written.  Every
time that it is relaunched the state is re-read, as well.  Then it
compares the state of the system with the saved intentions the last time
that he saw them, and tries to honour them if they still apply. Things
might have been moved around since the last time that aptitude saved the
state.

For example, in your case, changing the mirror and finding a new version
(were upgraded to "2:4.3.5+dfsg-3", but the new version is
"2:4.3.6+dfsg-1") while the packages are still recorded for Upgrade,
will keep them marked for upgrade.

aptitude should have marked them as having been upgraded after
re-reading the state after dpkg was run and before changing mirrors and
updating available packages, but if there was a problem for some reason
that aptitude crashed or the package could not be written (or if there's
a bug and "upgrade-already-done" is not considered a reason to save the
pkgstates again), they can still be marked to upgrade.

Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>