Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
On Mon, 8 May 2023 at 16:39, Sam Hartman <hartmans@debian.org> wrote:
>
> >>>>> "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.
The problem is that when there are udev/systemd bugs they get directed
to the systemd team, not to the package shipping a divert, because
diverts are essentially invisible to normal users. It is already very
difficult and very time consuming to support these packages,
especially udev because we are essentially dealing with the
intersection of an infinite combination of hardware and software, and
anything that makes our lives harder is detrimental to the project at
large. If there was a significant, or even any benefit at all, then it
could be discussed, but I fail to see any. I do not find the
theoretical point about multiple diversions very compelling - we use
different mechanisms for different things all the time, but more
importantly such a case simply has never surfaced in the 10 past years
or so since we ship systemd by default, and longer since we ship udev.
Moreover, as upstream developer, I can guarantee you that masking via
diversion like this is NOT supported, and there could be more bugs
lurking, and we categorically do not intend to support or help with
such cases. I have no intention to spend any time investigating
whether such bugs exist and document them. Therefore, given there is
only one case in the whole distro so impact is minimal, the best
option to me seems to flat out forbid it, so that we never get into
that bad situation in the first place.
Kind regards,
Luca Boccassi
Reply to: