Re: RFC: New uniform packaging scheme
On Thu, May 19, 2005 at 02:04:33PM -0400, Jurij Smakov wrote:
> Kernel packages are uniquely identified by their architecture,
> subarchitecture and flavour. For most arches the kernel images are
> built from the same source (upstream source with all-arch Debian
> patches), using different configuration files corresponding to
> different flavours. Subarch level is only required when specific
> unmerged patches need to be applied to the common source to support
> a particular class of hardware. As these patches potentially modify
> the headers, each subarch has to have its own kernel-headers package.
I think it's a very bad idea to have different source bases and if
possible we should implement it in the packaging - that would encourage
people to use the facility instead of fixing things up properly. And
doing that is always possible. I managed to fix the big mess that ia64
was in the 2.5 series, and Al Viro managed to fix m68k easily for 2.6.12
or 2.6.13 - the fix was mostly trivial the only problem was political
unwillingness from the m68k maintainers.
> Packaging scheme
> ----------------
> To accomodate all the possibilities, the following packaging scheme
> (to be implemented by the common source package) is proposed:
>
> kernel-headers-$(version)-$(abiname)
>
> A common headers package for an architecture without subarches.
> It will contain all the common header files required to build the
> 3rd party modules, including the scripts subdirectory (currently
> packaged as kernel-kbuild). It should contain only the includes
> for this particular arch, i.e. include/{asm-generic,asm-$(arch)}
> Unpacks to /usr/src/kernel-headers-$(version)-$(abiname).
>
> kernel-headers-$(version)-$(abiname)-$(subarch)
>
> A common headers package for an architecture with subarches.
> Same purpose and contents as the one above.
>
> kernel-headers-$(version)-$(abiname)-$(flavour)
>
> Flavour-specific kernel headers package, containing mostly the
> configuration files. It will have the same name for both cases
> (subarch or no subarch). As a result there is a restriction that
> all flavour names across all arches/subarches have to be unique,
> but that does not seem too problematic. This package must unpack
> to /usr/src/kernel-headers-$(version)-$(abiname)-$(flavour),
> depend on an appropriate common kernel-headers package, set up
> the symbolic links into it to provide a complete build-tree, and
> supply the /lib/modules/$(version)-$(abiname)-$(flavour)/build
> symlink to that tree.
I think we should only have a single kernel-headers-$(version)-$(abiname)
package. There's quite a bit of cross including of asm-<arch> headers,
and having the full set available makes getting this right much easier.
It's not a lot of space used anyway.
Reply to: