On Thu, 21 Jan 2016 17:54:21 +0100 Michael Biebl <bi...@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
