[SUMMARY] RFC: New uniform packaging scheme
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.
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
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?
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?).
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)
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: