Ticket #1217 (closed enhancement: fixed)
Stop autodebathenifying AFS
Reported by: | jdreed | Owned by: | jdreed |
---|---|---|---|
Priority: | high | Milestone: | Raring Ringtail |
Component: | -- | Keywords: | |
Cc: | Fixed in version: | ||
Upstream bug: |
Description
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.
Change History
comment:2 Changed 10 years ago by 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?
comment:3 Changed 10 years ago by 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)
comment:4 Changed 10 years ago by 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.)
I talked with geofft about this, and we think this is a sane approach:
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?