Ticket #755 (closed defect: fixed)

Opened 10 years ago

Last modified 10 years ago

install-debathena.sh destroys freshly-installed Maverick systems

Reported by: geofft Owned by: amb
Priority: blocker Milestone: IAP 2011
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:


If you haven't done an apt-get update; apt-get dist-upgrade or equivalent between installing Maverick and running install-debathena.sh, ubuntu-minimal and ubuntu-desktop gets removed, because aptitude gets confused about version number discrepancies. And then all their dependencies get autoremoved. Like GNOME and GDM. This seems suboptimal.

Is there any reason not to update and dist-upgrade before running the Debathena installer?

Change History

comment:1 Changed 10 years ago by jdreed

  • Status changed from new to assigned
  • Owner set to amb
  • Milestone changed from The Distant Future to IAP 2011

I believe at release-team, we decided to do something like this

(I did not test this code, somebody should)

pattern='^0 packages upgraded, 0 newly installed, 0 to remove'
if ! aptitude --simulate --assume-yes full-upgrade | grep -q "$pattern"; then
     echo "Your system is not up to date.  Please run 'aptitude full-upgrade' or use the GUI update manager to ensure your system is up to date before continuing"
     exit 1

comment:2 Changed 10 years ago by jdreed

  • Status changed from assigned to committed

Please review and test r24922.

comment:3 Changed 10 years ago by geofft

So, thinking about it a bit more, my concern with that is that it doesn't address the case where you haven't run aptitude update either. We do run aptitude update a bit later (we must, after we add our repo), so that's be a more appropriate place to do this check.

Also, there's a theoretical concern in that you might be intentionally holding back a package. I wonder if we can do some better check for whether the system is actually about to blow up?

comment:4 Changed 10 years ago by broder

Add a --force option if you're concerned about users that are too clever for their own good.

comment:5 Changed 10 years ago by geofft

Digging deeper, I found a couple things.

There may an aptitude bug going on here involving Internal error: found 2 (choice -> promotion) mappings for a single choice. This may or may not be DebBugs:507087 but there's not a whole lot of information there. We should give them a reproducible test case, but I'm having trouble getting one.

If I open a Maverick build chroot, comment maverick-security and maverick-updates in sources.list, aptitude update, aptitude install ubuntu-desktop, readding -security and -updates and aptitude update, and attempt to install dnsutils (a pre-dependency of our installer whose installation from maverick-{updates,security} depends on newer libraries than the currently-intsalled bind9), aptitude proposes removing ubuntu-desktop and a bunch of other stuff like Avahi. The second proposal, and the correct answer, is to upgrade bind9.

The same procedure with debathena-zephyr-config (which installation requires removing libzephyr4-krb and replacing it with libzephyr4-krb5) proposes removing most of your system. The second proposed solution, again, is correct.

Reading the aptitude manual's section on "Costs in the interactive resolver" (look at a recent version; unfortunately  http://tools.ietf.org/doc/aptitude/html/en/ch02s03s04.html seems to be the best URL), I noticed that a) aptitude now seems to be calculating the safety of a solution by the worst thing that any action in the solution does, as opposed to keeping a score based on each good/bad thing by a solution, and b) seems to consider removing packages the safest thing to do alongside installing them. The section also claims that the default sort is safety followed by apt policy priority (the extremum of all the priorities of packages in the solution), which is 500 for everything. This really gives aptitude no information as to how to sort solutions, so it's not quite surprising it comes back with nonsense.

I spent some time playing with the aptitude installer. Changing Aptitude::ProblemResolver::Remove-Level to be higher than Aptitude::ProblemResolver::Safe-Level (which we can do with -o) helps the dnsutils case, but since in the zephyr-config case we do actually want to remove one package, it doesn't help (it proposes the solution involving removing n packages first). Setting Aptitude::ProblemResolver::SolutionCost? (the sort order) to "safety,removals" fixes the dnsutils case, and to "removals,safety" fixes the zephyr-config case; I'm working to see if I can find something that works well for every case.

I'm of two minds about whether this is a superior solution to requiring the user be fully updated (note that there are legitimate cases for leaving a couple of packages back, like drivers or third-party stuff). It certainly seems less invasive, but it's a little more complicated. Also, it only works with the resolver from Maverick (or later) -- but then we only need it for that resolver.

comment:6 Changed 10 years ago by geofft

The other option here is that apt-get works perfectly fine. Given that, as best as I can tell, aptitude has become actively dumb, and also given that we need to install aptitude since it doesn't come with the Maverick desktop CD, I would be pretty okay with punting aptitude for new enough releases (either keyed on apt-get being new enough to work or aptitude being new enough to break -- Ubuntu d-i installs, including the result of PXE, will get aptitude, so we can't key off the existence of aptitude).

I believe we used to use aptitude because apt-get wasn't able to deal with the zephyr library thing, or something similar. They seem to have reversed roles.

You get a bunch of other silliness with aptitude, including something about wanting to confirm that you never wanted citadel-mta installed.

comment:7 Changed 10 years ago by geofft

Er, strictly speaking, it isn't true that aptitude is the only thing that acts silly about Citadel; apt-get does too. If I replace aptitude in install-debathena.sh with apt-get, it decides to install citadel-server (and some dependencies) just after telling me that citadel-server was (will be?) automatically installed, is no longer needed, and can be apt-get autoremoved. *sigh* Well, at least it doesn't destroy the system.


In other news, I've reported the dnsutils bug as  DebianBug:610845 ... In addition to  DebianBug:507087 which I mentioned above (and typo'd the wikilink), there's  DebianBug:341963 and  DebianBug:359171, which might be relevant but are 5 years old.

comment:8 Changed 10 years ago by jdreed

  • Status changed from committed to closed
  • Resolution set to fixed


Note: See TracTickets for help on using tickets.