Simon McVittie <s...@debian.org> writes: > On Fri, 22 Nov 2019 at 14:05:50 +0100, Ansgar wrote:
>> I'm fairly sure that systemd-tmpfiles doesn't require systemd as pid-1 > It doesn't, but its dh_installsystemd integration currently does, so > maintainer scripts relying on it would currently be buggy. I think it > would be premature to recommend systemd-tmpfiles in Policy before it can > be used in a non-buggy way. > I had also thought that, in the current state of non-systemd-init-world, > having a dependency on a package containing systemd-tmpfiles was likely > to be practically problematic because it would indirectly conflict > with elogind, via libsystemd0 and its elogind reimplementation - but > looking more closely, systemd-tmpfiles and systemd-sysusers depend on > /lib/systemd/libsystemd-shared-243.so (and not on libsystemd0) so that > shouldn't actually be a problem. There's also the problem that while systemd-tmpfiles doesn't currently depend on systemd as PID 1, I'm dubious upstream is willing to make any guarantees that this will continue to be the case. It's also not clear whether the project would be comfortable with us adopting new Policy guidance that inherently breaks the non-Linux ports (since I believe the systemd package does not build there). Let's hold off on this until the GR. The GR won't be too far into the future, and will provide a very clear path forward for proposals like this. Thank you very much for starting to work on it, though, and I'd be very happy to see specific proposed language in this bug that we can consider once the GR makes it clear how the project wants us to proceed with facilities like this. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
