Luca Boccassi <bl...@debian.org> writes: > That paragraph is in the context of StateDirectory= and > RuntimeDirectory=. These are unit files options, so it's up to > alternative init systems to provide alternative and integrate them in > the (eventual) init script, just as they are defined in the systemd > unit. I've mentioned those explicitly as you indicated earlier in this > thread:
Ah! Sorry, I did inded not understand the context correctly, and should have just not replied until I had a chance to read the context. That's my fault. I agree with this statement with respect to systemd unit features. This is a consequences of the fact that units are the preferred daemon configuration and package maintainers are allowed to use its features (GR 2019-002). We should be encouraging them to use those features correctly and documenting how to do so, but that necessarily means that init scripts for use with other init systems will need to provide a version of the same feature in some other way. We have had several GRs on this topic, and Policy does need to follow the outcome of those GRs unless someone overturns them with another GR. That being said: > Again, the rationale is: when there is a strong ownership model tied to > an individual service those are best as the lifecycle and permissions > are handled, when there is no owner or no specific owner or particular > metadata requirements then tmpfiles.d are best. I still am curious if it's safe to configure the same files in both tmpfiles.d and in the unit file, because it would make it much easier for those who want to support other init systems to do so. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
