Re: 2.6.12 is in testing

[Sven Luther <sven.luther@wanadoo.fr>]

On Wed, Sep 14, 2005 at 09:18:55AM -0400, Lennart Sorensen wrote:
> On Wed, Sep 14, 2005 at 08:19:16AM +0200, Sven Luther wrote:
> > 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.

not sure i fully understand what you mean here. I guess you are saying you can
kind of fix the b-i/kernel rules to install either linux-image or
kernel-image, but that would be counter productive, now that we have some nice
unified packages, we can have a simple set of rules for all arches, and make
the code much more maitenable.

Also, keep in mind that some of the flavours changed between the new packages
and the old stuff.

> > 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).

We don't care about initramfs, because the modules which go into the initramfs
are already unpacked, and there is thus no overhead, the overhead can only be
concerning :

  1) the archive space used up on the mirrors.
  2) the space used up on the cd medias.
  3) the actual download size of the .udebs.
  4) maybe the time it takes to process the Packages file on slower arches,
  and the effect .udeb multiplication has on this.

Friendly,

Sven Luther