On Wed, May 06, 2015 at 03:00:08PM -0400, Josh Boyer wrote:
On Wed, May 6, 2015 at 2:53 PM, Jarod Wilson <jarod(a)redhat.com>
wrote:
> On Wed, May 06, 2015 at 11:48:00AM -0400, Don Zickus wrote:
>> On Wed, May 06, 2015 at 10:41:28AM -0400, Josh Boyer wrote:
>> > > Not that my opinion matters much, but I think this is an interesting
>> > > mind shift. The end result is the same as today, just extra files in
>> > > /lib/modules/`uname -r`, right?
>> >
>> > Actually, I was hoping some other kernel maintainers would chip in so
>> > your opinion does matter. I really don't want to change this in
Fedora
>> > to only have it reverted in a future RHEL. Maybe Jarod or Rafael would
>> > be kind enough to review as well...
>>
>> Off the top of my head, if it works out for Fedora, I currently can't see a
>> reason RHEL would revert it. But that depends on what quirks falls out. :-)
>
> First pass through, I see a few oddities, some of which aren't the fault
> of this patch, but if manipulating these areas, might as well fix them
> up...
>
> 1) %image_install_path is never defined to anything but boot, for all
> supported arches. I think this is ia64 legacy, when it was /boot/efi, but
> we should just have a single define for it now.
>
> 2) we do this, both before and after the patch:
>
> mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/boot
> mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/%{image_install_path}
>
> ...which per #1, is obviously redundantly redundant.
>
> 3) after the patch, there are multiple install calls to put stuff into
> $RPM_BUILD_ROOT/boot/, but then they're %ghost'ed out. This seems a little
> bit of a waste, just do a touch for the /boot variants of those files and
> %ghost the same. Similarly, with the .hmac file, don't copy it around, put
> it where you want the real one, touch the %ghost.
Actually, I don't think we want to do that. We want to account for
the space that will be eaten by the real files that get copied to
/boot so that RPM can do it's disk space requirements estimates. We
don't want people to get 2/3 of the way installing a new kernel to
have it fail because they don't have sufficient space in /boot.
(We do something similar for the initramfs file already in a different
place, but that is literally generated from content outside the kernel
RPM so we can't just install a real file).
Ah, okay, that makes some sense. A bit wasteful on the packaging size, but
sound justification.
> 4) it appears there's already logic inside kernel-install to
copy the
> necessary files over to /boot at install time, and with the %ghost,
> they'll properly report as being part of the kernel package, but how long
> has that support actually been in kernel-install? Do you possibly want to
> add an explicit Requires: systemd >= x-y, as noted in the patch header? (I
> would).
Harald noted that all current Fedora releases are covered in the
initial posting. We could add an explicit systemd Requires, but it'll
just default to the oldest version in F20.
I think its probably safest to add it, lest someone try upgrading to this
kernel from F19 or something. I know its not supported, but we can at
least hand people the loaded gun with the safety on. :p
> Those issues aside, this doesn't really look all that scary
at all.
>
> One other thought: what happens when /boot is on the same file system as
> /usr and/or /lib? Does the file get unnecessarily copied, or is it
> hardlinked or _____?
Copied as far as I know. Yes it's slightly inefficient, but worrying
about that case (which isn't default at all) seems kind of pointless.
Yeah, really more idle curiosity, it'd be a systemd package issue
regardless, and wouldn't really directly impact this patch being accepted
or not.
--
Jarod Wilson
jarod(a)redhat.com