Re: Single kernel package discussion.
On Sun, May 15, 2005 at 02:39:14PM -0400, Jurij Smakov wrote:
> Hi Sven,
> >Any coments on the above ? I think it is sound, and it covers every
> >existing
> >case, while in many cases there will be only one subarch per arch, and many
> >flavours. Maybe we need to rename stuff, but this has worked for the arches
> >which need 3 levels.
>
> Ok, I'll summarize to make sure that I understand it correctly. On powerpc
> (and possibly on mips) you start with a common kernel source, which is
> then patched with subarch-specific patches to produce subarch kernel
> source. Kernels for different flavours within the subarch are built using
> the same subarch kernel source, but different configs. Is that correct?
Indeed.
> >So, what of the generated packages ? We have :
> >
> >source -> generate kernel-source, kernel-tree, kernel-patch and kernel-doc.
> >
> >arch -> nothing.
> >
> >subarch -> generates kernel-patch-<subarch> and kernel-headers-<subarch>
> >
> >flavour -> generates kernel-build and kernel-image.
> >
> >I think all of this is obvious, but i want to explain how
> >kernel-headers/kernel-build work, and get some comment since this is
> >perhaps
> >the most difficult part of it, and it may not correspond to the needs of
> >the
> >non-powerpc arches.
>
> Well, I have slightly different ideas about it. First of all, I think that
> kernel-build package is completely redundant and is not present on many
yes and no, but see below.
> architectures. I think in the simplest possible scheme the subarch level
> is not required, so that we have only arch and flavours within it. In a
> unified scheme stuff is distributed over the packages as follows:
>
> kernel-source-$(version)
> Contains source, debian patches, and arch/subarch specific
> patches. The latter include the unmerged patches, such as hppa
> kernel patch and your powerpc subarch-specific patches. The
> rationale is to keep all the source code and patches in one pile.
>
> kernel-image-$(version)-$(abiname)-$(flavour)
> Kernel image package for a particular flavour. kernel-image and
> kernel-headers-* packages below are produced by the common
> kernel-image package. In order to apply arch/subarch specific
> patches, it will use the --added-patches mechanism of the
> make-kpkg, infrastructure for it is already in place (well, I was
> not counting that added patches may be flavour-specific, but this
> is easy to correct).
>
> kernel-headers-$(version)-$(abiname)
> This is arch-specific headers package containing all the common
> headers/configs/Makefiles, etc.
In the three level archs, this one is subarch specific.
> kernel-headers-$(version)-$(abiname)-$(flavour)
> This is flavour-specific headers package, containing the
> flavour-specific headers/configs/Makefiles, etc. This should
> depend on the arch-specific kernel-headers package above, and
> setup the symbolic links to the dirs in it, so that the
> /usr/src/kernel-headers-$(version)-$(abiname)-$(flavour)
> directory contains the complete tree, needed for building of
> out-of-tree modules.
and this one is exactly the powerpc kernel-build. The only difference is the
different naming of the package. I have considered renaming k-b to k-h on
powerpc, but since i have a powerpc subarch and a powerpc flavour inside this
subarch, there is a name clash that stopped me from doing this renaming, and
which could also involve some confusion, so better to be avoided.
Alternatively, one could consider :
kernel-headers-$(version)-$(abiname)-$(subarch)
and
kernel-headers-$(version)-$(abiname)-$(subarch)-$(flavour)
where subarch could be empty in the case of the arches who are only two
levels.
Still, there is no fundamental difference between our two proposals, except a
naming scheme, and the fact that you don account for 3-level archs.
> kernel-image-$(version)-$(abiname)-$(flavour)
> Kernel image matching the above kernel-headers package.
You hAve a second set of kernel-images ? :)
> In order to build the out-of-tree modules one then has to install the
> kernel-headers-$(version)-$(abiname)-$(flavour), corresponding to
> their kernel. This will pull in the arch-specific headers package and
> provide the complete tree. Note, that
> kernel-headers-$(version)-$(abiname)-$(flavour) package should provide a
> symbolic link
>
> /lib/modules/$(version)-$(abiname)-$(flavour)/build ->
> /usr/src/kernel-headers-$(version)-$(abiname)-$(flavour)
>
> the same way the kernel-build package on powerpc currently does.
Indeed, it is an artificial naming scheme difference, which has no influence
on the semantics of the different packages.
> >The last point is of the files needed to support the different kernel
> >'packaging', the powerpc kernel supports mkvmlinuz by copying a couple of
> >object files from arch/ppc/boot into the kernel-image, as to be able to do
> >the
> >last step of the zImage.chrp|prep|... construction at install time, and
> >embedd
> >initrds. Other arches have similar needs, but maybe separated tools to do
> >this
> >job. The work of calling them should go into the individual kernel-image.
>
> Right, I've completely missed this possibility, will have to look closer
> at it. Regarding your proposals for discussion on other topics, I do not
> have anything to say yet. I definitely plan to draft some sort of howto
> for building the out-of-tree modules one we have settled the unified
> packaging scheme for all arches.
Well, my main intention on this is to have all those third party external
modules handy, so that we can automatically rebuild and upload them in an
abi-change case, without having to wait for a random, undetermined, and
possibly non-finite time before the third party module maintainer notices and
acts. That and making sure all third party module packages provide prebuilt
modules for all arches for the official debian kernels.
Friendly,
Sven Luther
Reply to: