Simon McVittie <s...@debian.org> writes: > The key piece of information that was missing from your previous > proposal was that systemd-tmpfiles interface versions match upstream > systemd version numbers. As a concrete example, if someone wants to > upload an implementation other than the one from systemd, it cannot have
> Provides: systemd-tmpfiles (= 254) > until it has at least a basic implementation of the new "X", "C+" and > "--graceful" features introduced in systemd 254. Yeah, I had missed that, thank you. I think that's now captured. > If the package benefits from running tmpfiles.d but does not strictly > require it (for example dbus-daemon, where /run/dbus/containers is > needed for some optional functionality), would a Recommends or Suggests > be allowed by this wording, or are we intending for this to be a > mandatory hard dependency? I'm not sure it's going to make a lot of difference in practice, since I think it will be hard to end up with a system that doesn't have a systemd-tmpfiles implementation installed, but I agree that in theory this is too strong. I'll try to come up with a rewording that allows for the possibility of Recommends or Suggests. Maybe just a parenthetical that says or Recommends or Suggests if this more accurately fits the nature of the dependency? I think apart from this and resolving whether to add empty directories into the deb, the remaining issue before we can merge this is to make sure that the sysvinit maintainers are okay with adding the requirement that the init system invoke a systemd-tmpfiles implementation periodically. As I would expect, the systemd-standalone-tmpfiles package only provides the binary, not any init system integration. Does anyone know if that integration has already been done to invoke systemd-tmpfiles during boot on systems using sysvinit? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
