Sam Hartman <hartm...@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 (r...@debian.org) <https://www.eyrie.org/~eagle/>
