Roland McGrath wrote:
It is. And I was under the impression that's what Dave was thinking too, but I'll let him speak for himself.
Well, do we want it in the package set? I figured we were talking about "informal" builds that might be put up for ftp, but not be an integrated part of the Fedora world.
This would appear to be question #1 we need to get answered. :)
If one rpmbuild from the spec kicks out -vanilla packages along with other variants, and we turn that on only for rawhide, still it winds up "in the system", people install it as "normal" and wind up with upgrade issues and all that. Eventually we have clueless Fedora users saying "you use -PAE? well -vanilla is the Fedora kernel I like best!" and reporting in bugs "why this fix isn't in -vanilla too?"
I don't think that's too big a concern, we could be 100% firm that we don't apply any patches whatsoever (outside of nonintconfig), its pure upstream.
The main benefit I see is that it would be really nice to spin them off the exact same rpmbuild, since that would mean the only possible variance is the set of patches applied.
However, yeah, it being "in the system" could indeed be annoying. And it could be a bit of unnecessary overhead, resulting in an identical kernel if from one kernel build to another, all that changes is the patches we add.
So perhaps, building "unofficial" builds, of all varieties, does make more sense, and then we just point folks at them when they have issues with our normal kernels and want to compare w/an upstream build.
It's easy to tweak my changes to put "vanilla" into %name instead of %release. I went with "kernel" and a long, funky %release because that's the tradition I've experienced for one-off and test builds people distribute. From my own experience juggling a dozen installations on two or three test boxes with many hack kernels installed each in an utterly disorganized fashion, it seems more likely to get resolved usefully when doing upgrades and such than an rpm named "kernel-foobar". That is, yum and rpm will get in your face all the time in the way that people are used to for juggling kernel rpms. (Also, I always shudder in superstitious fear that yum or who knows what will assume things about the kernel rpm being the way it always has been.)
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. Otherwise, a vanilla build we only wanted someone to install for testing would trigger one of the user's two other installed kernels being un-installed with our current default yum setup.
With whatever name, separate vanilla builds could easily be made usable as their own little yum repository.
Okay, I think that's what I'm leaning toward now. :)
What is more work, and I think is more dubious, is having it be the same srpm that produces both fedora and vanilla builds. What will -bp do, make two source trees patched differently?
Good question...
That requires basically duplicating all the innards of the spec file. I don't think that should be attempted without a complete cleanup of the spec file to become sane.
More specifically, what I had in mind was to add just one more variant, so you'd have kernel, kernel-xen, kernel-kdump, kernel-PAE, etc., plus now a kernel-vanilla, which would be analogous to kernel minus patches -- i.e., don't bother with kernel-vanilla-xen, kernel-vanilla-kudmp, etc.
That's no fun! Seriously, I think we need the full suite of variants (modulo xen until that's uptsream, etc.) for it really to be useful. Plenty of people are using -PAE and the point is to compare the foo you're using to foo-vanilla on a one-to-one basis, i.e. different source, same .config settings. And you want -debuginfo for all of those too.
I'd have had vanilla-debuginfo built off the main spec too (plus vanilla-devel and vanilla-headers). But I'm persuaded to go all-out.
Not to say that a spec file sanitization/sane-itization wouldn't be good to do as well (which I'm also perfectly willing to take on -- a few steps in this direction were taken earlier today).
I despise how much duplication there is in there. The debuginfo stuff I originally did with rpm macros got hand-expanded because older rpmbuild couldn't cope with it. Maybe nowadays there is nothing with an rpmbuild older than FC-5 we are trying to work with
And we only have to care about FC-5 for another month or so, in which case I wouldn't bother worrying about anything but FC-6 and later.
so we could use more macros for new stuff. (I think brew got fixed to use the buildroot's rpmbuild, so anything that's fine for the target systems sharing the kernel spec source should be fine.)
Correct, the buildroot should be using the target system's rpmbuild.
rpm macros are a hairy mess, but cleaning things up with clean new macros is a better bet than anything else, IMHO.
Absolutely.
Cool, I'll read your patch more carefully now. :)
Here's the current version of it. You still need the nonintconfig patch variant I posted last time to go with this. I also attached below the shell script used by the GIT-using hacks that are in this version. http://porkchop.devel.redhat.com/brewroot/scratch/roland/task_703101/ shows what "make git/roland/scratch-build" does (the build magic works for "make git/roland-fedora/..." too, but the fedora patches don't apply to current upstream so it didn't build). This (the non-fedora flavor) is similar to the vanilla build, but automagically prepends:
%changelog
- Thu Mar 29 2007 Roland McGrath roland@redhat.com
- Experimental build from git sources (no Fedora patches)
- git tag: v2.6.21-rc5 6fb04ccf5c5e054c4107090bed6e866489f1089f
- git branch: upstream 28defbea64622f69d65a6079bf800cedb9915a5f
- git branch: roland 0ca00c859e7ac4d9d053abd06376233cb4f3bf84
and includes:
Patch1: patch-2.6.21-rc5.bz2 Patch2: linux-2.6.21-rc5-upstream.patch Patch3: linux-2.6.21-rc5-roland.patch
Thanks much, I'll try to digest all this over the weekend, and/or early Monday...
Still interested to hear what approach others think we should take to providing some "vanilla" kernels, but it would seem I'm now on board for your idea, but with "vanilla" (or "upstream" or "whatever") moved from %release to %name.