On Mon, May 23, 2005 at 05:20:06PM +0200, Christoph Hellwig wrote: > 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.
I agree and disagree with you. I think it is good to keep the possibility of separate arch/subarch patches, while encouraging the migration to a single source tree. It is more flexible this way. > > (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. Ok, fine with me. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
