[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files



On Tue, 6 Jun 2023 at 11:58, Sean Whitton <spwhitton@spwhitton.name> wrote:
>
> 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.

My understanding is that "should" is effectively optional, ie: it is
not enough to make a package rc-buggy, and while they are generally
followed, there is no actual hard requirement to do so. That is not
enough for me and for this use case. So again my goal here is to make
an hypothetical future dpkg-divert or alternative of a unit file
(wherever it is shipped from) instantly and unambiguously rc-buggy,
with no leeway (again there are no longer any such cases in the
archive as of bookworm, so nothing is affected). If you can suggest an
alternative appropriate wording that can achieve the same effect, that
would be fine to me - I don't mind how it's written, as long as it
meets this requirement.

> > 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.

As above, as long as this wording makes any offending package
rc-buggy, it's fine by me, but my understanding is that using 'should'
doesn't guarantee that. Please correct me if I'm wrong here.

> I would also like to suggest "their own mechanisms for overriding parts
> of configuration" over "native overriding mechanisms" in the appendices.

Sure that sounds good.

Kind regards,
Luca Boccassi


Reply to: