On Wed, 7 Jun 2023 12:23:15 +0200 Bill Allombert <ballombe@debian.org> wrote: > On Tue, Jun 06, 2023 at 07:56:14PM -0700, 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. 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. There are already mentions of systemd and unit files in policy before this change, in other sections. For what reason are those fine and this is not? > 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. Earlier you wrote: > Policy is for promoting interoperability and documenting current practices. This is what this change is doing - promoting interoperability by forbidding known broken and unsupported practices, and instead steering toward known working and supported practices. It also documents what the current practice w.r.t. overriding and aliasing is as of Bookworm. > 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. It is explained how to use a better mechanism? With links to all the relevant documentation et cetera. Are you saying it's not exhaustive enough and you want more details added? I am wary of excessively redefining and duplicating existing documentation, especially because it will naturally evolve (in backward-compatible ways) and any such copy would get out of date and be confusing. -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part