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