Re: 2.6.12 is in testing
On Wed, Sep 14, 2005 at 09:46:32AM -0400, Lennart Sorensen wrote:
> On Wed, Sep 14, 2005 at 03:28:30PM +0200, Sven Luther wrote:
> > 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.
>
> Well is 2.4 kernel images being dropped from etch? Are the archs that
> still use 2.4 going to update their images to be linux-image-2.4.x?
Well, the goal is indeed to drop 2.4 kernels for most arches in etch, and
failing that to have a unified kernel for the remaining arches/subarches that
have these 2.4 kernels still left.
In the meantime we need indeed to keep something akin to the old code for 2.4
kernels, maybe doing something like :
if sarge | 2.4 kernel then use the old code else use the unified code.
> Unified rules sure sound nice.
>
> > Also, keep in mind that some of the flavours changed between the new packages
> > and the old stuff.
>
> Well some like -586 seem to have disappeared if I remember correctly.
powerp4, power4-smp, power3, power3-smp have been changed to powerpc64.
all hppa flavours renamed to include hppa.
some other renames like the hppa one i don't remember.
> > 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 :
>
> Ah, good point.
>
> > 1) the archive space used up on the mirrors.
> So the overhead of 1000+ potential modules (although wouldn't some of
> them like sound be worth stripping out as irrelevant to the installer?)
We would only package those needed for the installer, we can list those in the
.udebs actually, there should be around a 100 or so. multiplied by around 50
flavours (maybe less) this brings us around 5000 packages.
> > 2) the space used up on the cd medias.
> At 2k blocks, 1000 modules would probably add an extra 1M of wasted
> block space (assuming each wastes 1/2 of 2K each). Probably not a big
> deal really. Well plus any overhead from the package header and
> potential loss of compression due to a smaller amount of data to work on
> in each package.
Well, we may have multiple flavours per arch, but there will definitively not
be in the 1000 modules involved here.
> > 3) the actual download size of the .udebs.
> On the other hand, what if you didn't have to download as many? Would
> the installer be able to save ram by not having to load unnecesary
> modules?
Indeed, i was not going to list pro arguments though :)
> > 4) maybe the time it takes to process the Packages file on slower arches,
> > and the effect .udeb multiplication has on this.
> That could be annoying.
Could be, on the other side, slower arches probably have less modules, and
this should be less of a problem.
Friendly,
Sven Luther
Reply to: