[Aptitude-devel] Bug#328616: Bug#137771: #137771: aptitude's vs dpkg's hold state (was: Processed: more bts etc.)

[Daniel Hartwig]

Hi Axel, others

This is one of the major issues remaining in aptitude.  A task I will
eventually get to when schedule permits.

I have tagged it “help” for the obvious reasons of drawing much-needed
(developer) attention to it.  It is not expected to be particularly
hard though it will certainly take a considerable commitment and
effort to resolve.  It does not require extensive knowledge of
aptitude either, only some knowledge of APT and a certain enthusiasm.

I have also started a bounty [1] for the issue which is held in trust,
claimable by any person who submits a patch that fixes it.  This is a
nice way for non-developers to contribute some support to this task.

[1] http://www.fossfactory.org/project/p317

On 4 October 2012 23:03, Axel Beckert <abe at debian.org> wrote:
> It's likely less trivial than it seems, otherwise it would have been
> fixed already a long time ago.
>
> I'm though curious what's the culprit which -- for more than a decade
> -- kept developers from fixing it.

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

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.  APT only knows about dselect holds, which is why we see
reports like “$APT_FRONTEND does not respect aptitude holds” and the
inverse of that.

The reason for the aptitude holds appear mostly historical: this was
not a well integrated aspect of early APT, it appears that it was
easier to implement holds directly in aptitude.  To this day the
dselect holds are not fully integrated in to APT (for example,
“apt-mark hold” invokes dpkg directly rather than using class DPkgPM).

> I browsed through the merged bugs, but the only hint I found so far
> about the issue described in http://bugs.debian.org/137771 is in
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=220794#20:
>
> "the databases do not contain exactly equivalent information, and
> there is no one-to-one translation between them" (But it's not
> mentioned what the differences actually are.)

I have seen this comment (quite old) but not investigated its claim
yet.  I *suspect* that it no longer applies and was originally to do
with MarkInstall, etc. not respecting dselect holds, or something
similar.

Burrows submitted functionality to APT [2] to support this which has
been applied for some time and now APT does now respect the dselect
holds.  This cleaned up a lot of the issues users were expecting, but
the greater problem of aptitude holds not being respected by other
tools remains.

[2] http://bugs.debian.org/470035

> So I would be happy if you could post some more details to #137771
> about where you could need or would like to have help. Do you think
> it's rather a technical or a conceptual issue?

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.

This is a task for programmers who are a little familiar with APT.
Aptitude needs to be adjusted to read hold states from
PkgIterator->SelectedState, write hold states using dpkg (refer to
apt-mark.cc), and migrate it's internal hold states to
/var/lib/dpkg/status.

Alternatively, libapt-pkg's DPkgPM and also pkgPackageManager classes
could be updated to support changing hold state first, then aptitude
updated to write hold states using that.  I am not actually sure
whether this is lacking currently or not.

Developers, to get started stick your faces in to:
- aptitude/src/generic/apt/aptcache.cc;
- apt/apt-pkg/depcache.h;
- apt/apt-pkg/packagemanager.h;
- apt/apt-pkg/deb/dpkgpm.h; and
- apt/cmdline/apt-mark.cc (to see how it should be done).

An extensive knowledge of aptitude is *not* required :-)

> P.S.: http://bugs.debian.org/328616 looks to me like a different issue
> than http://bugs.debian.org/137771 -- maybe related, but not
> specifically related to syncing hold states.

Ah, you are correct.  #328616 is more related to the “aptitude
installs (removes) package removed (installed) by apt-get, etc.”  The
hold-bugs are currently entangled as blocking an archived bug.  I have
been preparing some more BTS maintenance on them to fix that and merge
some others so I'll unmerge this one at the same time.

Regards