Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 455438 - Patch for kernel RPM spec
Summary: Patch for kernel RPM spec
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.2
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Don Zickus
QA Contact: Martin Jenner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-15 14:36 UTC by Brian J. Murrell
Modified: 2008-07-18 21:46 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-07-18 18:28:03 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Brian J. Murrell 2008-07-15 14:36:45 UTC
I'd like to offer the following patch to the kernel RPM .spec file:

--- kernel-2.6.spec.dist	2008-07-08 08:44:25.000000000 -0600
+++ kernel-2.6.spec	2008-07-08 12:15:54.000000000 -0600
@@ -1939,14 +1942,14 @@
 # First we unpack the kernel tarball.
 # If this isn't the first make prep, we use links to the existing clean tarball
 # which speeds things up quite a bit.
-if [ ! -d kernel-%{kversion}/vanilla ]; then
+if [ ! -d %{name}-%{kversion}/vanilla ]; then
   # Ok, first time we do a make prep.
   rm -f pax_global_header
 %setup -q -n %{name}-%{version} -c
   mv linux-%{kversion} vanilla
 else
   # We already have a vanilla dir.
-  cd kernel-%{kversion}
+  cd %{name}-%{kversion}
   if [ -d linux-%{kversion}.%{_target_cpu} ]; then
      # Just in case we ctrl-c'd a prep already
      rm -rf deleteme

It simply propagates the Name: field into the executable portions of the
specfile, removing a bit of hard coding.

Comment 1 Don Zickus 2008-07-18 18:28:03 UTC
Thanks for the patch.  However, I don't think it is really worth it for RHEL-5
right now.  Unless of course, you guys modifed the %name field for whatever reason.

So I am going to close this a WONTFIX.  I do encourage you to submit this to the
fedora kernel list (fedora-kernel-list.redhat.com).  I am sure they will pick
this up because DaveJ gets excited when non-redhat people post fedora fixes. :-)

Thanks,
Don

Comment 2 Brian J. Murrell 2008-07-18 21:03:53 UTC
(In reply to comment #1)
> Unless of course, you guys modifed the %name field for whatever reason.

Indeed, that is exactly it.  We add Lustre to your kernel and call it
kernel-lustre, just to be clear about what it is we are providing.

> So I am going to close this a WONTFIX.

Fair enough.

> I do encourage you to submit this to the
> fedora kernel list (fedora-kernel-list.redhat.com).

Subscription required?  :-(

> I am sure they will pick
> this up because DaveJ gets excited when non-redhat people post fedora fixes. :-)

LOL.  I'll let him know you said so.  :-)

BTW: since we are discussing this, and maybe it should go through fedora first,
but just like you have your:

Patch99999: linux-kernel-test.patch

in your kernel spec, would you consider an always empty

Patch99998: linux-kernel-oem.patch

that an "aftermarket" (i.e. OEM) could plop their own patch into to build a
RHEL, customized kernel?  Or would you in fact advocate use of the 99999
"linux-kernel-test.patch?

Actually now that I think of it, what would be most useful would be:

Patch99998: %{oempatch}

where %{oempatch} could be defined with an "--with oempatch=$patch_file" option.

Comment 3 Don Zickus 2008-07-18 21:22:18 UTC
buildid doesn't work for you?

That is what we use internally.
So basing off a RHEL-5.2 kernel would look like

kernel-2.6.18-92.el5 -> kernel-2.6.18-92.el5.lustre

> I do encourage you to submit this to the
> fedora kernel list (fedora-kernel-list.redhat.com).

>Subscription required?  :-(

That sucks.  But I heard it was easy to signup for a fedora account.  Then again
I have no idea how I wound up on the list to begin with.

I understand your idea for an oempatch, but I would recommend the
linux-kernel-test.patch for now.  That was what is was there for, to quickly
shove in a patch and rebuild.  As for the --with oempatch option, I would have
to see a patch for the spec file because I am not even sure that can be done.

Cheers,
Don


Comment 4 Brian J. Murrell 2008-07-18 21:46:09 UTC
(In reply to comment #3)
> buildid doesn't work for you?

Ah, yes, indeed, buildid works wonderfully in fact.  We use that too.

> kernel-2.6.18-92.el5 -> kernel-2.6.18-92.el5.lustre

Indeed.  We even put a bit more into the buildid.

It's possible I might convince others here that we don't need to change the name
too, but we have done that for so long, and I think there is a desire to be
entirely explicit about the RPM we are producing.  I will bring it up though.

> That sucks.  But I heard it was easy to signup for a fedora account.  Then again
> I have no idea how I wound up on the list to begin with.

Yeah, I just subscribed anyway.  Predicted there might be some discussion and
not expecting people to CC me.

> I understand your idea for an oempatch, but I would recommend the
> linux-kernel-test.patch for now.

Indeed, it would work.  But then again, given that we have to patch the spec
anyway, adding a hunk to add an additional patch is easy anyway.  And then we
get to give it whatever name we want in the SOURCES dir.  If the only thing i
was patching the spec was to insert a patch I would surely use the 99999 patch.

> That was what is was there for, to quickly
> shove in a patch and rebuild.  As for the --with oempatch option, I would have
> to see a patch for the spec file because I am not even sure that can be done.

Fair enough.  I will see if I can create a patch for that in my next pass on our
kernel build hacking.


Note You need to log in before you can comment on or make changes to this bug.