[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] xen: Create EFI_VENDOR directory
On 23.03.2021 14:41, Ian Jackson wrote: > Jan Beulich writes ("Re: [PATCH] xen: Create EFI_VENDOR directory"): >> On 23.03.2021 13:34, Jason Andryuk wrote: > ... >>> 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. > > I agree with this analysis but it is for people like Fedora to decide > how they want to build their packages. > > There is also the case of ad-hoc packages (eg our "make debball") > which the user might reasonably choose to have dump things in the EFI > system partition. Well, it that's deemed reasonable, then perhaps yes. Albeit such ad-hoc packaging could then also involve the creation of that dir. > Conversely, I see no downside to the mkdir. Jan, is there some actual > harm in it ? If not, we should be accomodating to people's build and > packaging strategies even if we don't entirely approve of them. "Actual harm" is relative: Nothing's going to break afaict. There'll be a leftover dir from an install immediately followed by an uninstall. I consider such okay for the purpose of the install step that I did outline; I wouldn't consider it okay for a package install/uninstall. But nothing worse, I guess. So bottom line - my objection is not to be taken as a NAK. If everyone else wants the change, then so be it. Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |