Bill Allombert <ballo...@debian.org> writes: > On Tue, Jun 06, 2023 at 07:56:14PM -0700, Russ Allbery wrote:
>> I prefer that too, but in this case, it feels like must is appropriate >> for at least systemd configuration files. And also, just intuitively, >> I feel like must is correct when people are using diversions rather >> than a native mechanism. Diversions add weird edge cases and we really >> shouldn't be using them lightly. >> The wording I proposed and that Luca has now adopted therefore uses >> must with a caveat. Does that sound okay to you? > I do not think appropriate for the policy to list systemd or any other > packages specifically in this section. My rationale for listing systemd specifically is: 1. This is a common case where one package wants to change the behavior of another and I expect it to become increasingly common as people make more use of systemd security features. For example, I would expect cases where the default systemd configuration for a service disallows access to large swaths of the file system, and then installing a plugin for that package grants additional access to specific paths used by that plugin. 2. We understand what people are trying to do in this case and can offer very specific guidance, whereas we can't in general for arbitrary packages. This makes Policy more useful for packagers; instead of seeing a general rule that they can't use diversions but being left on their own to figure out how to solve their problem, Policy can explicitly say "here are the mechanisms to use for this case, they can do everything you would want to do with diversions." I would like to add more documentation like this around systemd-related things to Policy because systemd is complicated and has a lot of options, so people who aren't deeply familiar with it will easily miss best practices in its reams of very good but overwhelming documentation, and Debian should be opinionated about steering people towards best practices for our primary init system, just as we were very opinionated about how to write init scripts for sysvinit. > If a package set up a diversion that breaks another, then it is buggy, > whatever policy say. If the diversion does not cause any breakage, there > is no purpose for policy to declare it a RC bug. I don't really agree with this, and I thought we had reached some agreement in the other branch of this thread that this isn't quite complete and it's okay to ban diversions if there's a better mechanism available. I think that if diversions and some other mechanism work equally well technically, we should forbid using diversions and require using the other mechanism. This is in part based on the long threads that came out of the /usr-merge discussions, which made clear that diversions are a very complicated feature with a lot of edge cases, and it's possible to get into trouble with them because they're manipulating the packaging system at a very low level. If there's some alternative that's less invasive, I do feel like using diversions is a fairly serious bug because it adds to the instability of the system. In isolation, you could talk me into it being an important bug rather than an RC bug, but that feels like a lot of nuance here and must feels cleaner and more straightforward. That being said, I'd rather back down to should than remove the systemd-specific details, since I think the latter are quite valuable. > In general, policy proscription are only useful when the description of > a better mechanism is provided. But there is no place for that in this > section. I'm not sure I understand this statement, since describing a better mechanism is exactly the point of that language about systemd. We link directly to those better mechanisms (masking, drop-ins, and, for alternatives, aliases). I definitely agree that Policy should have a whole section devoted to systemd and its configuration files, but I don't want to try to boil the ocean in one bug. But yes, we should be working towards that, IMO. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
