Roland McGrath wrote:
> I kinda like it in %name whichever route we go here. Along the
> 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
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
18.104.22.168-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
Despite those issues, I still vote for the %name change.