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@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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)