Bug#943465: fwupd is wrongly marked Multi-Arch: foreign
On Fri, Oct 25, 2019 at 06:32:48AM +0200, Helmut Grohne wrote:
>Package: fwupd
>Version: 1.3.2-5
>Severity: important
>User: debian-cross@lists.debian.org
>Usertags: ftcbfs
>Control: affects -1 + src:fwupd-armhf-signed
>
>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.
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...
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"I used to be the first kid on the block wanting a cranial implant,
now I want to be the first with a cranial firewall. " -- Charlie Stross
Reply to: