Mark Hindley <m...@hindley.org.uk> writes: > I remain much less convinced that there is a consensus for requiring > packages to use tmpfiles.d(5) for /var, /tmp and maybe /etc.
Well, for /tmp, /var/tmp, and /run, I think this is the right approach, unless there is some other systemd unit configuration that is even better. This is also already what we're doing across the archive, which is a pretty strong indication of consensus. The alternative for /tmp, /var/tmp, and /run is to add manual mkdirs to systemd units or init scripts (that normally then have to be run as root, even when the daemon doesn't), and that's clearly inferior and a poor technical approach. Given that, if we want to keep everything working with non-systemd init systems, they're pretty much going to have to invoke systemd-tmpfiles during boot or things are going to start breaking just because they're not tested (or some equivalent; there was some discussion of adding support for the tmpfiles.d format directly to dpkg so that dpkg is also aware of what package owns these files). I am considerably more dubious about /var and /etc in general. I don't think there's a consensus for managing files or directories there with systemd-tmpfiles, and most packages just ship the directories in the package. I understand that this is part of the overall goal of making Linux distributions only ship files in /usr, but the project as a whole has not signed on to that goal yet. However, what's being proposed here is something much narrower: we should not be managing directories in those paths *with mkdir in maintainer scripts*, and instead should use systemd-tmpfiles in that specific case. For those rare cases where packages are manually creating directories in shell instead of shipping them in the package for whatever reason, switching to systemd-tmpfiles feels like an obviously correct improvement as long as the maintainer script arranges for systemd-tmpfiles to be invoked so that it will create the directories. It allows us to move something from imperative maintainer scripts that are very hard to analyze to declarative files that have well-understood semantics and handle all the edge cases that human-written maintainer scripts tend not to manage. This change should also be invisible to other init systems since the files and directories are still being created by the maintainer scripts as always, just using a different program. However, the really compelling use of systemd-tmpfiles is for /tmp, /run, and /var/tmp, replacing all the various hacks and workarounds we have had for decades to create those files during boot, at least in the cases where the functionality isn't handled directly by a systemd unit. It's that behavior that I think deserves a should. For the persistent directory case in /var and /etc, I think "encouraged" (Policy advice) is more appropriate at this point, since creating the directories in maintainer scripts is not *broken*, and we should not be making those packages instantly buggy. > The recent thread on debian-devel demonstrated a range of > opinion. Thorsten and Bill have just raised valid points about chroots. I don't understand the point about chroots. It seemed to be based on a fundmental misunderstanding of how systemd-tmpfiles works? Thorsten seemed to think it was a daemon; it's not. It's essentially a fancy version of mkdir + chmod + chown plus some other things that supports a declarative syntax for specifying what directories should exist. A good analogy for a different type of operation would be start-stop-daemon (except systemd-tmpfiles supports declarative configuration, which is even better). > Reading the proposed text as somebody who is particularly interested in > non-systemd systems, I am struck by the inconsistency between > 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. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
