Spinning kernel-vanilla packages via standard spec

[Jarod Wilson]

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 at 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.

-- 
Jarod Wilson
jwilson at redhat.com