On Mon, Jan 13, 2014 at 6:00 PM, Jarod Wilson <jarod(a)redhat.com> wrote:
On Mon, Jan 13, 2014 at 05:43:45PM -0500, Josh Boyer wrote:
> 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.
Note: the variant of the buildid stuff in the fedora spec looks far more
complicated than what is in the rhel7 spec. There are only 2 lines of spec
goo with buildid on them. I'd certainly endorse a patch that stripped out
all the extraneous crap. All I really need is:
# % define buildid .local
and
%define pkg_release %{fedora_build}%{?buildid}%{?dist}
Yeah, I'll look into that.
> 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.
Heh, history repeats itself, somewhat (kernel, kernel-unsupported). Just
kernel-core and kernel-drivers or perhaps kernel-core,
kernel-network-drivers, kernel-storage-drivers, etc? (and with a "kernel"
meta-package that requires all of them).
Variations on the theme, but yes. I have kernel-core and
kernel-drivers working for the ultimately simplistic cases with the
kernel meta-package requiring both of them. Where it currently breaks
is flavors, which winds up with e.g. kernel-debug-core,
kernel-debug-drivers, but no kernel-debug meta-package. I just
haven't gotten back to it yet.
Once I get them working, the real "fun" is going to be getting the
content of those packages settled. I'm sure kernel-core is going to
have to be more than just the contents of /boot, which is all it is in
my initial test runs right now (with -drivers being the /lib/module/
content). For that though, I'm waiting on the cloud people to tell me
what they need other than "uh... small!"
josh