Re: 2.6.12 is in testing
On Wed, Sep 14, 2005 at 08:19:16AM +0200, Sven Luther wrote:
> Is this not the moment to modify the way our kernel .udeb packages are built,
> and either use a single package building all .udebs or at least some common
> infrastructure for building them all if there is still problems in the
> archive, i feel that anything else would be unreasonable now that all arches
> are built from the same source packages (except mips/mipsel, but they will be
> folded in soon, i hope).
>
> Also, i propose that we rename the kernel .udebs to use the linux- prefix, as
> the .debs have done, to pave the way of futur non-linux support (hurd, *bsd or
> others like opensolaris maybe). This sounds a good time to do so.
>
> The next point would be for base-installer/kernel. I have thought about it
> some, but me talking about that on irc faced only a huge wall of silence, so i
> make the proposal here again.
>
> The gist of it is that :
>
> 1) modifying b-i/kernel will break sarge installs with the etch/sid d-i's.
It is possible to allow both kernel-image and linux-image at the same
time. At least I tried to do so when I modified the sarge installer
to handle linux-image-2.6.12 for amd64 a couple of months ago, although
I didn't keep any kernel-image on the cd so I didn't actually test it.
> 2) the kernel .debs are now built from a common package, and it doesn't
> really make sense to have 12+ different code snipplet, all being subtly the
> same but with individual differences in b-i/kernel.
>
> So, the secon proposal is to :
>
> 1) keep the sarge code as is, and use it only when installing sarge.
>
> 2) propose a new unified b-i/kernel code aiming at etch/sid kernels, and
> using the linux-image-<flavour> thingy.
>
> This new code could probably just use some per-arch rules to detect flavours,
> and it would even be possible in the long run to migrate that code to the main
> linux kernel packages, in order keep it at one place only, also porters know
> best what flavours match what subarches and so on, but we will see.
>
> The last point is that i would much prefer a 1 module per .udeb solution over
> the existing mess (where modules are assigned to .udebs in a rather arbitrary
> fashion, which often break on non-mainstream arches/subarches). I hear this
> has too much of a packaging overhead (but is this really the case ? Anyone
> claiming this can argument this case with real info ?), so another solution
> for the kernels could be found, where modules are not-packaged ?
Well how much overhead does a package have? 500 bytes? 100? 2000?
How big is the average kernel module? Looking at 2.6.12 on i386 it
appears to be about 27k/module on average. What is the block size of
initramfs (if it has such a concept).
> Anyway, i had a look at the "packaging overhead". Each module .udeb contains a
> (rather short) control file (498 bytes for the hfs powerpc modules), a file
> hierarchy, and the modules. The overhead over just the modules. The overhead
> seems to be 4k per directory node, and a half k for the control file. So is
> this really an overhead we are worried about.
>
> The only real problem would be the number of packages issue, but if we go this
> way, we could build the .udebs automatically from the kernel packages, and
> then have the whole kernel build problem take only a couple of days for all
> autobuilders to build the packages, and there would be no delay due to the
> kernel for d-i.
Len Sorensen
Reply to: