Hello,
On Tue 06 Jun 2023 at 07:56PM -07, Russ Allbery wrote:
> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> I think what's a bit peculiar here is using "must" for a case where
>> there might be package-specific exceptions. In other cases, Policy uses
>> "should" for these cases. Typically "must" rules are simple and
>> completely determinate.
>
> I prefer that too, but in this case, it feels like must is appropriate
> for at least systemd configuration files.
I've spent some time thinking about this, and I now agree that we should
add a "must" for systemd unit files, and the other classes of systemd
configuration mentioned in the patch.
> 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 still find myself feeling queasy about adding this must-with-caveat.
It feels like with the caveat you're trying to get something between
"must" and "should", but then rather than build down from "must", why
not build up from "should"? I would like to propose:
Maintainers should strongly prefer using other overriding
mechanisms, instead of diversions, whenever those other mechanisms
are sufficient to accomplish the same goal. In other words,
diversions in packages should be considered a last resort.
I think that this accomplishes everything, in terms of guidance for our
maintainers, that the must-with-caveat wording does. But it avoids
saying that using diversions over a native mechanism in and of itself
renders a package RC-buggy, which doesn't seem right to me.
My own experience with diversions is limited, and so I accept that I may
well be naively underestimating the badness of the edge cases.
--
Sean Whitton
Attachment:
signature.asc
Description: PGP signature