athena-auto-update should 'aptitude install'

[geofft]

So apparently if debathena-reactivate is unpacked but not configured (because we wrote a bug in its preinst that causes it to fail inside debian-installer, but install just fine on any installed system), and so debathena-cluster is not configured, if you run 'aptitude --simulate install' it proposes to retry installing reactivate and hopefully get the last of -cluster's dependencies that it hasn't gotten to yet, but if you run 'aptitude --simulate full-upgrade' it proposes to get rid of cluster because it's "not installable" and a bunch of thirdparty deps too. The latter is what auto-update does (first with and then without --simulate).

This caused all of the new machines in W20-575 to revert to -workstation.

[jdreed]

This is basically "the auto-updater should be more resilient when we suck at writing maintainer scripts"

[geofft]

I just saw this on a machine where the machine had been rebooted while taking updates (grumble grumble people ignored my sign grumble). "aptitude full-upgrade" didn't want to do anything other than ttf-mscorefonts-installer (whose debconf postinst the installer was presumably hung on, when it was rebooted) or unattended-upgrades, after I finished the dpkg --configure -a, but "aptitude install" picked up on ttf-umefont too.

[jdreed]

Do we still want this in a world where aptitude is occasionally harmful? Do we want "apt-get -f install" or what?

[jdreed]

I tested this today on some atpocalypse machines, and a "apt-get -f install" or "aptitude install" would have fixed it. The issue is, I believe, that occasionally dpkg --configure -a wants apt-get -f isntall, and sometimes apt-get -f install wants dpkg --configure -a.

If we do implement this, do we want apt-get or aptitude?

[jdreed]

Done. It runs aptitude install, but doesn't bail if it fails, and then tries dpkg --configure -a.