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.