Spinning kernel-vanilla packages via standard spec

[Jarod Wilson]

Roland McGrath wrote:
>> I kinda like it in %name whichever route we go here. Along the same 
>> lines as Ingo's kernel-rt packages, it makes it easier to install them 
>> in parallel with normal kernels for testing. 
> 
> I was just remembering about Ingo's -rt builds.  I hadn't looked.  What he
> uses is nearly identical to what I wind up with.  It should be easy to use
> a unified spec file for his -rt patch version too.

Definitely doable. Probably lots more %if'age in the spec, but hey,
there's already a ton...

> I've tweaked my hacks slightly to use name: kernel-vanilla and
> kernel-branch for the git stuff.  For git builds, it now produces
> e.g. kernel-upstream-2.6.20-2.6.21.rc5.97.1.3025
> or kernel-roland-fedora-PAE-2.6.20-2.6.18.rc6.256.1.3025
> using the tag and "commit number" from git (1.5) describe, so upgrades for
> the same branch package should work right without the ginormous date string
> release numbers I had before.

If I'm understanding correctly, my current implementation isn't quite as
flexible as yours, as it only adds the ability to build kernel-vanilla
(and all sub-variants/bits), but it does do so for both released and
in-development -rc and -rc-git vanilla kernels. I've been toying around
with a few different variations, shuffling %name, %version and %release
around a bit, and I think I've come upon one that I'm liking.

My current version outputs a kernel-vanilla-2.6.21-0.rc5.git9.1.fc7 from
a 1.3040-based spec, which is (hopefully) obviously 2.6.21-rc5-git9. A
2.6.20.4-based build should wind up being kernel-vanilla-2.6.20-4.1.fc6
using similar spec tweaks, and a forthcoming F7 2.6.21 kernel ought to
wind up being kernel-vanilla-2.6.21-0.1.fc7.

> (Those changes are small but I don't have
> intermediate diffs on hand since I didn't commit the old version.  I can
> send you the new files if you want.)

Absolutely, shoot me whatcha got. I still have your prior changes in
patch form (as well as a good portion merged into a working copy),
extracting the diffs is no prob.

Renaming to kernel-vanilla while still using the same spec does
introduce a few problems I hadn't considered...

1) it breaks some build setups, where spec and sources are both
somewhere like %_topdir/sources/%name. The build gets confused if %name
is now kernel-vanilla. I can work around it locally with a symlink in my
build root, but something programmatic would be good. Haven't looked
into this much just yet.

2) kernel-xyz-headers is going to conflict with kernel-headers. Perhaps
solved by simply 'if kernel-xyz, kernel-xyz-headers Provides:
kernel-headers'. I've got this in my latest edition, will see how it
behaves...

Despite those issues, I still vote for the %name change.

-- 
Jarod Wilson
jwilson at redhat.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/kernel/attachments/20070403/c3b815dc/attachment.bin