Re: FLAME____ Why is the kernel source not included

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux