Bug 455438 - Patch for kernel RPM spec
Patch for kernel RPM spec
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.2
All Linux
low Severity low
: rc
: ---
Assigned To: Don Zickus
Martin Jenner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-15 10:36 EDT by Brian J. Murrell
Modified: 2008-07-18 17:46 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-18 14:28:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Brian J. Murrell 2008-07-15 10:36:45 EDT
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 14:28:03 EDT
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 17:03:53 EDT
(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 17:22:18 EDT
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 17:46:09 EDT
(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.