I've just been looking into the aptitude method of a: hold/unhold, which is fine and easy, but I've hit a massive and I believe basically unfixable bug for aptitude hold/install tests and checks.

Currently I use dpkg -l | grep ^hi ... in various permutations, which is basically almost instant, but my first tests with the horribly convoluted, and almost useless, aptitude search feature, shows me massive, and I think, given the size of the package groups to be tested in debian sid, unacceptably slow package status searches.

I hit this issue once before with another tool, grep-dctrl or something, which was also utterly useless because it was absurdly slow. That one I solved by just creating a custom apt-cache search item, but it's a bit trickier to handle aptitude.

I found this thread which explains the syntax for the /var/lib/aptitude/pkgstates file, and obviously you can grep that one directly, with a bit of help from sed, but man, what a painful and poorly done part of aptitude this is, sigh... sometimes things seem too good to be true.

Score one for the sidux recommended apt-get method here, it's superior in this area hands down.

Basically, to get usable search, I have to write my own little mini search algorythm, which really suggests kind of strongly that the one aptitude provides is just not very well done. Sigh. But on we go, I need to remember that there are more important things to worry about than this stuff.
Back to top

I figured out a hack to get around this, I grep the text file /var/lib/aptitude/pkgstates for the hold/install value, then change that with aptitude hold/unhold, and read the changes.

I don't really like this method, because long term it's going to slightly corrupt the aptitude method, but I can't really find any other way to do it that isn't super slow.

If you have openoffice.org on hold using hte old smxi method you have to now put it on aptitude hold again in smxi, but annoyingly, this will leave the dpkg holds in place, but since aptitude now ignores those, that doesn't really matter unless you want to use apt-get.

I really can't believe that the debian devs couldn't think a bit more on this one and get some more clean integration of the package tools. Apparently synaptic also has its own hold install list.

Why they couldn't make dpkg the master list is totally beyond me, this one was not at all well thought out in my opinion, a definite blemish on my aptitude experience so far, creating 3 possible places for one piece of information is VERY bad planning.

dpkg was the natural location, they screwed this one up, this is chaotic and poorly done, oh well, one minus for aptitude, most other things so far have been pluses. Well, ok, two minuses, the aptitude search feature is horrible too. Incredibly slow, and totally non-intuitive, with syntax only a debian developer could consider reasonable.
Back to top

No idea about synaptic's own hold routine, but a (dist-)upgrade with synaptic would not install my package on hold, aptitude does neither (I replied in the other thread with code output).

It is "aptitude install" and "apt-get install" which do overwrite dpkg holds here.

At the moment I really cannot see why "aptitude full-upgrade" respects dpkg holds here and not in smxi (I have not tested smxi).

hubi
Back to top

smxi is using dist-upgrade. I wonder if that's related.

However, this is a known issue, lots of bug reports on it I believe, at least so the #debian guys said.

I'm wondering if this just happened, is something that the newest sid aptitude is doing.

There's no doubt it's doing it, I had OOo on hold in dpkg, and aptitude dist-upgrade totally ignored that, and I also saw hplip get held pre du and then aptitude totally ignored that and installed hplip, which is what alerted me, well, that and the OOo failure.

This type of inconsistency in my opinion is a serious bug, there should be ONE and only one source for hold information, and that should be the most basic component, dselect/dpkg. All others should read from that, otherwise you get into silly things like one tool not paying attention to another.

aptitude holds are ignored by everything else too, they live in their own file, as I discovered, /var/lib/aptitude/pkgstates

Just the fact that aptitude holds are ignored by apt-get or dpkg shows the problem, there is no reason they couldn't have done this in a more integrated style.

I've modified smxi to now hold/install using either dpkg --set-selections or aptitude hold/unhold, but I don't like this at all, I think it was very poor engineering and poor decisions made, the aptitude tool is very good, but there should be only one source for this data, not 3 as there apparently are. I was asked if I was also handling synaptic, but I'm going to totally ignore that, I can't support it because I never ever use it, but I am afraid that synaptic users will be equally frustrated here.


Back to top

Ooooh yes, I can reproduce it with hplip. The dependency handling is different.

I did test runs with "apt-get dist-upgrade", "aptitude dist-upgrade", "aptitude full-upgrade".

0. There is no difference between "aptitude dist-upgrade" and "aptitude full-upgrade".

Now to the hplip testrun. Installed is hplip, hplip-data, hplip-gui, hpijs, hpijs-ppds, all those packages would be updated with a dist-upgrade.

1. hplip is on hold

- apt holds "hpijs hpijs-ppds hplip" and installs "hplip-data hplip-gui"
- aptitude installs "hplip hplip-data hplip-gui", no holds at all

2. hplip and hplip-data are on hold

- apt holds "hpijs hpijs-ppds hplip hplip-data" and installs "hplip-gui"
- aptitude holds "hplip-data" and installs "hplip hplip-gui"

3. hplip, hplip-data, hplip-gui are on hold

- apt holds "hpijs hpijs-ppds hplip hplip-data hplip-gui"
- aptitude holds "hplip-data hplip-gui" and installs "hplip"

4. hplip, hplip-data, hplip-gui, hpijs are on hold

- apt holds "hpijs hpijs-ppds hplip hplip-data hplip-gui"
- aptitude holds "hplip-data hplip-gui" and installs "hplip"

5. hplip, hplip-data, hplip-gui, hpijs, hpijs-ppds are on hold

- apt holds "hpijs hpijs-ppds hplip hplip-data hplip-gui"
- aptitude holds "hpijs hpijs-ppds hplip hplip-data hplip-gui"

It was the packages hpijs, hpijs-ppds which triggered that the hold of hplip was not respected.

As I said before, "apt-get install foo" and "aptitude install foo" overwrite holds, I put hplip, hplip-data, hplip-gui, hpijs, hpijs-ppds on hold and ran testruns. The results for apt-get and aptitude were the same.

apt-get/aptitude install hpijs installs hpijs, hplip
apt-get/aptitude install hpijs-ppds installs hpijs, hpijs-ppds, hplip


So more options:

The packages are still on dpkg hold, and I put hplip on hold with "aptitude hold hplip" as well. Result: "aptitude dist-upgrade" installs hplip and hpijs.

I put hplip and hpijs on "aptitude hold": this finally did not install any of the packages hplip* hpijs*


Conclusions:

If reverse dependencies are updated or installed, aptitude is not interested in any holds (no dpkg holds, no aptitude holds), it installs the package.

If you want to avoid the update of a package when a reverse dependency is updated one has to set the reverse dependency on "aptitude hold [rdep_package_1] [rdep_package_2] [rdep_package_n]".

So if you want to hold hplip, "aptitude dist-upgrade" or "aptitude full-upgrade" does install hplip if an upgrade of hpijs requires it. Neither a dpkg hold of hplip nor "aptitude hold hplip" stops this behaviour. One has to hold the reverse dependeny hpijs through "aptitude hold hpijs".

I agree with h2: this is a showstopper on a rolling release. One goes nuts when one always has to check rdepends when you want to dist-upgrade.

Daniel Burrows, the maintainer of aptitude, indirectly confirms this on Debian bugtracker, and it seems to be a desired feature:
bugs.debian.org/cgi-bin/bugreport.cgi?bug=452589#10

For me: this is now serious and I stop using aptitude ... holds have to be respected when a reverse dependeny wants to update a package on hold. apt does that, aptitude does not. This is not acceptable on a rolling release.

hubi
Back to top

hubi, aptitude hold/install is the biggest current problem I think now in the smxi scripts, and that one is a biggy I think, probably worth posting in the bug report threads on Debian for that one until the dev stops being silly and starts making a hold do what you expect it to do, hold the damned package.

This is a case, however, where I think a few people can make a difference. The more people who point out that a hold that is not respected is worse than useless, in fact, it's a totally ridiculous idea, and the more of us who point this out in bug report threads, the better. Sometimes debian developers get so far out of touch with people that they actually manage to convince themselves that a hold that does not hold is a 'feature' rather than a failure.

aptitude is supposed to be clever and smart, and here it can't even make a simple, super simple, decision: read the hold list, do not install anything, or update it, if it is on that list. If there are other packages dependent on that package, hold them as well, or do not offer them to install for dist-upgrades/upgrades. This is so utterly obvious, I am starting to suspect that aptitude actually has two core developers, one who did everything well and improved the user experience by making things more intuitive with better options, and the other who decided this was unthinkable, and so implemented very poorly done features, very user unfriendly, like the aptitude search function, and this stuff.

I'm guessing that this slightly tongue in cheek explanation might actually be true, the search stuff is terrible, it's slow, it's totally useless for regular users, it's utterly non-intuitive, and, what's worse, you can make faster searches by scripting it yourself, which is to me a total failure of any software if it's so slow and unpleasant to use that you find writing something yourself to be less painful.

Clearly, asking aptitude to 'hold' something, then having that something installed, as hplip was, even using aptitude's own hold / install syntax, isn't just a small bug, it's a full on design and implementation failure.

Last time I checked, the word 'hold' doesn't mean: ok, hold this unless you don't feel like you should, then ignore the hold and install it anyway.

What I hope is not the case is that this isn't some deeper failing in aptitude, because otherwise it's hard to think of any rational reason to have such totally non-functional components to aptitude. I mean, what it should say in this case whenever you run the command aptitude hold package should be a brief warning: for no rational reason anyone can determine but one which unfortunately the aptitude developer has convinced himself is correct, this hold may or may not work as you expect. If you really really needed a package to be held, always, tough, you can't do it with full certainty.

Once the truth was exposed in this clear way, it would be I think a bit too shameful for the aptitude guys to keep trying to maintain such an absurd position. And since the truth can in fact be expressed in such ways, ie, an aptitude hold does not really do much unless it feels like it wants to, and since aptitude ignores what should be the true last word on holds, dpkg --set-selections, this in fact means you have NO reliable tools to implement a hold or remove it. Well, I assume removing the hold with unhold makes aptitude work almost like it does by adding a hold, except the package will I guess always update anyway, instead of sometimes.
Back to top

The unfortunate thing is that in most other ways, aptitude is really good in sid, here's today's handling of the kde libs issue, package version mismatch:


That's the same result, by the way, I got via smxi holding kdelibs-data.

It's unfortunate that aptitude isn't working correctly in this single area, hold handling. This seems like a very fixable issue, unless the developers get into that 'it's not broken it's a feature' defensive position, which would be unfortunate for the greater good of all Debian users going forward.
Back to top

It is not only aptitude that overwrites a hold.

For example I have mplayer on hold, aptitude and apt-get do keep it when using

apt-get dist-upgrade

but apt-get/aptitude install mplayer does override it.

Is that meant to happen?
Back to top

Yes, apt-get/aptitude install always overrides, that's a desirable feature, since install <package> means you specifically are requesting the action.

In a perfect world, maybe, apt-get/aptitude would ask you if this is what you want, but I think it's quite reasonable to assume that if you request an action specifically, for a specific package, that action takes place as you requested.

To me the hold failures are only relevant re upgrades and dist-upgrades, in those cases, specific holds should always be respected and handled as expected by apt-get (which does that always) and aptitude (which does that only in some cases, and depending on which package you held, ie, maybe if you hold package-data it will hold package, but if you hold package, and package-data has a newer version, package will get upgraded.

Also, I have to admit to being somewhat shocked to learn that aptitude, synaptic, and dpkg/apt-get use 3 separate hold database methods, which is incredibly badly done, there should be one and only one that all 3 read and write from, and even with 3, all 3 should always work in all cases, but it's really silly to have especially synaptic have its own hold db which apt-get doesn't even know about, or aptitude, what if you use synaptic for gui and apt-get or aptitude for upgrades? I really have no idea how this came about, but it's a perfect example of how sometimes this thing with each project being totally disconnected from the others is not at all a good thing. Now and then it's good to enforce a larger picture process, ie, if you are going to create a tool for package handling, it must use a common db and way of handling things, with extra features.

This partial handling is what is ridiculous, I mean, if I install a package with aptitude, there is it, listed in dpgk -l | grep package as ii status, so why on earth would you then not use the perfectly working hi status marker in dpkg db for all hold checks and puts? It simply makes no sense.
Back to top

While using aptitude in smxi it wanted to install the evolution packages that are being kept back right now. It asked me if I wanted to resolve the depends myself. I told it no and it didn't install the evolution packages.

Is this behavior what you guys are talkiing about?
Back to top