This is a new one, I think something changed recently, aptitude just started to ignore the echo <package name> install|hold | dpkg --set-selections command.

This means I have to modify smxi to use the aptitude hold / unhold method.

I have to admit, every time I start to almost like Debian, they do something counter-productive and pointless like this, and it makes me realize Debian will always be what it is.

I'd already determined that aptitude hold/unhold had no affect on dpkg set holds, now it appears it's complete, and aptitude completely ignores these hold commands set in dpkg directly.
Back to top

I cannot verify that. One package is on hold here, both apt-get and aptitude hold that package when running a (dist-)upgrade. I never used aptitude hold. The difference: aptitude does not list the package, apt-get does.

But: both apt-get and aptitude overwrite a dpkg hold when you run 'aptitude/apt-get install package_on_hold'.

Here an excerpt (a box which has not seen a d-u for a few weeks, but aptitude is the current Sid version):



Both aptitude and apt would deliver the same result, lame is on hold. The difference: aptitude does not state it in the package list.

My version:


hubi
Back to top

I get the same as hubi, on antiX-sid-sidux.

Example: transmission set to hold by smxi.

aptitude dist-upgrade did not upgrade transmission.

Once version mis-match was fixed
aptitude dist-upgrade upgrades transmission
Back to top

smxi now handles aptitude and apt-get holds using each tool, dpkg and aptitude hold/unhold, so it will work in all cases.

I'm tempted however to add dpkg hold/installs as well just in case to the aptitude stuff.
Back to top

I still prefer aptitude.

I wonder what the reason is that apt-get, aptitude and synaptic all chose different handling of the installed database. Is it that the dpkg one is not consistent or unstable?
Back to top

I don't know if it's related, but I remember trying to hold a package using aptitude in Debian Sarge. It was a few years ago, so I don't remember which package it was, but I was quite puzzled because placing the hold didn't seem to actually do anything. In other words, it didn't work.

So this was fixed? If so, that's great. However, if this issue ever pops up again in some form, perhaps a suitable workaround would be to pin the package at the desired version.

Phil
Back to top

No, sadly, it's not fixed, it's still broken, for the very simple reason that the aptitude maintainer refuses to consider this bug a bug, which of course means that it won't get fixed until he wakes up from his dreams and makes a hold hold as intended.

The goal of using aptitude hold is to hold the package, and aptitude is supposed to replace apt-get and be an all in one, so having to go in manually to pin a package in order to hold it is simply admitting that aptitude is still broken. Which in this respect it is.

The only 'fix' I have found is to locate all related packages, like the audacity-data audacity set, and then place both explicitly on hold with aptitude. That sometimes works, as long as there aren't too many other directly related packages, but it's very random, and nothing near as clean and efficient and predictable and well done as the basic echo <package> hold | dpkg --set-sections method. In other words, it's broken, and isn't truly a real replacment for apt-get yet, though it is improving, but it won't be fully resolved until the maintainers admit that bugs are bugs, and that weaknesses should be fixed, and if they are core issues, the core needs to be fixed too, which is unfortunately my growing suspicion (ie, when issues that make no sense are not promptly fixed, I have to suspect that they are simply symptoms of deeper broken things, that make fixing such visible things almost impossible. )
Back to top

As h2 stated: a dpkg hold has no effect with aptitude when a dependent package is updated.

When I realized that I stopped testing aptitude. That was a real showstopper because I did not want to start putting all dependencies on hold.

So I just sit out version mismatches in Sid again and put them on manual hold in smxi (if needed ... smxi is quite elaborated now). But if I have a hold it is for a reason (relevant bug e.g.) and I want the package manager to accept that. Aptitude does not. Unfortunatelly.

hubi
Back to top