Hello, 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
signature.asc
Description: PGP signature
