On Thu, May 19, 2005 at 02:04:33PM -0400, Jurij Smakov wrote: > As you might know, we are planning a transition to the common kernel > source, which is expected to build all the kernel-related packages, > eliminating the problems with arches getting out of sync, etc.
Are the problems with > 200 binary packages really fixed? If you want to
"fix" the problems, you have to integrate the udeb build process which
produces currently something about 300 binary packages.
> ===================================================================
> Background
> ----------
> There is currently no standard for naming and contents of the
> kernel-related Debian packages. The goal of this document is to
> provide a unified scheme for naming and contents of these packages
> across all architectures.
You speak about kernel but mean linux, do you?
> Packaging scheme
> ----------------
> To accomodate all the possibilities, the following packaging scheme
> (to be implemented by the common source package) is proposed:
>
> kernel-headers-$(version)-$(abiname)
> kernel-headers-$(version)-$(abiname)-$(subarch)
This needs to contain the scripts directory.
> 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.
cobalt mips/mipsel? Please clearify.
> kernel-image-$(version)-$(abiname)-$(flavour)
As all of them begin with kernel, how do you integrate netbsd and hurd
into this schema?
> * 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.
Why not use one package with the arch-specific and one with the other
parts?
Bastian
--
Men will always be men -- no matter where they are.
-- Harry Mudd, "Mudd's Women", stardate 1329.8
signature.asc
Description: Digital signature
