On Mon, Jan 13, 2014 at 5:25 PM, Jarod Wilson <jarod(a)redhat.com> wrote:
On Mon, Jan 13, 2014 at 04:07:06PM -0500, Josh Boyer wrote:
> On Mon, Jan 13, 2014 at 3:53 PM, Paul Bolle <pebolle(a)tiscali.nl> wrote:
> > Josh Boyer schreef op ma 13-01-2014 om 15:41 [-0500]:
> >> As far as I know, nobody actually uses buildid to differentiate between
> >> kernel builds.
> >
> > Well, I do!
>
> OK, so it would be fairer to say "it is infrequently used". :)
Its actually used on a very regular basis by some folks for one-off
builds. However, said folks are pretty much all internal to Red Hat, doing
RHEL builds. For example, I craft a test build via 'make rh-srpm
BUIDLID=".test_foo"', which subs in the BUILDID value for the buildid bit
in the spec file. We can of course just graft that back in when RHEL8
branches from Fedora <20 + mumble> in the future. But I personally like
having the "edit this" part on its own line as its own thing regardless.
You can have a spec file patch or script that does it much more simply
than if you have to worry about other things that might be in the var
you want to tweak.
OK, I guess I'll just drop this one. So much for low-hanging fruit.
As an aside, some of the other changes I'm playing with to split up
the kernel packaging so the cloud people get a tiny kernel to install
are much more invasive. In terms of RHEL<mumble> they'll be a much
bigger impact. They will likely need to be adopted in RHEL land
eventually and not reverted/replaced. I will, of course, post them
first because I'd like review for a bunch of different reasons. I've
already posted this on some of the other discussions, but the general
premise is splitting it into kernel-core and kernel-drivers packages.
josh