Am 09.07.21 um 14:24 schrieb Helmut Grohne:
Now let's do something stupid. Rename systemd to systemd-core (taking all files with it, please refrain from discussing the name unless you seriously consider doing this). Mark it Multi-Arch: allowed. Add a new, empty binary package systemd. It is Multi-Arch: foreign and depends on systemd-core:any. This approach would technically satisfy all three requirements, but it feels a little crazy to me.
[..]
And I fear we have another related issue that we swept under the carpet thus far. man systemd.exec explains SystemCallArchitectures=native.
You are right. Thinking more about this, splitting out libsystemd-shared as a Multi-Arch: same library will not help with SystemCallArchitectures=native, which is used by the services in systemd-{container,journal-remote,...}. So splitting out libsystemd-shared, while in theory a nice solution, is not the right one in this case. We really need to ensure that systemd and systemd-* are of of the same architecture.
I still think that my idea of having a ":arch" annotation as counterpart to ":any" would be the most elegant way to achieve this. But since this is only an idea and not implemented, it's not something I can make use of. Do you think there is a chance we could convince dpkg and apt maintainers to add support for that?
Alternatively, your idea of systemd-core/systemd got me thinking.While I don't like the prospect of moving all (conf)files and state from one package to another, maybe we can turn this idea around.
We introduce an empty systemd-native package, which is Architecture:linux-any but *not* Multi-Arch: foreign/same/allowed.
systemd and all systemd-* packages would depend on systemd-native.This would link the architecture of systemd and systemd-* together and ensure they are the same.
Would this work for your cross-compile use-case? Michael
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature