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
Attachment:
signature.asc
Description: Digital signature