Re: kernel-{image,headers} package bloat

[Rob Browning <rlb@cs.utexas.edu>]

David Schleef <ds@schleef.org> writes:

> I develop/maintain several packages that compile kernel modules
> outside the kernel source, and understand a lot about what is
> necessary to compile modules outside the kernel.  I have yet to see
> a header package in any distro that is actually useful in doing
> non-trivial module compilation -- there's just too much in the
> kernel that building modules _could_ depend on, such as including
> Makefile fragments, .config, scripts/makedep, etc.  Right now, the
> rift between what is neccessary (for me) and what is available is so
> large that I always recommend to people to build their own kernel,
> even if it is a standard configuration.  I'd be willing to help,
> since I think it is a good goal, but I think this thread is
> worthless.

Maybe this is untenable, but it's not like we're running Windows here.
We have amazingly powerful tools available, including the ability to
install a set of packages that can actually build the kernel itself.

I think someone else suggested something similar, but what would
prevent us from having a minimal set of kernel packages per arch,
maybe even just one, and then having a kernel-custom package that pops
up a debconf gui when installed, listing all the available
configurations[1], and once selected, builds and installs the
requested kernel, with all the modules that have been installed as
source packages.

[1] For extra brownie points, have one option on the gui be "Run make
    config directly?" and also make the FS location of the .config
    file public so people can just "cp" one there.  Also write the
    scripts to properly use "make oldconfig" as appropriate.  (BTW,
    Thanks Craig -- I had no idea that even existed...)

Other than the time required to build the kernel, this seems like it
might be better from a mirror storage perspective and from a "did I
get the right kernel and modules" perspective.

It seems like we have all the needed bits to do this, and it would be
*really* cool IMO.

As far as this thread is concerned.  I'm really sorry to see it.  It's
been a long time since I was watching debian-devel, and rather than
seeing people, many of whom I have substantial technical respect for,
working to try and understan the legitimate issues on both sides and
then to find a superior solution, I see them beating the crap out of
each other and wasting a lot of time.

Then again, if that wasn't happening, I suppose I'd proabably wonder
if I was reading the wrong list :>

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930