Stop autodebathenifying AFS

[jdreed]

When Hardy (the last non-DKMS release) is dead, we can stop autodebathenifying AFS (right?) Given #1189, I think we still need to make some metapackages to ensure that the right kernel headers get pulled in, but I'd really like us to come up with a way to solve this that doesn't rely on the autodebathenificator. That may be doing something clever in the installer, and deciding that if you don't use the installer, you get to ensure your kernel headers are installed by hand.

[jdreed]

I talked with geofft about this, and we think this is a sane approach:

• The installer does some cleverness to figure out what kernel you're running (and perhaps ask you, if you've managed to install more than one) and pulls in the correct headers. Once installed, you're all set for upgrades, because all the headers packages (should) Provide at least linux-headers, which is a dependency of dkms.
• If you are clever enough to change what kernel you're running, you're clever enough to deal with installing its headers correctly.
• If you use the manual installer, and run server, virtual or lowlatency, you get to figure out headers yourself (and we can note this on the manual install page).

I think our upgrade paths are all set, because the DKMS transitional metapackages will still exist, we just won't be creating any new ones. Or do the old header packages disappear from the archive, such that the dependency of the transitional packages will not be satisfiable once a newer kernel is released? Regardless, I think we can safely stop debathenifying for Oneiric and higher.

Or is the answer that we should produce our own metapackage that conditionally depends on the "missing" kernel headers that dkms doesn't depend on?

[jdreed]

OK, I think we can just go ahead and turn off the autodebathenificator at this point for Oneiric and above. Our transitional metapackages merely depend on the generic headers packages, so they will be fine. The only potential screw case is that Lucid machines can conceivably still have hand-built modules if they're in some broken state where they never took our new metapackage. I'm not sure if there's a good solution there, or if we just get to wait until 2015. Under what cases might a Lucid machine have ended up without DKMS?

[jdreed]

So, dkms 2.2.0.3-1ubuntu3.1 just came out, which fixes  LP:960770, and dkms now recommends nothing to do with the kernel. The LP log seems to suggest that things which make use of dkms should deal with pulling in headers. It's unclear whether we should ask openafs to recommend headers, or whether we should just move forward with the installer changes (and manual installation instruction updates)

[andersk]

Neither dkms, openafs, nor any package in the Ubuntu repository or ours is in a position to know which kernel headers to pull in. The installer is.

(It’s possible that we can conscript something in jockey to do it for us, but that’s probably more work than necessary.)

[jdreed]

Now that #948 is fixed, I think we can do one final run by hand, and turn it off whenever. We've secretly not been building for hardy for a while, since we took it out of DEBIAN_CODES. And everything else has DKMS.

[jdreed]

builder@magrathea:~$ crontab -l
MAILTO=debathena-root@mit.edu

#min	hour		mday	mon	wday	command
#0	*/2		*	*	*	pagsh -c /mit/debathena/bin/build-serve /autodebathenify
[...]