Bug#812215: consider spliting systemd-tmpfiles into separate package

[Josh Triplett]

On Thu, 21 Jan 2016 17:54:21 +0100 Michael Biebl <biebl at debian.org> wrote:
> Hi Ondřej
> 
> Am 21.01.2016 um 17:28 schrieb Ondřej Surý:
> 
> > please consider spliting systemd-tmpfiles into separate package,
> > perhaps with sysvrc script provided.
> > 
> > The tmpfiles mechanism is quite great and if we can use tmpfiles
> > mechanism in the sysvrc scripts, we could remove a lot of custom shell
> > scripts that do just the same - create a temporary directory in /run
> > (and elsewhere).
> > 
> > Personally I have a shell snippet that can understand most basic stuff
> > in /usr/lib/tmpfiles.d/<package>.conf, but there's a lots of
> > duplication since /run started being tmpfs that gets deleted on every
> > machine reboot.
> > 
> > Also since this utility probably doesn't need anything from the
> > kernel, it might be compilable on non-Linux archs :) (worth trying).
> > 
> 
> We already considered this a while ago. It's not easily possible.
> systemd-tmpfiles links against the internal libshared which basically
> means building half of systemd. This is unlikely to succeed on
> non-linux. Last time I tried it, I've given up on it without success.
> 
> A systemd-tmpfiles compatible implementation outside of the systemd
> sources looks to me like a more maintainable solution. And once we have
> that, splitting out systemd-tmpfiles only on Linux doesn't make sense
> anymore, I guess.
> 
> I agree though, and I think the rest of the team as well, that having
> the systemd-tmpfiles mechanism on non-systemd would be worthwile.

I'd agree that systemd-tmpfiles won't build outside of systemd or on
non-Linux; beyond the systemd libraries, it would need portability
changes around things like selinux, devices, ACLs, and xattrs, and
couldn't support subvolumes at all.

However, since installing the "systemd" package doesn't change the init
system, and systemd-tmpfiles should run without systemd as init, I do
think it might make sense to add a new source and package "tmpfiles",
that Depends on "systemd [linux-any]" (but not on systemd-sysv) and
ships a sysvinit script to run systemd-tmpfiles on sysvinit.  The
tmpfiles package should ship a corresponding .service symlink linked to
/dev/null, since systemd already runs systemd-tmpfiles.  Then, packages
could depend on "tmpfiles" and count on tmpfiles.d support across
multiple init systems, to avoid the need for duplicate logic in their
sysvinit scripts.  (I'd suggest depending on "tmpfiles | systemd-sysv",
except that you can have systemd-sysv installed but boot with sysvinit
as init, and avoiding the installation of one unused script and one
symlink doesn't seem worth breaking that case.)

That same "tmpfiles" package could also potentially provide a subset of
the functionality of systemd-tmpfiles on non-Linux platforms, and
software that supported non-Linux kernels could restrict itself to that
subset and depend on the tmpfiles package.

This would need some coordination among init systems and projects
shipping tmpfiles.d snippets, since some packages (notably systemd
itself) may not expect their tmpfiles.d snippets to run under
non-systemd.  Several existing sysvinit scripts could make use of this;
for instance, right now the rcS script bootmisc.sh creates nologin, but
/usr/lib/tmpfiles.d/systemd-nologin.conf seems like a much simpler way
to do that.

If having tmpfiles.d support across all architectures and init systems
sounds appealing, I'd be willing to construct such a package, though I'd
want to have co-maintainers who actually run sysvinit and/or non-Linux
architectures.  The subset of tmpfiles.d syntax that can easily work on
all POSIX systems seems simple enough to write.

- Josh Triplett