kernel-2.6.11-1.1166_FC4.src.rpm

Paul Iadonisi pri.rhl3 at iadonisi.to
Sat Mar 5 02:05:15 UTC 2005


On Thu, 2005-03-03 at 22:37 -0500, David Cary Hart wrote:
> On Thu, 2005-03-03 at 22:24 -0500, Matthew Miller wrote:
> > On Thu, Mar 03, 2005 at 09:55:54PM -0500, David Cary Hart wrote:
> > > No. What has been widely discussed is the elimination of the pre-
> > > compiled kernel-source. HOWEVER, I have always been able to compile the
> > > kernel-source myself from the src.rpm. The current src.rpm does not have
> > > the code necessary for creating kernel-source. There is no way to
> > > customize the FC4 kernel without hacking the config files which is a
> > > VERY bad idea.
> > 
> > I don't get it -- you're already rebuilding the kernel source RPM. Why is it
> > even a slightly bad idea to add your customizations at that level? Sounds
> > like a _excellent_ idea, in fact.

  It is an excellent an idea.  And it's one that I've been doing for
over five years with, I would wager, far fewer problems than using a
'binary' kernel-source rpm (or kernel-sourcecode in its later
incarnations) and the upstream tools to build a kernel.
  It always struck me as just plain wrong to have a full kernel source
tree that it's heavily modified by the kernel build process itself when
that tree is managed by rpm.  I substantially defeated the purpose of
having it managed by rpm.  And it left detritus around when you removed
the rpm.  Lots of it.  Even when I had it installed on many of my
systems, I typically used it only for reference, or to copy over to
subdir in my home dir to build a test kernel there.
  One thing Mr. Hart has mentioned though is a problem, but absolutely
not 'perilous'.  Don't worry about the 'do-not-edit' warnings in the
config files.  They are there because the upstream kernel build tools
put them there, not because it was a conscious decision by the kernel
rpm packager.  Sometimes CONFIG_* dependencies and conflicts can be a
bear to deal with, but in most cases they are quite simple.  Just a
quick look at the Kconfig file in the area you are changing usually
reveals what else you may need to change.
  But when that fails, just copy the relevant config file to '.config'
in the kernel dir, do 'make oldconfig' (I believe) and pick your
options.  When your done, you have a .config that you can copy back to
the proper name for your rpm build to pick up.
  Oh, and don't forget to change your Release: tag to something
meaningful before doing 'rpmbuild -ba' on your spec file.
  This 'new way' takes some getting used to, but in the end, having your
custom kernel managed by rpm, in most cases, makes your admin job much
more manageable.
-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets




More information about the fedora-devel-list mailing list