DKMS transition breaks on Debian meta-metapackages

[geofft]

From zephyr:

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

       Hm?
       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?

       yup

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.

[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.

[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?

[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.

[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?

[jdreed]

Committed in r25841. I hate Debian so much.

[jdreed]

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.