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