Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
On Fri, 2019-11-22 at 09:05 -0800, Russ Allbery wrote:
> Simon McVittie <smcv@debian.org> writes:
> > 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.
As I said I'm interested in supporting environments with no init
installed and believe alternative init implementations happen to have
the same or similar needs here. For environments with no init, it
would be useful to split out the -tmpfiles and -sysuser programs into a
separate package as people using container images are always concerned
about image sizes.
I tried linking -tmpfiles and -sysusers against a static version of
libsystemd-shared which increased binary size a bit: -tmpfiles was 212
kB (up from current 84 kB), -sysusers 137 kB (up from current 51 kB).
But this should allow to safely split out the programs into a smaller
binary package.
> 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.
I would be surprised if upstream would break installing packages in
containers which often don't have systemd as pid-1 (as they have no
init at all). There also seems no reason for them to use facilities
provided by pid-1.
> 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).
We can make the guidance apply to only Linux and use other means on
non-Linux platform, just as we would for other Linux-specific parts
(any systemd .service files for example). Altenratively, non-Linux
ports could choose to use an alternative implementation (which
reportedly already exists outside Debian).
> 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.
I think no option says we shouldn't use services that don't rely on
systemd as pid-1 (which also includes widely used things like udev).
Ansgar
Reply to: