Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
On Sun, Jun 04, 2023 at 02:56:59PM +0100, Simon McVittie wrote:
> I think one way or another, if anyone is going to set a package-level
> dependency on systemd-tmpfiles, the first (preferred) dependency needs to
> be on either a concrete provider (systemd or systemd-tmpfiles-standalone
> in this case), or a default-systemd-tmpfiles virtual package
> that only has one provider per architecture (which is the way
> {default-,}dbus-{system,session}-bus are handled). Otherwise, you
> can get a non-deterministic choice of default implementation, which
> seems strictly worse than either depending on systemd or depending on
> systemd-tmpfiles-standalone - if you're unlucky, it can have all the
> disadvantages of either one of those.
Thank you for the elaborate writeup. There is little to add to what you
write except for one minor aspect.
> - actual result: apt's heuristic might have difficulty realising that
> it needs to do that
I think we should be able to guide apt here. I recently had to look into
Replaces and in that process I also had to re-read policy section 7.6.2.
It details the "other" use of Replaces to guide a package manager (e.g.
apt) for changing implementations of an interface - which is exactly
what we are talking about here. In essence, it says that we should do:
Provides: systemd-tmpfiles
Conflicts: systemd-tmpfiles
Replaces: systemd-tmpfiles
And systemd-standalone-tmpfiles does that. :) But systemd does not. :(
systemd misses out on Conflicts and Replaces. I guess (but have not
verified) that once these are added, apt would be happier to "upgrade"
systemd-standalone-tmpfiles to systemd when needed.
I've also experimented with a minimal chroot, installed the standalone
tools and the asked apt to install libbiometric0 (which happens to have
a dependency on systemd) and apt was quite happy with removing the
standalone variants. This is still missing the consumers of the provided
facilities though, so it might not be representative.
Is there any concrete evidence of apt having difficulties in a real
situation? Or maybe a constructed example demonstrating this? Thanks for
being cautious, but I'd also like to understand whether this is
hypothetical or real.
Helmut
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
On Mon, 5 Jun 2023 09:53:39 +0100 Simon McVittie wrote: > On Mon, 05 Jun 2023 at 01:36:25 +0100, Luca Boccassi wrote: > > If it is useful, adding a "default-tmpfiles" or so virtual package > > would be fine by me - but with the kfreebsd port being retired soon, > > and i386 (for hurd) going the way of the dodo, I'm not sure it would > > be very useful? I don't think it would be a problem to add it, if it > > turns out to be of use though. > > What this would look like, in src:systemd: > > Package: systemd > Provides: default-systemd-tmpfiles, systemd-tmpfiles > > Package: systemd-standalone-tmpfiles > Provides: systemd-tmpfiles > > (or maybe the other way round, depending what conclusion we come to on > the choice between (1.) and (2.)), and then in dependent packages: > > Package: foo-service > Depends: default-systemd-tmpfiles | systemd-tmpfiles > > The benefits of that over having foo-service depend directly on > "systemd | systemd-tmpfiles" or > "systemd-standalone-tmpfiles | systemd-tmpfiles" are fairly minor, but the > cost is also fairly minor; and if we want this, we should set it up > *before* lots of packages start adding a dependency on the -tmpfiles or > -sysusers interfaces. The benefits I see are: > > - if we find out that the dependency we first added is a practical problem > for whatever reason, we can swap the default with a src:systemd upload, > without needing multiple maintainers to touch all the dependent packages; > > - if we get a useful non-Linux port (admittedly this looks increasingly > unlikely) which cannot compile src:systemd, then their reimplementation > of these interfaces can have Provides: default-systemd-tmpfiles on that > architecture, without affecting Linux architectures > (the same way dbus-x11 Provides default-dbus-session-bus on non- Linux > ports, even though it's dbus-user-session that Provides the virtual > package on Linux) Sure, that sounds reasonable and simple enough to do, no objection from me. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
On Mon, 5 Jun 2023 10:11:46 +0100 Simon McVittie wrote: > On Mon, 05 Jun 2023 at 01:36:25 +0100, Luca Boccassi wrote: > > Our time is worth more than 80K or whatever it is of disk space in a > > throw-away container. > > I agree that the systemd maintainers' time is a limited resource that we > should not waste, but that size estimate is off by a couple of orders of > magnitude. On amd64, aptitude tells me systemd-standalone-tmpfiles and > -sysusers are about 700K of Uncompressed Size between them, while the > full systemd and libsystemd-shared packages add up to about 15M. For > genuinely throwaway containers, yes, it's not worth optimizing this, > but for containers that will be archived in a registry and/or kept > running longer-term, that seems like enough that maintainers of Docker > containers, etc. will want to use the standalone binaries if they are > sufficient for the container's needs. > > (This is ignoring any extra library dependencies that might be required by > systemd and libsystemd-shared but unnecessary for the standalone binaries; > if there are any, then obviously the effective size delta increases.) Sure, but again, those special cases that really care about that particular angle can simply adjust their dependencies accordingly, there's nothing stopping them from doing so. It does not need to be the default. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
On Mon, 05 Jun 2023 at 01:36:25 +0100, Luca Boccassi wrote: > On Sun, 4 Jun 2023 at 14:56, Simon McVittie wrote: > > So I think the only realistic options for packages that hard-require > > this functionality (not all do) are: > > > > 1. Depends: systemd | systemd-tmpfiles > > 2. Depends: systemd-tmpfiles-standalone | systemd-tmpfiles > > 3. Depends: default-systemd-tmpfiles | systemd-tmpfiles In case it's not obvious, (2.) should say systemd-standalone-tmpfiles | systemd-tmpfiles (and the same everywhere else that I mentioned systemd-tmpfiles-standalone). > Our time is worth more than 80K or whatever it is of disk space in a > throw-away container. I agree that the systemd maintainers' time is a limited resource that we should not waste, but that size estimate is off by a couple of orders of magnitude. On amd64, aptitude tells me systemd-standalone-tmpfiles and -sysusers are about 700K of Uncompressed Size between them, while the full systemd and libsystemd-shared packages add up to about 15M. For genuinely throwaway containers, yes, it's not worth optimizing this, but for containers that will be archived in a registry and/or kept running longer-term, that seems like enough that maintainers of Docker containers, etc. will want to use the standalone binaries if they are sufficient for the container's needs. (This is ignoring any extra library dependencies that might be required by systemd and libsystemd-shared but unnecessary for the standalone binaries; if there are any, then obviously the effective size delta increases.) smcv
Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
On Mon, 05 Jun 2023 at 01:36:25 +0100, Luca Boccassi wrote: > If it is useful, adding a "default-tmpfiles" or so virtual package > would be fine by me - but with the kfreebsd port being retired soon, > and i386 (for hurd) going the way of the dodo, I'm not sure it would > be very useful? I don't think it would be a problem to add it, if it > turns out to be of use though. What this would look like, in src:systemd: Package: systemd Provides: default-systemd-tmpfiles, systemd-tmpfiles Package: systemd-standalone-tmpfiles Provides: systemd-tmpfiles (or maybe the other way round, depending what conclusion we come to on the choice between (1.) and (2.)), and then in dependent packages: Package: foo-service Depends: default-systemd-tmpfiles | systemd-tmpfiles The benefits of that over having foo-service depend directly on "systemd | systemd-tmpfiles" or "systemd-standalone-tmpfiles | systemd-tmpfiles" are fairly minor, but the cost is also fairly minor; and if we want this, we should set it up *before* lots of packages start adding a dependency on the -tmpfiles or -sysusers interfaces. The benefits I see are: - if we find out that the dependency we first added is a practical problem for whatever reason, we can swap the default with a src:systemd upload, without needing multiple maintainers to touch all the dependent packages; - if we get a useful non-Linux port (admittedly this looks increasingly unlikely) which cannot compile src:systemd, then their reimplementation of these interfaces can have Provides: default-systemd-tmpfiles on that architecture, without affecting Linux architectures (the same way dbus-x11 Provides default-dbus-session-bus on non-Linux ports, even though it's dbus-user-session that Provides the virtual package on Linux) smcv
