[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


> >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.



Sven Luther

Reply to: