Need help with Multi-Arch in systemd

[Michael Biebl]

Hi,

a couple of days ago, the following bug report was filed against systemd
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990547

I'm quoting the relevant parts

> I noticed that systemd-machined was failing to start on an arm64
> box. This box had armhf enabled, and turns out systemd had been
> cross-graded over to systemd:armhf[*]. It still had
> systemd-container:arm64 installed, so now I had an arm64
> /lib/systemd/systemd-machine, but an armhf
> /lib/systemd/libsystemd-shared-244.so.
> 
> libsystemd-shared-244.so is from the systemd package. Since systemd is
> marked Multi-Arch: foreign, systemd:armhf was able to incorrectly
> satisfy systemd-container:arm64's dependency on systemd.

The systemd package provides a package private library
/lib/systemd/libsystemd-shared-{source:Version}.so, which is used by 
binaries that are built from src:systemd. Some of those binaries are 
split into separate binary packages, like systemd-container.
Since both systemd is marked as Multi-Arch: foreign, it can happen that 
we get this architecture mismatch.

Asking on #debian-systemd, Marco d'Itri suggested, that we move 
libsystemd-shared into a separate binary package. This would only help, 
if we moved libsystemd-shared into a Multi-Arch location (which means, 
we'd have to carry a patch against upstream). It would also mean, that 
on every new upstream release, systemd would have to go through NEW.
So I'm not very keen on doing that.

Option 2 would be to drop Multi-Arch: foreign from systemd. This would 
mean, that packages like libpam-systemd/libnss-systemd can no longer be 
installed for a foreign architecture (even though those modules only use 
architecture independent interfaces of systemd).

Option 3 is something I came up with after reading the Multi-Arch 
related wiki pages:
https://salsa.debian.org/systemd-team/systemd/-/commit/c379461a14dcd13e0b625bd8faabbcf7fb3d19d6
It would mean marking systemd as Multi-Arch: allowed. And packages that 
only use architecture interfaces of systemd would have to use the :any 
annotation.


I would appreciate feedback, if option 3 is proper solution or not, or 
if there are other, better alternatives. If we go with option 3, should 
I inform all rdeps of systemd to update their dependency accordingly, 
i.e. do a MBF?
Currently, I only see interpreters like perl, use M-A: allowed, so I'm 
not sure if I'm misusing this feature.

Regards,
Michael



-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20210708/4b3fccbb/attachment.sig>