Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Russ Allbery]

Mark Hindley <mark at 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 (rra at debian.org)              <https://www.eyrie.org/~eagle/>