Bug#943465: fwupd is wrongly marked Multi-Arch: foreign
Hi Steve,
On Fri, Oct 25, 2019 at 10:55:30PM +0100, Steve McIntyre wrote:
> >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 I follow your requirements.
> I think this particular situation is not well-described at all by M-A!
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).
> 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
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.
> but I don't see how to ensure that the *right* fwupd-efi package is
> installed for a system that wants to run it...
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
Reply to: