Bug#137771: aptitude's vs dpkg's hold state

[Axel Beckert]

Hi Daniel,

thanks for your reply. It definitely brings light into the issue!

Daniel Hartwig wrote:
 Basically there are two kinds of package holds:
 - dselect, stored in /var/lib/dpkg/status; and
 - aptitude, stored in /var/lib/aptitude/pkgstates.

Hmm. While you definitely can set and query holds without dselect
being installed, I wonder if dpkg works any different with them. At
least when I stumbled upon it, dpkg seems to let aptitude
happily override dpkg's hold, despite dpkg's man-page says:

   hold   A package marked to be on hold is not handled by dpkg,
  unless forced to do that with option --force-hold.

 When aptitude starts it attempts to divine which dselect holds have
 changed and updates its database accordingly (not perfect). At no
 point does aptitude update the dselect holds when it's own have
 changed.

Real life confirms that:

Thanks to tons of iceweasel versions on mozilla.debian.net, I played
around a little bit (on Squeeze) with downgrading, upgrading and
holding packages and then doing it again. ;-)

# dpkg --get-selections | fgrep iceweasel; dpkg-query -l iceweasel | egrep 
'^[ih]'; aptitude search '^iceweasel$'
iceweasel   install
ii  iceweasel  16.0~b6-1~bpo6 Web browser based on Firefox
i A iceweasel   - Web browser based on Firefox
# echo iceweasel hold | dpkg --set-selections
# dpkg --get-selections | fgrep iceweasel; dpkg-query -l iceweasel | egrep 
'^[ih]'; aptitude search '^iceweasel$'
iceweasel   hold
hi  iceweasel  16.0~b6-1~bpo6 Web browser based on Firefox
ihA iceweasel   - Web browser based on Firefox
# echo iceweasel install | dpkg --set-selections
# dpkg --get-selections | fgrep iceweasel; dpkg-query -l iceweasel | egrep 
'^[ih]'; aptitude search '^iceweasel$'
iceweasel   install
ii  iceweasel  16.0~b6-1~bpo6 Web browser based on Firefox
i A iceweasel   - Web browser based on Firefox  
  

dpkg's holds are handled like hold flags set by aptitude -- but only
until I change something in aptitude. From there on it ignores dpkg's
hold flag:

# dpkg --get-selections | fgrep iceweasel; dpkg-query -l iceweasel | egrep 
'^[ih]'; aptitude search '^iceweasel$'
iceweasel   install
ii  iceweasel  15.0.1-1~bpo60 Web browser based on Firefox
i A iceweasel   - Web browser based on Firefox
# echo iceweasel hold | dpkg --set-selections
# dpkg --get-selections | fgrep iceweasel; dpkg-query -l iceweasel | egrep 
'^[ih]'; aptitude search '^iceweasel$'
iceweasel   hold
hi  iceweasel  15.0.1-1~bpo60 Web browser based on Firefox
ihA iceweasel   - Web browser based on Firefox
# aptitude full-upgrade
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
# aptitude unhold iceweasel
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
# dpkg --get-selections | fgrep iceweasel; dpkg-query -l iceweasel | egrep 
'^[ih]'; aptitude search '^iceweasel$'
iceweasel   hold
hi  iceweasel  15.0.1-1~bpo60 Web browser based on Firefox
i A iceweasel   - Web browser based on Firefox
# aptitude safe-upgrade
The following packages will be upgraded: 
  iceweasel 
1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 2,067 kB of archives. After unpacking 379 kB will be used.
Do you want to continue? [Y/n/?] 
Get:1 http://mozilla.debian.net/ squeeze-backports/iceweasel-beta iceweasel 
amd64 16.0~b6-1~bpo60+1 [2,067 kB]
Fetched 2,067 kB in 0s (4,688 kB/s)
(Reading database ... 486708 files and directories currently installed.)
Preparing to replace iceweasel 15.0.1-1~bpo60+1 (using 
.../iceweasel_16.0~b6-1~bpo60+1_amd64.deb) ...
Leaving 'diversion of /usr/bin/firefox to /usr/bin/firefox.real by iceweasel'
Unpacking replacement iceweasel ...
Processing triggers for gnome-menus ...
Processing triggers for desktop-file-utils ...
Processing triggers for man-db ...
Processing triggers for hicolor-icon-theme ...
Processing triggers for menu ...
Setting up iceweasel (16.0~b6-1~bpo60+1) ...
Installing new version of config file 
/etc/iceweasel/searchplugins/locale/en-US/twitter.xml ...
Processing triggers for menu ...
 
Current status: 0 updates [-1].
# dpkg --get-selections | fgrep iceweasel; dpkg-query -l iceweasel | egrep 
'^[ih]'; aptitude search '^iceweasel$'
iceweasel   hold
hi  iceweasel  16.0~b6-1~bpo6 Web browser based on Firefox
i A iceweasel 

Bug#137771: aptitude's vs dpkg's hold state

[Daniel Hartwig]

On 5 October 2012 18:06, Axel Beckert a...@debian.org wrote:
 dpkg's holds are handled like hold flags set by aptitude -- but only
 until I change something in aptitude. From there on it ignores dpkg's
 hold flag:

Yes.  Once aptitude considers it's own hold more up-to-date it will
happily ignore anything from the dpkg database.  This is actually
correct (!) for the current situation, since aptitude's direct
instruction to (un)hold is more recent than the information in dpkg.

From some of the reports this process seems to break down when a dpkg
hold is overridden in aptitude, then later the package status is
changed outside of aptitude again (such as maybe dpkg unhold again, or
install/upgrade).  By migrating aptitude to use only the dpkg holds we
will avoid this problem.

 Either dpkg doesn't complain about having its holds overridden,
 aptitude suppresses dpkg's complaints or aptitude passes options to
 dpkg to not complain, i.e. --force-hold.

The later, though it is libapt-pkg which arranges for dpkg to not complain.

Internally, APT considers the dpkg holds (in MarkInstall and friends)
before it asks dpkg to do anything.  It then arranges for dpkg to
ignore any holds, since they are already considered.  Aptitude
considers it's own holds to be more up-to-date than the dpkg ones, so
it instructs APT to not even consider those.

This is also mostly correct given the current situation.

 At this point I think that the reasons which gave rise to aptitude
 holds have mostly disappeared.  Though I have not determined yet
 precisely what they were or whether any remain, I think the best move
 going forward is to simple drop the concept of an aptitude hold and
 completely integrate the dselect-/APT-style used by all other
 frontends.

 As long as you can still set holds via aptitude using = (as
 keybinding as well as package suffix on the commandline),

Indeed, I don't see any need to change the interface, just the
mechanism.  A hold is still a hold, and now one hold shall rule them
all.

 that sounds
 fine and the right way for me -- mostly because I don't see any
 conceptual differences from the user point of view, except that it
 will cause fewer bug-reports in the long run. ;-)

I don't see any difference either, but haven't looked enough at the
history or code to be 100% on that.  There is also Burrows' comment
which is not to be dismissed lightly; it is clear from his other
contributions that he was rather informed about APT and dpkg internals
at the time.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org