Bug#943465: fwupd is wrongly marked Multi-Arch: foreign
> -----Original Message-----
> From: Helmut Grohne <helmut@subdivi.de>
> Sent: Saturday, October 26, 2019 1:16 AM
> To: Steve McIntyre
> Cc: 943465@bugs.debian.org; debian-cross@lists.debian.org
> Subject: Bug#943465: fwupd is wrongly marked Multi-Arch: foreign
>
>
> [EXTERNAL EMAIL]
>
> 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.
>
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
> 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: