[RFC] sysutils/fwupd: Make uefi-capsules plugin work

[sergii.dmytruk_3mdeb.com]

Summary

Fix gnu-efi producing broken binaries.

Needed to make fwupd-efi work.

Drop unused libefiboot dependency.

It's not needed since 2023.

Make fwupd work with native libefivar.

It's either native libefivar or the one from ports. Their API is incompatible. devel/efivar was needed for libefiboot, so it makes sense to not depend on it now, except that /usr/lib/libefivar can't be used if devel/efivar is installed due to -rpath. Linking to /usr/lib/libefivar.a as a workaround doesn't work, because it was not built with -fPIC.

Using devel/efivar requires different patches for fwupd and implementation of FreeBSD's ioctl() to deal with EFI variables in efivar. Both changes are available, but posting a simpler version first to get feedback about which approach is preferable.

Add patches to make uefi-capsules work on FreeBSD.

These will be sent to upstream which knows about FreeBSD, but which patches should be sent partially depends on which libefivar is going to be used in the end.

Questions to reviewers

Need to decide if the conflict with devel/efivar is acceptable or can be avoided.

Also, should bsdisks be added to the dependencies of fwupd? fwupd could be used without it, so maybe it should just be recommended.

Test Plan

• Make sure dbus is running and bsdisks is installed or ESP won't be found.
• bsdisks port must be the latest (reporting UUID was already upstreamed).
• fwupdtool plugins should show uefi-capsules plugin as functional.
• fwupdtool get-devices should show system firmware as updatable.
• fwupdtool install-blob update.cap should succeed and update after a reboot should also succeed.

ESRT sometimes wasn't present (efitable -t esrt) in QEMU and failed with ENODEV on hardware, likely because EFI loader doesn't move ESRT to EFI runtime memory before calling ExitBootServices(). This is, however, not in the scope of these changes.

[emaste]

devel/gnu-efi/Makefile

29–31

This comment seems a little confusing out of context -- in this diff it makes sense with the removal of the strip command, but now it's just here without context. I'd probably add something like "This port installs object files as lib/*.o. Previously it stripped those objects, but ..." to start off the comment.

This (stripping .o or .a) seems to have come up a few times in different ports and I'm not sure where the idea is coming from.

I think we could commit this part of this review independently first.