TL;DR: The *.efi images must not live in a M-A:foreign binary package.
fwupd is presently marked Multi-Arch: foreign. Likely for good reasons.
Unfortunately, this is subtly wrong. fwupd contains (unsigned) efi
binaries in /usr/lib/fwupd/efi. These binaries have
architecture-dependent names. When you cross build fwupd-armhf-signed
from amd64, it tries to sign fwupdx64.efi and the build fails.
Now we have two possible routes. Either fwupdx64.efi is part of the
interface of fwupd. Then clearly the interface is architecture-dependent
and the Multi-Arch: foreign marking is wrong. In the other case,
fwupd-armhf-signed is accessing an internal aspect of fwupd and must not
do that. The latter would essentially mean that cannot have
fwupd-armhf-signed, so the former seems more plausible.
Simply removing the foreign marking isn't going to make us much happier
either (though it might fix cross building fwupd-armhf-signed). I think
what we need here is recognizing that fwupd has both
architecture-independent and architecture-dependent interfaces. The
logical consequence is splitting the package into two (usually one being
M-A:foreign and the other M-A:same).
So I see two possible routes here:
1. Remove M-A:foreign. (Nobody likes that)
2. a. Move the efi packages to a separate non-M-A:foreign package.
b. Have fwupd depend on that new package.
c. Rename the fwupd dependency of fwupd-armhf-signed to that new
package.
Helmut
Thanks for the heads up. I took a stab at how this should work here (not yet merged): https://github.com/fwupd/fwupd/commit/809eb181f57dc5158b5d37d2855a0a48eafc3565 Can you please review that and make sure you agree it's done correctly?
complex. You split the various firmware packages into fwupd-$(DEB_HOST_ARCH)-unsigned. Why did you do that? Why not have one real fwupd-unsigned package? Clearly you intend them to be coinstallable, which is why you marked them M-A:same. Note that M-A:same doesn't make sense, when you only list one specific architecture in the Architecture field. Can you maybe do the following? d/control: Package: fwupd-unsigned Architecture: amd64 i386 ... Multi-Arch: same no Provides: I also think that Built-Using must refer to real packages, which is not presently the case. My suggestion would ensure that. Helmut
Thanks for reviewing it. I made some modifications and think I captured your suggestion here https://github.com/fwupd/fwupd/commit/3508aecefdbd81924314834ac9e14bcd71aa253f Can you make sure that looks good now?
Thanks for the heads up. I took a stab at how this should work here (not yet merged): https://github.com/fwupd/fwupd/commit/809eb181f57dc5158b5d37d2855a0a48eafc3565 Can you please review that and make sure you agree it's done correctly?
Unfortunately, no. Ansgar Burchardt kindly pointed out that Built-Using must refer to a source package, not a binary package. This was wrong in the previous iteration and I didn't spot it. Refer to the debian policy section 7.8. Now there are two other subtle things left. Previously, fwupd included the *.efi images. Now it recommends them. Is that enough or should that be a hard dependency to retain the old behaviour? I don't know. Does fwupd actually work without the *.efi binaries? I'm also wondering why the signing-template includes the SIGNARCH in the package name. This is not a regression, but it should follow the same reasoning as for why fwupd-unsigned doesn't have to include an architecture. Do note that the same binary package may be built from different source packages for different architectures as long as now two source packages build it for the same architecture. For instance libsystemd-dev used to be built from different source packages for linux-any and kfreebsd-any. Can we simplify that part as well? Helmut
On Oct 25, 2019 14:46, Helmut Grohne <helmut@subdivi.de> wrote: [EXTERNAL EMAIL] Unfortunately, no. Ansgar Burchardt kindly pointed out that Built-Using must refer to a source package, not a binary package. This was wrong in the previous iteration and I didn't spot it. Refer to the debian policy section 7.8. Now there are two other subtle things left. Previously, fwupd included the *.efi images. Now it recommends them. Is that enough or should that be a hard dependency to retain the old behaviour? I don't know. Does fwupd actually work without the *.efi binaries? It used to be a hard dependency, but these days the runtime will detect this situation and show the user an error that the efi binary is missing so they can't do UEFI updates until installed. It was introduced about the same time we introduced signed binaries to Debian. I'm also wondering why the signing-template includes the SIGNARCH in the package name. This is not a regression, but it should follow the same reasoning as for why fwupd-unsigned doesn't have to include an architecture. Do note that the same binary package may be built from different source packages for different architectures as long as now two source packages build it for the same architecture. For instance libsystemd-dev used to be built from different source packages for linux-any and kfreebsd-any. Can we simplify that part as well? Helmut This was mostly copied off of what grub2 did, which split it up this way. I don't see a strong reason that it can't be adjusted (of course need to do package transitions and stuff). Steve, any thoughts?
Ummm, I don't think I follow your logic here at all. The normal system
pieces of the fwupd package (i.e. the bits that are executed by the
running Linux system need to match the arch you're running (to be
useful). But to be able to work on a normal system, the underlying EFI
binaries *must* match the hardware that's running (otherwise the EFI
firmware won't be able to use them at all). *However*, in some
circumstances (like building a live image) we want to allow
installation of all versions of the fwupd EFI binaries.
I think this particular situation is not well-described at all by M-A!
Maybe we could do something like:
* fwupd (non-M-A) - bits in /usr/{s,}bin, must have the right arch
installed
* (we could possibly split out some of the common data into a
M-A:foreign fwupd-data package)
* fwupd-efi (M-A:same) for each architecture
but I don't see how to ensure that the *right* fwupd-efi package is
installed for a system that wants to run it...
Hi Steve, I think I follow your requirements. Unfortunately, I very much concur with this. I (and others) tried hard to describe M-A, but we always run into a roadblock: M-A must talk about "interfaces" of a package and "interfaces" are not well-described at all by Debian. In other words: In order to describe M-A, we must describe what "interface of a package" means. Essentially it means "not everything a package ships is part of its interface, but sometimes it is an implementation detail". So here we were first thinking "the *.efi files are not part of the interface, so M-A:foreign is fine". Then I noticed that they're used by the sign package and thus I concluded that "oh they art part of the interface and M-A:foreign is thus wrong". Now we have a choice between removing M-A:foreign and changing interfaces (i.e. moving files to different packages). I don't see why removing M-A:foreign (or splitting a fwupd-data package) from fwupd would be required. All I said was that the *.efi files must not reside in a M-A:foreign package. Let me try to explain this in terms of interfaces. Suppose we keep the fwupd-efi (or fwupd-unsigned as it was previously called) package, have it contain the *.efi binaries and be M-A:same. Now we keep fwupd M-A:foreign. What does this do to multiarch? The package building that uses the *.efi files must not build depend on fwupd for that matter, because we say that the *.efi files are not part of the interface "fwupd". They're still used internally by fwupd. Instead you build depend on fwupd-efi (or fwupd-unsigned as it was called in the patch). All is well here. Now fwupd can depend on fwupd-efi. Given that dependencies always ensure same-arch constraints (unless M-A:foreign on the dependee, :any or :native is involved), fwupd will always get the fwupd-efi instance of the same architecture as itself. The M-A:foreign will practically ensure that the native fwupd is installed. The latest patch doesn't have that dependency, but turned it into a recommendation instead. Like dependencies, these are also preserving the architecture constraint by default. Does this help you, Steve? I don't feel like I've explained it particularly well. I've Cced d-cross@l.d.o now. Please keep them in the loop so maybe Guillem or Josch can do a better job at explaining this. Please bear with us and don't give up. Helmut
Recommends work no different from depends when it comes to the architecture constraint. Yes, this syntax does work. The architecture qualification is resolved at build time and the resulting binary packages will have the dependency exactly for those architectures that need it. This looks sane to me. Keep in mind that you also need to upload fwupd-*-signed. Helmut
I guess by this argument it really should be made into a Depends not a Recommends not because fwupd internally needs it to work but to ensure those architecture constraints get met effectively. Part of the reason to make it Recommends is that it only is needed for 4 architectures. I'm not sure if setting architecture specific dependencies is valid syntax, but if so this updated changeset should accomplish the goal. https://github.com/fwupd/fwupd/commit/88623a90fae36b61093c84198acfdba6bce3e533
Thanks for your confirmation. Steve, what do you think of this? Since it's going to need to be a NEW binary package I suspect you'll need to sponsor it for me if we agree to go this route. That part gets handled by some backend service when the new template packages are made.