Merge pull request #112819 (mkIf in systemd units)

@thelegy writes:

  unitOption is only used inside of attrsOf wich is perfectly capable of
  handling the attrsets from mkIf, though the checkUnitConfig test
  forbids it.

  This commit weakens that restriction to allow the usage of mkIf inside
  of systemd.services.<name>.serviceConfig.<something> etc.

While I personally don't like that we can't easily use
pushDownProperties from the module system and need to rely on internals,
we *already* use internals for the mkOverride case, so adding another
case for mkIf doesn't add a hard-to-find indirection.

I'm merging this, since this fixes a valid use case and it shouldn't
make refactoring worse than before.
This commit is contained in:
aszlig 2021-02-13 05:24:04 +01:00
commit 2d5a31a3ef
No known key found for this signature in database
GPG key ID: 684089CE67EBB691

View file

@ -92,10 +92,12 @@ in rec {
checkUnitConfig = group: checks: attrs: let
# We're applied at the top-level type (attrsOf unitOption), so the actual
# unit options might contain attributes from mkOverride that we need to
# unit options might contain attributes from mkOverride and mkIf that we need to
# convert into single values before checking them.
defs = mapAttrs (const (v:
if v._type or "" == "override" then v.content else v
if v._type or "" == "override" then v.content
else if v._type or "" == "if" then v.content
else v
)) attrs;
errors = concatMap (c: c group defs) checks;
in if errors == [] then true