Re: RFC: New uniform packaging scheme
On Thu, May 19, 2005 at 02:04:33PM -0400, Jurij Smakov wrote:
> kernel-headers-$(version)-$(abiname)-$(subarch)
>
> A common headers package for an architecture with subarches.
> Same purpose and contents as the one above.
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.
> kernel-headers-$(version)-$(abiname)-$(flavour)
>
> Flavour-specific kernel headers package, containing mostly the
> configuration files. It will have the same name for both cases
> (subarch or no subarch). As a result there is a restriction that
> all flavour names across all arches/subarches have to be unique,
> but that does not seem too problematic. This package must unpack
> to /usr/src/kernel-headers-$(version)-$(abiname)-$(flavour),
> depend on an appropriate common kernel-headers package, set up
> the symbolic links into it to provide a complete build-tree, and
> supply the /lib/modules/$(version)-$(abiname)-$(flavour)/build
> symlink to that tree.
So /lib/modules/$(version)-$(abiname)-$(flavour)/source is deprecated and will
have to be removed ?
> * There is a proposal to create a common kernel-headers packages
> for all arches which build from common source and containing
> all include/asm-* for them. Pros: we are saving some space by
> not including the common stuff (how big is it?) into the
> arch-specific kernel-headers packages. Cons: to build on a single
> arch user will have to pull in headers for all arches. Also
> the subarch handling becomes non-uniform with the rest.
I am not sure about this one, ppc needs ppc64 includes, and the apus subarch
and maybe nubus need some part of the m68k includes, last i checked.
> * Anything else?
Maybe some mention of the mkvmlinuz and the like support libraries ? Saying
that if anything is needed to make the vmlinux provided in the kernel-image
usable, then this support stuff need to be added to the kernel-image, and the
kernel-image has to mae sure it will do the right thing on installation. the
powerpc kernels depend on mkvmlinuz, which does a debconf question at medium
priority or defaults to the right thing for each subarch, and is automatically
called on kenrel-image install.
Now, going farther with this, we need to find some relationship with mkinitrd
invocation, especially in presence of externeal or moved to non-free
potentially root holding modules. I would suggest making sure the initrd
generating and later steps (like calling mkvmlinuz or ybin or lilo or whatever
is needed) are correctly done after the kernel-image install as well as after
installing or upgrading those third party modules.
Thanks for your great work on those.
Friendly,
Sven Luther
Reply to: