On Tue, Mar 23, 2021 at 6:36 AM Jan Beulich <jbeul...@suse.com> wrote:
> On 23.03.2021 13:34, Jason Andryuk wrote: > > On Tue, Mar 23, 2021 at 3:23 AM Jan Beulich <jbeul...@suse.com> wrote: > >> > >> 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. > > > > On Fedora, RPMs drop EFI binaries directly into /boot/efi/EFI/fedora/. > > grub, shim, fwupdate and xen are all packaged that way. It seems > > reasonable to have those important binaries tracked by the package > > manager. > > > > Does SuSE populate EFI_VENDOR from EFI_DIR when some boot loader > > script is called? > > Yes. And back at the time, when I consulted our EFI person, I was left > with the impression that this is the only reasonable approach. The > primary reason, as said, was that the EFI partition as a whole may get > rebuilt perhaps even from scratch at any point. Hence it's not > reasonable to expect package-managed files to live there. (This is > also expressed by us installing xen.efi into two places, which ought > to be a clear indication by itself that one of them is only to ease > things, not for packaging.) > Big +1 to the above -- in running our own distro we've come to appreciate that very point -- EFI partition is basically a cache and the source of truth is always elsewhere. Thanks, Roman.
