On Mon, Jan 13, 2014 at 6:00 PM, Jarod Wilson <jarod@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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
_______________________________________________
kernel mailing list
kernel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/kernel
