treewide: systemdSupport: use lib.meta.availableOn

[ghost]

Description of changes

Many packages have some kind of flag indicating whether or not to build with systemd support. Most of these default to stdenv.isLinux, but systemd does not build on (and is marked broken for) isStatic. Only a few packages have the needed && !isStatic in the default value for their parameter.

This PR moves the logic for the default value of these flags into systemd.meta.{platforms,badPlatforms} and evaluates those conditions using lib.meta.availableOn.

This provides three benefits:

1. The default values are set correctly (i.e. including && isStatic)
2. The default values are set consistently
3. The way is paved for any future non-Linux systemd platforms (FreeBSD is reported to have experimental systemd support)

Things done

• Built on platform(s)
  • (no post-eval change)
• Fits CONTRIBUTING.md.

[Ericson2314]

I don't think this is a good idea. Systemd is an init system, that's way removed from an intrinsic property of the platform.

What we should instead have is something that works for any package, like

systemdSupport ? systemd.meta.canBuild

indeed, we used to have something like that. Not sure why it was removed.

[ghost]

systemdSupport ? systemd.meta.canBuild

indeed, we used to have something like that. Not sure why it was removed.

I assume you mean something other than meta.platforms and meta.broken.

Ah, I see, you meant meta.availableOn: #114374

Please see latest push. In particular, it was necessary for 2daa429cc3205033a0ea7164aaff2a5117551fe7 to extend lib.meta.platformMatch to accept predicate functions, since isStatic cannot be defined structurally if pkgsStatic is involved.

[ghost]

Squashed.

[ghost]

Resolved merge conflict.

[flokli]

Thanks for your patience, and sorry this took so long!

[ncfavier]

Allowing functions in meta.{platforms,badPlatforms} isn't great for discoverability: nix-env checks meta attributes and will output "platforms": null if platforms contains a function, which in turn means that the package will have no platforms listed on search.nixos.org.

Can isStatic be made into a pattern instead? We still have to figure out how to display those but at least this wouldn't kill the whole attribute.

In any case I think the documentation for lib.meta.platformMatch should mention that using functions there is discouraged.

[ghost]

Allowing functions in meta.{platforms,badPlatforms} isn't great for discoverability

Yeah, and Nix's fragile function equality is not something we should expand our reliance upon. @sternenseemann has documented the full extent of how crazy it is, which goes way beyond just f != (x: f x). I opened this PR before that situation was fully understood.

Can isStatic be made into a pattern instead?

Not trivially. But I do think it is possible and was thinking of attempting it. @ncfavier would you be willing to review the result? If it turns out to be possible, I will include a revert of b7d0974 in that PR. Handling isStatic is the only justification for functions in meta.platforms.

[ncfavier]

@sternenseemann has documented the full extent of how crazy it is

Jesus. 🤯

would you be willing to review the result

Willing, sure. Capable, we'll see.

Handling isStatic is the only justification for functions in meta.platforms.

How about the stuff in lib.systems.inspect.predicates? Do they all map to patterns cleanly?

[ghost]

How about the stuff in lib.systems.inspect.predicates? Do they all map to patterns cleanly?

Yes; in fact the predicate functions are generated from the patterns.

Except for isStatic. It's the oddball.

Mainly because it's the only part of a hostPlatform that isn't determined by the gnu-config tuple (e.g. x86_64-unknown-linux-gnu).

[SuperSandro2000]

The python breakages where already fixed in #212391 and the other two things I fixed in #212613

[SuperSandro2000]

I don't like seeing this change and generally more often depending on lib.meta.availableOn for compile options because if we adjust platforms for a package we can silently disable features in other packages which where before expected to be enabled. This can't be easily be caught in review and I am expecting this to be the cause of unexpected breakages in the future.

[trofi]

nix-env does not support predicates and assumes plain strings. As a result nixpkgs-review complains at every review as has invalid meta attribute 'badPlatforms':

$ nix-env --option system x86_64-linux -f /home/slyfox/.cache/nixpkgs-review/pr-212919/nixpkgs -qaP --xml --out-path --show-trace --no-allow-import-from-derivation --meta
derivation 'systemd-252.4' has invalid meta attribute 'badPlatforms'
derivation 'systemd-minimal-252.4' has invalid meta attribute 'badPlatforms'
derivation 'systemd-stage-1-252.4' has invalid meta attribute 'badPlatforms'
derivation 'systemd-stage-1-network-252.4' has invalid meta attribute 'badPlatforms'

I'm surprised to see meta attributes not being plain values. It's not metadata if you need to evaluate it.

[ghost]

#212925

nix-env does not support predicates and assumes plain strings.

Only nix-env --meta is affected, not the rest of nix-env.

It's not metadata if you need to evaluate it.

In a lazy language like Nix everything needs to be evaluated:

$ nix eval --expr 'builtins.trace { x=(x:x) 3; } ""'
trace: { x = <CODE>; }

I think you meant to say something like "it's not metadata if you can't run builtins.toString on it". I'm not sure I agree with that either. Unfortunately nix-env --meta does, and it's part of the stable command set (nix-build, nix-instantiate, nix-env) so changing its behavior is the very last resort.

The long-term fix is to fix isStatic. I think I have a short-term fix in the meantime. See #212925

[ghost]

It's a bit rough, but this could be the long-term fix:

• meta: replace predicates with pattern over elaborated platform #212939

[alyssais]

I don't like seeing this change and generally more often depending on lib.meta.availableOn for compile options because if we adjust platforms for a package we can silently disable features in other packages which where before expected to be enabled. This can't be easily be caught in review and I am expecting this to be the cause of unexpected breakages in the future.

I'm worried about package options that look at meta.broken, but I don't expect this to be a problem for meta.platforms, because as long as we're maintaining the conventional meanings of platforms being "where should this package work?", and broken being "where is this package not working because of bugs?", the only situation where we remove a platform from meta.platforms should be when we discover that the package doesn't work on that platform and was never intended to. In that case, disabling downstream optional features is exactly what we'd want to happen.