Fedora Users — Re: FLAME____ Why is the kernel source not included

Matthew Miller wrote:

On Fri, Oct 15, 2004 at 12:44:13PM -0600, Ken Johanson wrote:
some performance related (opinion varies), some hardware compatibility related (you may need to build modules *into\* the kernel to boot certain devices), security related (removing untrusted/unneeded modules from the core), and even just to to incremental upgrades/bugfixes (downloading only updated module instead of the whole source lib).
These are great examples of why you want to build from a source RPM.

For hardware compatibility, if the machine won't _boot_ without a special kernel, you're clearly not building on that machine itself.

Unless, say, I'm changing its boot device after the fact to be Raid, Scsi, etc... right?

So you want some

nice way of getting the specialized kernel onto the system -- sounds exactly like a job for an RPM _package_.

We may be going in circle here - how do you propose I "get" this source RPM? And are you prosing I *maintain* (rebuild) the rpm when I do incremental upgrades?? And are you talking about source or binary rpms? (not sure you stated).


If you're removing kernel features for security, having a new package with
the parts you don't want just _gone_ seems much cleaner than having the old
kernel managed by RPM with a new kernel with some missing parts smeared on
top of it.

This I agree with in respect to the rpm packaging, but pruning the physical tree is less practical than the Old" way of simply defining which modules go in and not.. So then are you suggesting that I take a kernel-source RPM (manually obtained -- from redhat? from kernel.org?), prune it, compile and repackage it? It sounds to be all good intents but not practical when just the request modules will be compiled anyway.


For incremental changes, keep the same original source RPM, and add in your
tiny little patch -- without mucking with the pristine original. (RPM is
great for this.) You can do this over and over, and the RPM package release
numbers and changelog provide a convenient (and standardized) way to
document the differences.

Again a very good argument, but I personally just dont need the rpm (additional steps, time, training), and there remains the question of where to conveniently get it and what is going to manually prune the unwanted nodes ('missing parts').


This all becomes exponentially more true if you have more than one machine
to deal with, but it's true on one system too.

Certainly agreed. Good points.