Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
On Mon, 8 May 2023 at 20:00, Sean Whitton <spwhitton@spwhitton.name> wrote:
>
> Hello,
>
> On Mon 08 May 2023 at 08:48AM -07, Russ Allbery wrote:
>
> > 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,
>
> Hmm, could you explain why?
>
> > 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.
>
> I don't mean to dismiss the significant impact on the systemd
> maintainers that's being claimed, but specifically calling out udev and
> systemd configuration files seems strangely specific, for Policy, to me.
>
> The general prohibition seems justified, and then I would be inclined to
> use the systemd and udev configuration files case as an example, which
> explains and justifies the existence of the rule. So instead of
>
> [don't use dpkg-divert on other packages's files] In particular,
> packages should not divert systemd and udev configuration files.
> Doing so leads to confusing command output.
>
> it seems more natural to me to do something like
>
> [don't use dpkg-divert on other packages's files] For example,
> diverting another package's systemd units or udev configuration
> files can result in confusing command output.
>
> If this was a mistake that maintainers seemed to habitually make, the
> former would make sense, but so far I think we have just one or a few
> concrete examples, and so the correct thing to do seems to me to be to
> add normative language for only the general case.
Hi,
The specific difference, for which I think an explicit call out is
needed, is because these config files are shipped by some packages but
are not used _by_ them, they are consumed by systemd (or udev, or
kmod, etc). Specifically, if package A ships a.service, and package B
overrides it, even if the maintainers of A and B agree, that's still
not good enough for me, as they are really affecting systemd, which is
the consumer and the provider of the interface they are using, and
ultimately the first port of call for bug reports. This is especially
true for udev.
So in my latest revision of the patch, the general rule is as
requested by Russ and as you mention it, but there is an explicit,
stricter rule to cover this case, which is important to me. Policy
calls out core component software in many places, such as dpkg, and
systemd is already mentioned in other parts of the policy, so it did
not seem too far-fetched to me.
I am of course open to re-wording, adjustments, etc as deemed necessary.
Changeset at: https://salsa.debian.org/bluca/policy/-/tree/systemd_overrides
Kind regards,
Luca Boccassi
Reply to: