[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] xen: Create EFI_VENDOR directory



On 22.03.2021 18:08, Andrew Cooper wrote:
> On 22/03/2021 15:15, Jan Beulich wrote:
>> On 22.03.2021 15:59, Andrew Cooper wrote:
>>> On 22/03/2021 14:52, Jan Beulich wrote:
>>>> On 22.03.2021 14:33, Jason Andryuk wrote:
>>>>> make install-xen fails when EFI_VENDOR is set (=fedora) with:
>>>>> install: cannot create regular file 
>>>>> '/home/user/xen/dist/install/boot/efi/efi/fedora/xen-4.15.0-rc.efi': No 
>>>>> such file or directory
>>>>>
>>>>> Create the EFI_VENDOR directory so xen.efi can be installed within.
>>>>>
>>>>> This removes the need for Fedora and Qubes xen.spec files to manually
>>>>> create the directory in advance.
>>>> While I'm not strictly against, I'd like to point out that it was
>>>> deliberate to not create this directory here. I also didn't expect
>>>> anyone's xen.spec to do so. Instead I'd expect the distro to create
>>>> it during OS installation. If this was a bad assumption, I'd prefer
>>>> if the commit message here could point out why such an expectation
>>>> won't hold in general.
>>> This reasoning is broken for anything other `make install DESTDIR=/` on
>>> a live system.
>>>
>>> It is incompatible with how RPM, deb, etc packages work.
>> I'm afraid I don't understand, for both of your statements. If distro
>> installation put in place the designated directory, there wouldn't be
>> any live system lacking it, and there wouldn't be any concern in the
>> packaging of any software.
>>
>> To take a perhaps too extreme example - packages typically expect e.g.
>> /usr to exist as well, don't they?
> 
> No.  A buildroot starts out fully empty, by design.
> 
> The packaging environment (usually a chroot) invokes `make install
> DESTDIR=/path/to/staging/root` so you don't interfere with any of the
> tools inside the environment, and the resulting tar/cpio has the
> buildroot stripped out of paths.
> 
> The failure being discussed here is the build within the packaging
> environment, not the metadata which forms the final package.  Installing
> a deb/rpm/etc will make directories as applicable.

Ah, I see. But then this _still_ isn't the right thing to do. In fact,
the package build and installation shouldn't put xen.efi in the EFI
partition _at all_. The build system doing so is for developers only,
so they don't need to invoke boot loader configuration every time they
rebuild and re-install. Hence the packaging build shouldn't set
EFI_VENDOR in the first place. There it instead should be a subsequent
boot loader re-configuration which picks up xen.efi from its install
location (under $(EFI_DIR)) and places it on the EFI partition.

With the above I take back my "I'm not strictly against" - I'm pretty
firmly against. If the warning emitted is deemed a problem, I'm sure
we can find a way to silence it.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.