[Aptitude-devel] Bug#137771: aptitude's vs dpkg's hold state

[Daniel Hartwig]

On 5 October 2012 18:06, Axel Beckert <abe at 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.