>>>>> "Luca" == Luca Boccassi <bl...@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
