Today we generate a set of development packages for each architecture
from the linux-2.6 source package:
linux-headers-<abiname>-common
static headers
linux-headers-<abiname>-<flavour>
configuration, symbol versions generated headers; depends on
linux-headers-<abiname>-common
linux-headers-<abiname>-all
metapackage depending on linux-headers-<abiname>-<flavour> for
all current values of <flavour>
Then the linux-latest-2.6 source package generates:
linux-headers-<flavour>
metapackage depending on linux-headers-<abiname>-<flavour> for
current value of <abiname>
1. Some OOT module packages want to recommend or suggest a headers
package. Currently there is no good stable package name they can use on
an architecture that has multiple kernel flavours. Instead, they use
the virtual package name 'linux-headers', resulting in a random flavour,
or the obsolete 'linux-headers-2.6'.
Since the linux-headers-<abiname>-<flavour> packages are generally quite
small, I would like to suggest that we add a metapackage that depends on
linux-headers-<abiname>-all, perhaps called linux-headers-all, and
encourage OOT module packagers to refer to that. That might cause DKMS
to build for all flavours automatically, so we should discuss this with
the DKMS maintainers first.
2. Further, I think we should consider folding all the development
packages in the first list into one (though it would need to provide
linux-headers-<abiname>-<flavour> initially since DKMS and
module-assistant expect that pattern).
3. Finally, the stem name 'linux-headers' is not very helpful. These
packages don't just provide headers, and they also specifically provide
headers for kernel development, not sanitised headers for userland
development (linux-libc-dev). Could we also change the names to
linux-kernel-dev-<abiname> (or linux-<abiname>-kernel-dev) and
linux-kernel-dev?
Ben.
--
Ben Hutchings
Computers are not intelligent. They only think they are.
Attachment:
signature.asc
Description: This is a digitally signed message part