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/c379461a14dcd13e0b625bd8faabbcf7fb3d19d6It 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
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature