Comment 2 for bug 75332

Package: aptitude
Version: 0.2.11.1-2
Followup-For: Bug #137771

Hi Daniel,

I just wanted to followup on

a)#137771, the bug which Joey Hess earlier reported.

I have noticed this problem as well, and the related issue

b) that if you put a package (say foo) on hold in the traditional way,
# echo "foo hold" | dpkg --set-selections
this is completely ignored by aptitude.

This works with apt-get, and people moving from apt-get to aptitude
are going to expect this behaviour. Looking at the Debian user lists
this is the most popular way of putting a package on hold.

>From what Joey Hess says, it appears that this information is stored
in the file /var/lib/dpkg/status. I don't know much about how dpkg
works, but this is confirmed by my own observations.

Anyway, it seems that apt-get does not store the held state of
packages internally. Instead, it reads /var/lib/dpkg/status.

Currently, aptitude stores the held status of packages in some
internal database. I am guessing this may be
/var/lib/aptitude/pkgstates. Would it not be best if it behaved like
apt-get, ie. reading information from /var/lib/dpkg/status?

This would solve a) and b) at one go. Anything else would mean that
dpkg/apt-get were not aware of when a package was being held by
aptitude and vice-versa. Note this is based on my understanding, which
may be incorrect.

I see that you responded to Joey Hess's report saying the bug had been
fixed, but it is still open, and I certainly see the behaviour he
reported. Also, I don't understand your reply to him. You say

"The running of apt-listchanges is harmless, and occurs because
aptitude doesn't check whether anything is to be done before telling
apt to install/remove packages (so all the hooks get called)
This will also occur if, eg, you run an "upgrade" when nothing is
upgradable."

Could you spell this out for me, please?

I have another side comment. When I put a package (say slrn) on hold,
then when I run apt-get install slrn I get

The following held packages will be changed:
  slrn
The following packages will be upgraded
  slrn

It seems that directly doing an install forces a change in the status
of the package. This might be described as a "soft hold".

The behaviour of aptitude using its own hold is similar, except that
it does not warn about the package having being in the held state. (It
might be a good idea to add a warning as apt-get does). This might be
called a "softer hold". :-)

I would like to see a "hard hold", where short of explicitly unholding
the package, the package will not be upgraded. This would make it
unlikely that you would accidentally nuke a painfully hand-compiled
(over several hours) package :-) Perhaps you could put a config
option, to toggle the behaviour of aptitude between a "soft" and
"hard" hold.

Are you planning to work actively on aptitude over the summer?

                                 Best regards, Faheem Mitha.

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux Chrestomanci 2.2.19pre17 #1 Tue Mar 13 22:37:59 EST 2001 i686
Locale: LANG=C, LC_CTYPE=C

Versions of packages aptitude depends on:
ii apt [libapt-pkg-libc6.2- 0.5.4 Advanced front-end for dpkg
ii libc6 2.2.5-4 GNU C Library: Shared libraries an
ii libncurses5 5.2.20020112a-7 Shared libraries for terminal hand
ii libsigc++0 1.0.4-3 Type-safe Signal Framework for C++
ii libstdc++2.10-glibc2.2 1:2.95.4-7 The GNU stdc++ library