On Fri, Oct 15, 2004 at 02:33:04PM -0600, Ken Johanson wrote:
> >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?
Okay. That part doesn't really matter. RPM is nicer on the same system too.
See below. I've actually been doing it this way for some time on the system
I use a custom kernel package for. (My laptop. I _could_ build the
customized package on that system, but it's nicer to build it on an Opteron
server and copy it over, so that the process doesn't take four days.)
> >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).
You get the source RPM from the net, just like you get any source RPM. Or
any binary RPM.
And yes, I'm suggesting that you rebuild the RPM. It's incredibly easy.
"Maintain" makes it sound like a much bigger process than it is -- after
all, if you're building a custom kernel, you're "maintaining" that source
tree already.
I'm talking about both binary RPMs and source RPMs -- after all, binary RPMs
are generated from the source ones.
> >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.
You don't need to prune the kernel source tree -- you leave the pristine
original source untouched. (That's actually one of the basic rules of making
a good RPM.) You then edit the config file from which the new kernel will be
built -- just like you'd do if you were building the kernel tree on its own
(use menuconfig or whatever). Then, you tell RPM to build the kernel with
that config file, and the resulting binary RPM contains only the part you
want.
> >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').
It is an initial extra step, but in my experience, it's far outweighed by
the convenience later.
Plus, RPM-building skills are useful to anyone participating in the Fedora
project, or using any RPM-based distribution. It's not kernel specific,
after all.
--
Matthew Miller mattdm@xxxxxxxxxx <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
