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@xxxxxxxxxx
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Fedora-kernel-list mailing list Fedora-kernel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-kernel-list
