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

[SUMMARY] RFC: New uniform packaging scheme


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 :


Since it is a variant of the above common header file, and unpack to

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.

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.

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.

Why not use one package with the arch-specific and one with the other

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?

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:

  Arch-independent package, containing all the headers including the
  include/asm-* for all arches.

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

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


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.

Thanks and best regards,

Jurij Smakov                                        jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                   KeyID: C99E03CC

Reply to: