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