Ticket #948 (closed defect: fixed)

Opened 10 years ago

Last modified 8 years ago

DKMS transition breaks on Debian meta-metapackages

Reported by: geofft Owned by:
Priority: high Milestone: The Distant Future
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:


From zephyr:

       ... squeeze doesn't have a linux-headers-686

       Did we break this?

       looks like? openafs-modules-686 in switching to dkms depends on the nonexistant linux-headers-686

       I only have an amd64 squeeze box easily accessible... is it that it
       should depend on linux-headers-2.6-686?


There's code early in the OpenAFS debathenificator to detect Debian's meta-metapackages (linux-foo Depends: linux-2.6-foo). We should deal with those.

Change History

comment:1 Changed 9 years ago by jdreed

Why does the transitional metapackage even depend on anything other than openafs-modules-dkms? I see no need for it to depend on a kernel/header version. I'd rather just punt those additional dependencies in the transitional package, and then move on, and wait until April when we can finally kill off the debathenifier for openafs.

comment:2 Changed 9 years ago by jdreed

OK, I found the logic problem. This statement:

# To distinguish metapackages from meta-metapackages, we need to look
# at whether the package's linux-image-* dependency is an actual
# kernel image or a metapackage.

is not true. linux-image-i686 (a meta-meta package) depends on linux-image-2.6.32-5-686, which is just a plain old package.

I'm not sure what the easiest way to fix this is, but it sounds like this only affects ia32, and that there are a finite number of meta-meta packages, so maybe we should just blacklist the meta-meta-packages?

comment:3 Changed 8 years ago by jdreed

So, uh, the real problem here is that we create metapackages with invalid dependencies.
We can trivially shove an apt-cache show in there to ensure it exists before creating it. But the question is, if a headers package doesn't exist, should we skip the metapackage creation entirely? I think so.

I think the script needs to be more complicated than it is, and on Debian, we need to identify if two metapackages provide the dependency. That is, if linux-image-686 depends linux-image-2.6.32-5-686 and linux-image-2.6-686 also depends linux-image-2.6.32-5-686, then we go back and look at each of those metapackages, and figure out which one is "real" and has headers and which one doesn't.

comment:4 Changed 8 years ago by jdreed

Actually, given the above situation, should we instead create our metapackages to match linux-image metapackages? That is, for linux-image-686, should we create openafs-modules-686 which deps openafs-modules-2.6-686? Or should we just stop caring?

comment:5 Changed 8 years ago by jdreed

  • Status changed from new to committed

Committed in r25841. I hate Debian so much.

comment:6 Changed 8 years ago by jdreed

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

OK, I tested this and deployed it. It correctly does not create metapackages with nonexistent dependencies. e.g. For linux-image-vserver-amd64, it will create openafs-modules-2.6-vserver-amd64, but not openafs-modules-vserver-amd64. So we should be all set. I opted not to create another tier of metapackages for the skipped ones (e.g. openafs-modules-686 Depends openafs-modules-2.6-686 which Depends linux-image-2.6-686 and linux-headers-2.6-686). We can always add it later if we want.

Note: See TracTickets for help on using tickets.