aptitude users: aptitude is ignoring dpkg hold/install rules

[techAdmin]

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.

[hubi]

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):

:: Code ::

# aptitude full-upgrade
  [...]
The following NEW packages will be installed:
  [...]
The following packages will be upgraded:
  [...]
380 packages upgraded, 9 newly installed, 0 to remove and 1 not upgraded.

# apt-get dist-upgrade
  [...]
The following NEW packages will be installed:
  [...]
The following packages have been kept back:
  lame
The following packages will be upgraded:
  [...]
380 upgraded, 9 newly installed, 0 to remove and 1 not upgraded.

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:

:: Code ::

apt-cache policy aptitude
aptitude:
  Installiert: 0.4.11.10-1
  Kandidat: 0.4.11.10-1
  Versions-Tabelle:
 *** 0.4.11.10-1 0
        500 http://ftp.hu.debian.org sid/main Packages
        100 /var/lib/dpkg/status

hubi

[anticapitalista]

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

[techAdmin]

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.

[Richard]

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?