Re: [SUMMARY] RFC: New uniform packaging scheme
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
Reply to: