Re: kernel-{image,headers} package bloat
On Tue, Apr 17, 2001 at 09:56:47PM +1000, Herbert Xu wrote:
> Craig Sanders <cas@taz.net.au> wrote:
>
> > is this kind of package bloat really necessary?
>
> IMO yes. I don't know about you but there were two reasons why I
> didn't use a precompiled kernel in potato. One of them was the
> inclusion of unneeded drivers which went away with initrd. And the
> other was the fact that it was compiled for 386.
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.
> 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.
it makes about as much sense as "since cows give milk, it made sense to
have different kinds of sheep to provide different kinds of wool".
> > all these packages take up around 110MB, and if every kernel has the
> > same number of packages available (approx 25 per kernel version),
> > will bloat the Packages file to an absurd size.
>
> 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?
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.
> > this will waste a lot of space on mirrors, and cause dpkg to be even
> > slower than it already is.
>
> 100MB is a negligible price to pay for the CPU cycles saved from
> people having to compile kernels needlessly.
it's far from negligible. in bandwidth, that's 100MB * the number of
mirrors - repeated every time there's a new kernel version uploaded.
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.
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.
all that space and bandwidth is wasted to provide something that is not
only unneccessary, it is actively detrimental: people should compile
custom kernels for their own machines, the debian-supplied kernel is
good enough for installation but not suitable for running a system on.
i guess that your next argument will be that it's important to cater for
people who aren't capable of following simple instructions for building
their own kernel (kernel-package makes it trivially easy to compile and
install a new kernel).
why should everyone else suffer the wasted bandwidth and/or the cost
of an extra CD to cater for people who would probably be better off
sticking to windows anyway? if they can't even compile a kernel and
aren't willing to learn how then linux is too hard for them.
> 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.
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.
and more again when 2.5.x kernels are available.
> > what's wrong with just one kernel-image that works with all i386
> > clones and the kernel source package for people to compile their own
> > kernels? it's worked well for us in the past.
>
> Well I never actually used any myself for the reasons I've outlined
> above, and I supsect many others don't use them for the same reasons.
see, they worked. they're installation kernels, not run-time kernels.
for the handful of people where they work as both, that's great....but
i don't see any justification for wasting the CD space and bandwidth on
something so trivial and unncessary.
craig
--
craig sanders <cas@taz.net.au>
GnuPG Key: 1024D/CD5626F0
Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Reply to: