[Pkg-utopia-maintainers] Bug#1042981: Multiarch pitfall: polkitd fails to start if not installed in native architecture

[Simon McVittie]

On Tue, 12 Mar 2024 at 22:30:01 +0100, Michael Biebl wrote:
> On Wed, 9 Aug 2023 04:05:43 +0200 Bertram Felgenhauer <int-e at gmx.de> wrote:
> > My speculation is that this happened while satisfying dependencies for
> > a third party i386 application. That meant installing required 32 bit
> > libraries, and one of them must have come with a polkitd dependency,
> > and the i386 version was selected because I was installing an i386
> > package.
...
> Is there a valid use case where we need/want a foreign systemd/policykit-1?

The valid use-case for polkitd being Multi-Arch: foreign is the scenario
Bertram described: you install third-party, potentially binary-only
i386 software onto an amd64 system, and it depends on polkitd. We want
polkitd:amd64 to be able to satisfy that dependency.

That's also why we want systemd(-sysv) to be Multi-Arch: foreign:
for example the i386-only quake4-server needs systemd (in that case
it's actually a only Recommends, because you don't *need* to use the
systemd units, but it could in principle have been a Depends) and we
want systemd(-sysv):amd64 to satisfy that dependency.

I don't know of any valid use-case for polkitd and systemd(-sysv)
being of an architecture that is not the same as the system's primary
architecture, except for perhaps briefly during crossgrading, but that
isn't what Multi-Arch: foreign means anyway.

"The primary architecture" really just means "the same architecture
as dpkg", and I don't think there is any metadata that could be set on
polkitd or systemd to say that they must be of that same architecture.

    smcv