[Aptitude-devel] Bug#799987: Bug#799987: Bug#799987: aptitude and dpkg disagree upon held packages

[Manuel A. Fernandez Montecelo]

2015-10-17 4:21 GMT+01:00 Harald Dunkel <harri at afaics.de>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 09/30/15 14:13, Manuel A. Fernandez Montecelo wrote:
>>
>> Even if we add support in aptitude to hold uninstalled packages (another bug report of yours), dpkg doesn't consider them, and that's not likely to change in the immediate future
>
> I think that is OK. dpkg is very low level.
>
>> -- so the problem of dpkg and apt and others not knowing about aptitude's hold states of uninstalled packages will repeat, as with the holds on installed packages until now.
>>
>
> I disagree on putting dpkg and apt on the same level here. In my
> understanding apt-get and aptitude are. They should work on the
> same database of package states. If apt-get is run internally by
> the unattended upgrades cron job, then the changes done by aptitude
> shouldn't be overridden.

tl;dr: after aptitude 0.7.2, the use case should work.


aptitude and apt use the mechanisms of dpkg for this feature to work,
so we need to consider dpkg into the equation "at the same level" when
considering package selected states, as holds.

This started with dselect, which is part of the dpkg source package,
and it predates apt and aptitude.  cupt is also another tool for
managing packages similar to apt. The only common baseline is dpkg,
and all the tools rely on it to get the lower level job done, included
selected states.  This was discussed and decided in the last DebConf.

So , in summary, the only way to implement holds in a way that work
today and are respected by all tools, is through dpkg -- that's how we
implemented it in 0.7.2.


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