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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]