Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
On Mon, 8 May 2023 at 16:48, Russ Allbery <rra@debian.org> wrote:
>
> I think your X-Debbugs-Cc was syntactically invalid and thus didn't work.
> I manually added in the other addresses in this reply.
Thanks - email is hard!
> Luca Boccassi <bluca@debian.org> writes:
>
> > It has come to my attention that there is one package in Debian using
> > dpkg-divert to mask a systemd configuration file (an udev rule).
> > Speaking as one of the maintainers, both upstream and downstream, I find
> > this greatly undesirable for several reasons that I will outline
> > later. Hence I would like to propose explicitly mentioning that
> > dpkg-divert must not be used for systemd configuration files (units,
> > rules, etc), and instead the supported workflow (drop-ins, masking, etc)
> > must be used, both by packages and administrators. This is already
> > standard practice, and again there is only one instance that needs
> > correcting as far as I understand, and I have already provided a bug and
> > a MR for that [1][2]. So the impact of this policy change should be
> > minimal, and it's mostly to ensure more such instances are accidentally
> > added in the future.
>
> > I have a draft policy update, that adds a paragraph to the dpkg-divert
> > section of the policy. It is attached here, and also available on Salsa
> > on my fork [3].
>
> The part of Policy that you edited with this patch is basically
> unmaintained and should ideally be removed in favor of actual Policy. (I
> had started looking at that a long time ago and then never finished.) All
> of those appendices from the old packaging manual predate better
> documentation maintained elsewhere (such as in the dpkg package) and are
> ambiguous with regards to whether they set requirements for Debian
> packages, document things for local administrators, or something else.
> The Policy manual warns that they may not be normative, and people often
> don't think to read them (for good reason).
>
> In the case of diversions, while I certainly agree with your proposed
> rule, I suspect Policy should say something stronger and more general,
> namely that no package in Debian should divert a file from another package
> unless this is arranged cooperatively between the packages to solve some
> specific (unusual) problem. To me, this feels similar to the case of one
> package modifying the configuration files of another package, where we
> explicitly prohibit one package modifying the configuration of another
> package except through an interface provided by the package whose
> configuration is being modified.
I'd like this to go a step further - rules, units and so on can (and
must!) be shipped by other packages, not just from src:systemd.
But as I mentioned in the other reply, bugs come to the systemd bug
tracker most often, and make our lives more difficult, even if it's a
third package that ships the configuration.
So, I'd very much want to make the rule stronger for this use case,
and forbid it even if the respective maintainers agree between
themselves that package A's unit should be diverted by package B's,
because ultimately both A and B are feeding configuration into
systemd/udev/etc, and this is just not a supported mechanism to apply
such changes.
> In other words, dpkg-divert is primarily for local administrators,
> non-Policy-compliant local packages that are doing unusual things, and the
> occasional rare problem that requires special coordination between
> packages, not something that Debian packages should be doing to other
> packages without explicit coordination.
>
> The rule about systemd and udev files doesn't entirely fall out of that
> statement, so we can still include a specific statement about them, noting
> that drop-ins and masking make dpkg-divert unnecessary (and those
> facilities produce better tool behavior) and therefore it should not be
> used.
>
> So, ideally, the way I'd prefer to move forward is for us to add a new
> section to the main Policy manual on diversions (probably 10.11), document
> that this is primarily a tool for local administrators and local packages
> to override the behavior of Debian, and that its use between Debian
> packages should be rare, should involve coordination between the packages,
> and should only be used to solve problems that cannot be handled through
> other facilities such as alternatives or package-specific tools like
> systemd's support for drop-ins and masking. And then explicitly call out
> systemd and udev configuration as cases where dpkg-divert should not be
> used, alongside conffiles and critical system files.
Ok, I can look at adding 10.11 - I very naively searched for existing
paragraphs mentioning diverts and found the one I extended, I did not
realize it was not proper part of Policy, thanks for the pointer.
Kind regards,
Luca Boccassi
Reply to: