[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |