On Mon, 8 May 2023 at 18:31, Russ Allbery <r...@debian.org> wrote: > > 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.
Yes, that is precisely what I meant. I have applied your suggestions and added a 10.10 chapter that has a generic 'should' rule, and a more strict 'must' rule for systemd files. I am pushing to the same branch, if you prefer me to attach directly to the mail too let me know and I can do that, otherwise the branch is on Salsa: https://salsa.debian.org/bluca/policy/-/tree/systemd_overrides I kept the wording for the dpkg-divert appendix too, because people are bound to find it when googling, so as long as it's there I think it should mention this too. Once it gets removed/reworked it can go. On request from Marco, the kmod maintainer, I've also added the same constraint for modprobe.d/ files, for exactly the same reason, as kmod supports overrides, drop-ins and so on. I've kept it as a separate commit on top of the other changes, given I am not involved with kmod directly. Kind regards, Luca Boccassi
