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. So you want some nice way of getting the specialized kernel onto the system -- sounds exactly like a job for an RPM _package_. 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. 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. This all becomes exponentially more true if you have more than one machine to deal with, but it's true on one system too. -- Matthew Miller mattdm@xxxxxxxxxx <http://www.mattdm.org/> Boston University Linux ------> <http://linux.bu.edu/>
