Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Sam Hartman <hartmans@debian.org> writes:
> 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.
I think (and please correct me, Luca, if I'm wrong) that Luca is trying to
declare, on behalf of the systemd maintainers, that this method of
disabling a systemd configuration file is unsupported and may not work.
To me that does warrant a Policy "should not" even if in specific
situations it works currently, because it implies that this approach is
fragile and may well stop working or cause bugs in the future with no
further notification (since that's essentially the definition of
unsupported).
Also, even apart from that, I personally would support a Policy "should
not" for using diversions in any case where another mechanism is available
that solves the same problem. Diversions are a low-level tool with a lot
of sharp edges and should be used very carefully and avoided when there is
some other approach available.
> 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.
I'm not really convinced by this the way that I would be if we were
talking about alternatives. With alternatives, the slave links mean that
managing a group of similar changes together is important, but dpkg-divert
has no equivalent and every diversion already has to be maintained
separately. Given that, I think the burden of asking people to use
masking instead of diversion for systemd configuration files is a fairly
minor request, so I weigh the problems on the systemd side higher than
what feels like a modest convenience.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: