Just to update y’awl on where we stand, we’re currently struggling with
BindsTo, trying to find a sane way to expose these. Our problem with the names systemd uses for them is that we find it impossible to remember which directive has which exact semantics, and don’t want to pass this same feature to the snapd world, if at all possible.
After are fine, and clear, and I think uncontroversial.
Conditions, yes we should expose all the relevant ones. Probably export it as a
conditions map inside an app, to keep it neat, and probably implemented using the
AssertFoo instead of the
ConditionFoo, so we have logs (let us know if there’s a reason not to do things this way).
Environment is already supported; we don’t think there’s value in additionally supporting
EnvironmentFile, unless there’s an actual use case for it where the file lives in the snap’s data directory and is modified? It sounds rather far-fetched, so let us know if this is the case. If you’re using it to read a file in the snap, snapcraft should be able to pack an environment file into environment stanzas (but this isn’t done yet). If you’re using it to read a file outside of the snap entirely, we wouldn’t want to support that (at least not without a pertinent interface, and that would need further design).
PropagatesReloadTo fit into the bigger conversation we’re having about
Requires and etc.
PartOf really useful on its own in practice, given that you can’t really define targets? Or would you also need targets for it to be useful? (I don’t think we want to allow targets – but on the other hand if a dev needs them they’ll end up simulating them with an app that does nothing, so maybe we do).