FLAME____ Why is the kernel source not included

Ken Johanson fedora at kensystem.com
Fri Oct 15 20:33:04 UTC 2004


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.





More information about the fedora-list mailing list