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

[Sam Hartman <hartmans@debian.org>]

>>>>> "Luca" == Luca Boccassi <bluca@debian.org> writes:

    Luca> It has come to my attention that there is one package in
    Luca> Debian using dpkg-divert to mask a systemd configuration file
    Luca> (an udev rule).  Speaking as one of the maintainers, both
    Luca> upstream and downstream, I find this greatly undesirable for
    Luca> several reasons that I will outline later. Hence I would like
    Luca> to propose explicitly mentioning that dpkg- divert must not be
    Luca> used for systemd configuration files (units, rules, etc), and
    Luca> instead the supported workflow (drop-ins, masking, etc) must
    Luca> be used, both by packages and administrators.

First, I thought there was already a prohibition about one package
mucking with another package's configuration.
In many cases it sounds like it's already against policy for one package
to change the default systemd or udev configuration--at least for
packages in the archive.
(I am skepticle that amazon-ec2-utils complies with policy in general).


In cases where the change being made is permitted by policy, I think you
have made a compelling case to vastly prefer the native systemd and udev
mechanisms to dpkg-divert.
I don't think that your case is strong enough to forbid dpkg-divert.

As far as I can tell reading your reasoning, dpkg-divert *works fine*.
It just gives surprising results to someone coming from the systemd
universe.

But consider a package that diverts several resources, several of them
systemd and several of them not systemd.
The maintainer might legitimately want to use the same mechanism for all
the overriding/masking  so that systemd resources and non-systemd
resources were handled the same.

There's a real trade off there, and we generally leave those to
maintainers.

So, I'd support policy advice (ENCOURAGED) rather than policy
requirements (MUST) in this case.

I do think that if a maintainer violates this advice without a good
reason, important is a more appropriate bug severity than wishlist, but
unfortunately we don't have a good way to specify that in policy
language.

I would not support policy recommendation language (RECOMMENDED/SHOULD)
because that has a connotation that failing to follow the recommendation
is always a bug, and I don't think that's true here.

--Sam