On Tue, May 24, 2005 at 09:55:31PM -0400, Jurij Smakov wrote: > Hi, > > Thanks to everyone who responded to the proposal on new uniform packaging > scheme. Below is the summary: > > Sven Luther wrote: > > >To be absolutely sure that there will be no namespace collision between > >this one and the flavour version, i would name it : > > > > kernel-headers-$(subarch)-$(version)-$(abiname) > > > >Since it is a variant of the above common header file, and unpack to > >.../kernel-headers-$(subarch)... > > > >The flavour packages of this subarch will then depend on this one, and > >add the appropriate symlinks. > > That sounds reasonable. If there are no objections, I'll look into > implementing it.
Cool. > >So /lib/modules/$(version)-$(abiname)-$(flavour)/source is deprecated > >and will have to be removed ? > > Upon further investigation and discussion with kernel-package maintainer > it turned out that the postinst file included by make-kpkg into > kernel-images has (and had for quite a while) a piece, which is supposed > to remove the source link if it is dangling, i.e. points to a non-existent > directory. Unfortunately, there is a bug in this piece of code, due to > which it was never removed :-). I filed a bug (#309981) against > kernel-package, which will hopefully be fixed in the next upload. That is not the problem. The question is which of the two links we want to keep so that third-party modules will be automatically buildable ? Either build and source exist, but what is each one supposed to do ? I am not speaking kernel-package or debian -wise, but what is expected by third party driver writters from the mainline kernel ? > Bastian Blank wrote: > > >You speak about kernel but mean linux, do you? > > This is a good point: linux kernel is pretty much dominating at the > moment, however in the future hurd and netbsd kernels may become (are?) > available. I do not know the current status of these projects, so it is > unclear whether it is worth an effort to work on a single naming scheme > which would cover _all_ kernels. Anyone else thinks that kernel- prefix is > too generic and should be replaced by something like linux- ? It would not > be too hard to implement. I would definitively go for : linux-kernel-<version> -> source package linux-source-<version>-<abi> -> binary package containing the source (and linux-tree-<version>-<abi> and linux-patch-<version>-<abi>) linux-image -> binary package containing the kernel. (and linux-headers, ...) Notice that if we are going to use these headers only for building modules, we should maybe rename them to linux-build or linux-module-support, in order to avoid confusion. > >cobalt mips/mipsel? Please clearify. > > It looks like there might be a problem with cobalt mips/mipsel flavours > which I am not aware of. I asked Bastian what the problem is exactly, but > did not get a response so far. As I understand, they are two different > architectures, so the proposed packaging should work just fine. Indeed, i was under that impression too, but thiemo told me that the current mips/mipsel package use the same source for both, and simply builds the binary packages for those two arches, as such it is already a mini-common-package, and should work out just well. > >Why not use one package with the arch-specific and one with the other > >parts? > > This is in the context of a common kernel-headers package. As it was > mentioned by other people, the discussion of it is below. > > Christoph Hellwig wrote: > > >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. > > Basically, what Christoph is proposing is not to include the > arches/subarches which require unmerged extra patches into the common > packaging scheme. I think this is a little bit extreme. I don't think it > is fair to require the Debian kernel maintainers to "fix" their > architectures which do not build from a common source. Besides there is a > constant progress with this, as I know hppa patch is constantly shrinking, > for example. Any other opinions? Christoph is welcome to help fixing the apus or nubus patchset so it is integrated upstream. I think encouraging a commmon source code is good, but we need a transition phase. > >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. > > Right, so this is a third "aye" in favour of the common kernel-headers > package for all arches (counting the one by Andres Salomon expressed in an > irc conversation). In principle it is possible to implement, however, as > it is quite significant deviation from the existing packaging scheme, > might take longer to implement. If this way is chosen, we'll probably need > the following packages: > > kernel-headers-$(version)-$(abiname) > Arch-independent package, containing all the headers including the > include/asm-* for all arches. > > kernel-scripts-$(version)-$(abiname) > Arch-dependent package, containing the contents of scripts/ directory > along with the binary files, built from source there. I don't think > that we can do without shipping the binaries, as rebuilding them on > the user's machine will require write access to /usr/src. Some > architectures also include the plain text, but arch-specific file > arch/$(ARCH)/kernel/asm-offsets.s, which should be included with the > headers. It must go into this package, along with other arch-dependent > files I am probably forgetting (are there any?). Ok, seems reasonable. kernel-headers-$(version)-$(abiname)-$(flavour) would depend on both of them. > The only unclear thing is how to handle the subarches, which potentially > modify the header files with their patches. Perhaps there should be a > possibility for subarch-specific patches, such as > > kernel-headers-$(subarch)-$(version)-$(abiname) > kernel-scripts-$(subarch)-$(version)-$(abiname) Yes, i would do this. These replace the normal one for all flavours of this arch/subarch. This is the best solution for flexibility, and if done right, would not be too much of a weight. > Any thoughts and ideas on this are welcome. As soon as the discussion is > settled, I'll try to write up the results in some more or less permanent > location. Cool. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]