Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
On Mon, 8 May 2023 at 18:31, Russ Allbery <rra@debian.org> wrote:
>
> 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.
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
Reply to: