On Tue, 13 Jun 2023 10:55:38 -0700 Russ Allbery <rra@debian.org> wrote: > > Init systems other than ``systemd`` should allow providing the same > > functionality as appropriate for each system, for example managing the > > directories from the init script shipped by the package. > > This sort of requirement is exactly what we should be getting rid of > by > using systemd-tmpfiles uniformly instead. We should be trying to > minimize > the extra work required to support non-systemd init systems in every > package if we want non-systemd init systems to remain viable, because > we > know that work largely won't happen. > > So, in other words, I haven't read the latest version of the patch > yet, > but if that wording is in there and I'm understanding the context > correctly, I think that's the opposite of what we should be saying > and we > should take it out in favor of saying everything should just invoke > systemd-tmpfiles or some equivalent implementation that uses the same > configuration. > > If other init systems arrange for systemd-tmpfiles to be run when > appropriate (at boot, mostly), then there is no need to provide > fallbacks > via, for instance, init scripts with different functionality than the > systemd units. This is the whole reason why we did the work to > package a > standalone systemd-tmpfiles package that can be used regardless of > the > init system. 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: > However, reading that documentation, it sounds like most of the cases for > other directories are handled by other systemd unit configuration > directives. We should say that explicitly here and reproduce the list of > other directories that should be handled directly by the unit file if > that's what we want people to do. 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. -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part