Re: kernel-{image,headers} package bloat
On Wed, Apr 18, 2001 at 11:05:09AM +1000, Craig Sanders wrote:
>
> that is the point of the debian-supplied kernel. it is meant to be a
> generic kernel which boots on as many different kinds of hardware as
> possible. use it to install the system, and then compile a custom kernel
> which suits your hardware.
That's where we disagree.
> > Since initrd removes the need for kernels which differed in their
> > inclusion of drivers, it made sense to make different flavours that
> > were optimised for common platforms.
>
> huh?
>
> there seems to be no logical relationship between the predicate and the
> conclusion in that sentence.
Well if you reread my messages, you'll see that there were two reasons
preventing someone from using the precompiled kernel. One of them
disappeared with initrd, hence it made sense to bite the bullet and
remove the other one by enabling CPU-specific optimisations.
> > That's easily managed by removing obsolete kernels from the archive.
> > If you're worried about it, start filing bug reports about any that
> > you happen to find.
>
> who's to say when a kernel is obsolete?
The various kernel maintainers do. It's alway been like that, except of
course they're usually not too fussed about removing old kernels unless
there are seriuos problems with it. But come release time, the obsolete
kernel packages certainly will go, unless of course there was a very good
reason for them to stay.
> e.g. 2.2.17 may be useless to you and me, but may be the only thing that
> boots on soemone else's machine.
Sure. That may be the good reason for some to stay around. However, this
is very very rare in my experience and certainly is not the case with 2.2.17.
> it's far from negligible. in bandwidth, that's 100MB * the number of
> mirrors - repeated every time there's a new kernel version uploaded.
If there is a general consensus that having these kernels isn't worth the
amount of bandwidth that it takes up, then I will remove them.
> even worse than that, 100MB is almost 1/6th of a CD-ROM. that's probably
> going to mean yet another CD in the next release.
That's the strongest argument I've seen so far. Perhaps we can hear from
someone who's responsible for making the CDs?
> if we include 2 kernels in the next release (a 2.2.x kernel and a 2.4.x
> kernel) that will be an extra 200MB on the CD images.
Not in this particular case, I will not support initrd on 2.2.x for i386.
In any case, this is a CD management issue. CD sizes is a problem in
general and will need to be addressed irrespective of what happens with
the kernels. Perhaps what we need is the ability to exclude certain
packges from CDs altogether, i.e., only make them available via the net.
Nevertheless, when such a solution is reached, this will become a nonissue.
> > And I doubt anyone can measure how much dpkg is slowed down by 20
> > extra packages.
>
> we currently have kernel images in unstable for 2.2.17, 2.2.18, 2.2.19,
> 2.4.0, and 2.4.2. 2.4.3 will no doubt follow soon.
2.4.0? I never compiled that. I will get 2.4.2 removed as soon as 2.4.3
is out for a week.
2.2.17 and 2.2.18 should be removed now. I've just filed bug reports
against ftp.debian.org to that effect.
> if all of them used the same package bloat model, that would be about
> 150 packages rather than 24. or (estimated) 170K of space in the
> Packages file.
When 2.2.17/2.2.18 gets removed, we'll only have 2.2.19/2.4.2/2.4.3, so
even if they did follow this model, that would be a mere 40K and not 170K.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Reply to: