Hello,
On Mon 05 Jun 2023 at 12:59AM +01, Luca Boccassi wrote:
> On Sun, 4 Jun 2023 19:39:49 +0200 Bill Allombert <ballombe@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
Attachment:
signature.asc
Description: PGP signature