Hello, On Mon 05 Jun 2023 at 12:59AM +01, Luca Boccassi wrote:
> On Sun, 4 Jun 2023 19:39:49 +0200 Bill Allombert <ballo...@debian.org> > wrote: >> On Sun, Jun 04, 2023 at 12:25:54PM +0100, Luca Boccassi wrote: >> > If you prefer, I can reword the general rule to be stricter, ie: >> > "packages must not use diversions where native mechanisms are >> > available" or so. Would this be better? >> >> "native mechanisms" seems to vague. > > Well, I originally had written precisely what I meant, but was told on > this thread to "add normative language for only the general case" > instead, so I've done that. That's always going to sound vague. I > cannot do both at the same time. > > As you can see from the latest revision, right now the rule is general > but it's immediately followed by a very concrete and documented > example. Open to precise suggestions on how to improve it. 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. Maintainers do take our "should"s seriously -- let's use that here. It can always be strengthened later. > Diversions and alternatives should be used primarily as a tool for > local administrators and local packages to override the behaviour of > Debian. Its use between Debian packages should be rare, should involve > coordination between the packages and their maintainers, and must only > be used to solve problems that cannot be handled through other > facilities or native mechanisms. In other words, packages in Debian > must not divert a file from another package unless this is arranged > cooperatively between the packages to solve some specific and unusual > problem. How about: Diversions and alternatives are primarily tools for local administrators and local packages to override Debian's default behaviour. Maintainers should prefer to use other, package-specific facilities for overriding configuration, such as systemd's unit file overrides, wherever possible. If diversions and alternatives are to be used, maintainers should co-ordinate with the maintainers of all the packages involved. For example, configuration files used by systemd components should not be diverted with dpkg-divert or the alternatives system without agreement between not only the maintainers of the packages that ship the files, but also the maintainers of the relevant systemd components. I would also like to suggest "their own mechanisms for overriding parts of configuration" over "native overriding mechanisms" in the appendices. -- Sean Whitton
signature.asc
Description: PGP signature