Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files
Bill Allombert <ballombe@debian.org> writes:
> On Tue, Jun 06, 2023 at 07:56:14PM -0700, Russ Allbery wrote:
>> I prefer that too, but in this case, it feels like must is appropriate
>> for at least systemd configuration files. And also, just intuitively,
>> I feel like must is correct when people are using diversions rather
>> than a native mechanism. Diversions add weird edge cases and we really
>> shouldn't be using them lightly.
>> The wording I proposed and that Luca has now adopted therefore uses
>> must with a caveat. Does that sound okay to you?
> I do not think appropriate for the policy to list systemd or any other
> packages specifically in this section.
My rationale for listing systemd specifically is:
1. This is a common case where one package wants to change the behavior of
another and I expect it to become increasingly common as people make
more use of systemd security features. For example, I would expect
cases where the default systemd configuration for a service disallows
access to large swaths of the file system, and then installing a plugin
for that package grants additional access to specific paths used by
that plugin.
2. We understand what people are trying to do in this case and can offer
very specific guidance, whereas we can't in general for arbitrary
packages. This makes Policy more useful for packagers; instead of
seeing a general rule that they can't use diversions but being left on
their own to figure out how to solve their problem, Policy can
explicitly say "here are the mechanisms to use for this case, they can
do everything you would want to do with diversions."
I would like to add more documentation like this around systemd-related
things to Policy because systemd is complicated and has a lot of options,
so people who aren't deeply familiar with it will easily miss best
practices in its reams of very good but overwhelming documentation, and
Debian should be opinionated about steering people towards best practices
for our primary init system, just as we were very opinionated about how to
write init scripts for sysvinit.
> If a package set up a diversion that breaks another, then it is buggy,
> whatever policy say. If the diversion does not cause any breakage, there
> is no purpose for policy to declare it a RC bug.
I don't really agree with this, and I thought we had reached some
agreement in the other branch of this thread that this isn't quite
complete and it's okay to ban diversions if there's a better mechanism
available.
I think that if diversions and some other mechanism work equally well
technically, we should forbid using diversions and require using the other
mechanism. This is in part based on the long threads that came out of the
/usr-merge discussions, which made clear that diversions are a very
complicated feature with a lot of edge cases, and it's possible to get
into trouble with them because they're manipulating the packaging system
at a very low level. If there's some alternative that's less invasive, I
do feel like using diversions is a fairly serious bug because it adds to
the instability of the system.
In isolation, you could talk me into it being an important bug rather than
an RC bug, but that feels like a lot of nuance here and must feels cleaner
and more straightforward.
That being said, I'd rather back down to should than remove the
systemd-specific details, since I think the latter are quite valuable.
> In general, policy proscription are only useful when the description of
> a better mechanism is provided. But there is no place for that in this
> section.
I'm not sure I understand this statement, since describing a better
mechanism is exactly the point of that language about systemd. We link
directly to those better mechanisms (masking, drop-ins, and, for
alternatives, aliases).
I definitely agree that Policy should have a whole section devoted to
systemd and its configuration files, but I don't want to try to boil the
ocean in one bug. But yes, we should be working towards that, IMO.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: