On Tue, 16 Aug 2022 19:35:27 +0100 Simon McVittie wrote: > I don't think this is as simple as either of > the two obvious opposing viewpoints: > > - this dependency is always OK, take no action > - this dependency is always wrong, revert the feature completely [...] > If it wasn't for its dependency implications, I would be saying that > we should be making *more* use of tmpfiles.d and similar declarative > mechanisms over time: a declarative syntax for the transient files that > we want to create and/or clean up seems like a win. tmpfiles.d fragments > also seem like a useful way to associate transient files with the package > that "owns" them, analogous to %ghost files in RPM. So I would like to > avoid issues like this one making maintainers reluctant to use tmpfiles > in situations where they're non-critical.
There are other alternatives than you mentioned: It was suggested to avoid such dependencies on package-level and instead have init systems depend on it as part of the required "runtime services" for using service management. This would mean no package- level dependencies on systemd-tmpfiles. If you don't use an init system (e.g. containers), you are on your own (but systemd-tmpfiles and regular service management would often not run in such cases either anyway). This is similar to providing system startup scripts: we don't add dependencies on init systems for these either (with some exceptions where Adam Borowski pushed maintainers to add explicit dependencies on systemd-sysv, making use of init-less systems harder). There are some questions about how to express one requires a recent enough sysvinit-core (with such a dependency); "Breaks" isn't really great and "Depends" is what we want to avoid after all... This however wasn't wanted by current sysvinit-core maintainers, so we get to keep the package-level dependencies for now. This is a bit similar to: > It might also be useful to have a third mode that is equivalent to what > happened before 13.8: assume that tmpfiles.d snippets are desirable on > systemd-booted systems, but either unnecessary or actively harmful on > non-systemd-booted systems. But no longer specific to systemd. Ansgar
