Bug#982456: lintian: systemd SystemCallArchitectures directive incompatible with M-A:foreign

[Helmut Grohne <helmut@subdivi.de>]

Control: tags -1 + moreinfo

Hi Guillem,

We concurrently wrote our replies, so this may duplicate your mail a
little.

On Wed, Feb 10, 2021 at 01:42:59PM +0100, Guillem Jover wrote:
> The systemd unit file directive SystemCallArchitectures is
> incompatible with Multi-Arch:foreign markings in a package, as that
> means once you install such foreign package, systemd will refuse to let
> it run.
> 
> Please tag this as an error.

I think this is an interesting aspect, but less clear than you picture
it.

If my foo:amd64 package ships a .service file with
SystemCallArchitectures=x86-64 and calls a binary from the same package,
then M-A:foreign can very well make sense. Thus far, this case is not
practically relevant, because no upstream .service file works this way.

If my foo:amd64 package ships a .service with
SystemCallArchitectures=native, then this is a problem, because native
here refers to the architecture of systemd and since systemd is
M-A:foreign, that can be any architecture. So we'd have to restrict this
error being signalled explicitly to the value native.

Unfortunately, that's the most likely value for upstreams to put there.

That puts us in a difficult situation. It's essentially Multi-Arch
versus hardening. What we'd want is "it just works".

I think we can do better with a little bit of support from debhelper.
debhelper already ships a dh_installsystemd that specially handles
.service units. How about extending it? Let me propose some pseudo-code:

if the .service unit contains SystemCallArchitectures:
    if the relevant binary package is Architecture: all:
        if the package is Multi-Arch: foreign:
            die with an error
    else:
        Let systemd_arch be the systemd name of the relevant package
	architecture.
        if the value of SystemCallArchitectures is native:
            Replace it with systemd_arch.
	if the value of SystemCallArchitectures is not systemd_arch:
	    die with an error

Doing so actuall changes .service files and it may make some existing
packages FTBFS. I think this is a useful tradeoff.

In this setting, packages would likely not have to change as debhelper
would take care of the fixups. So I wonder whether a lintian tag is
really necessary (assuming that debhelper can be changed). Tagging the
bug moreinfo for now.

Helmut