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 <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
