Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

Sean Whitton spwhitton at spwhitton.name
Tue Jun 6 11:37:51 BST 2023


On Sun 04 Jun 2023 at 02:56PM +01, 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
> (where the third one is equivalent to one of the first two, depending on
> how default-systemd-tmpfiles was implemented), possibly with some more
> less-preferred options between the first "|" and the virtual-package
> fallback.

As you wrote in another message, it's very cheap future-proofing to use
a virtual package for whichever actual solution we're implementing, so I
think we should do that.

> Another possible mitigation which I haven't previously seen proposed
> is giving *elogind* a Depends or Recommends on systemd-*-standalone.
> I think that would work to mitigate the failure mode with (1.) and (B.),
> and the installed-size argument seems less interesting here because the
> sort of systems that require elogind are already much larger anyway.
> Would the elogind maintainers be willing to consider this? Does anyone
> see a reason why it wouldn't work?

So to confirm, you think that if the elogind maintainers did this, then
default-systemd-tmpfiles could point at systemd rather than
systemd-standalone-tmpfiles, which the systemd maintainers prefer, but
in addition, there aren't any scenarios in which people's systems are
likely to be re-arranged when they don't want them to be?

> As a maintainer of system services, I would not be at all happy with
> expecting the maintainer of every system service that requires tmpfiles
> to have this conversation again and again. Obviously as a technical
> committee member and occasional Policy contributor, I've chosen to take
> on some of the burden of decisions like this one; but when I'm working
> on dbus or polkitd or even openarena-server, I should be able to follow
> a project decision, and be reasonably confident that I won't get angry
> RC bug reports about it (and if I do, I should be able to refer the bug
> reporter to a project decision instead of having to re-litigate it).
> Putting this sort of thing on individual package maintainers seems like
> a recipe for making it no longer fun to maintain a package.

Yes, let's figure out a standard solution and write it in Policy.
The reasoning may well be applicable to similar things in the future.

Sean Whitton
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 869 bytes
Desc: not available
URL: <http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/attachments/20230606/b76f4077/attachment-0001.sig>

More information about the Debian-init-diversity mailing list