>>>>> "Helmut" == Helmut Grohne <hel...@subdivi.de> writes:
Helmut> Hi Sam and others, thanks for shifting the perspective.
Helmut> On Thu, Jan 16, 2025 at 09:49:41AM -0700, Sam Hartman wrote:
>> It also seems like the TC has the option of providing policy
>> here, for example policy on what the default MDNS implementation
>> is in Debian or policy on how services can interact that gives
>> guidance on the interaction between packages like avahi-daemon
>> and systemd-resolved.
Helmut> I'm not sure how such policy would help resolve the
Helmut> conflict. Given reverse dependencies of popular packages,
Helmut> avahi-daemon is the de-facto default implementation, but
Helmut> does that preclude resolved from performing resolving in the
Helmut> absence of avahi-daemon (as requested by Luca)?
Helmut> Would you have an idea of what kind of policy could be
Helmut> enacted and how it would help resolve the conflict?
"Debian's policy on mdns implementations:
The default mdns implementation for Debian trixie is avahi-daemon. Other
packages must not provide an mdns resolver or publisher in their
default configuration."
I think that's probably a bad policy, but it seems fairly clear that if
Debian through the TC were to adopt such a policy it's clear that
systemd would be responsible for turning off mdns either at compile time
or through the default config files.
Assuming we thought that disabling systemd-resolved's MDNS support was
the right answer even if avahi-daemon is not installed, we could come up
with something better worded than what I propose above.
If we think it is reasonable for systemd-resolved to provide MDNS
resolution when avahi-daemon is not installed, we could write a policy
that said avahi-daemon is our preferred implementation. Then we could
talk about how other implementations figure out whether they are the
most preferred implementation on the system and what their behavior
should be if they determine that they are not the most preferred
implementation on the system. (I'm imagining such a policy might push
the systemd maintainers toward a generator that generated runtime config
to turn off MDNS when avahi-daemon is installed, although I think you
could also write policy that pushed toward avahi-daemon generating a
drop-in.
I don't think thinking about this in terms of policy magically solves
anything on the technical level. I think it might be a superior way to
phrase things at a political level:
* The TC could be ruling on things like what our default
implementation is and on how packages handling the same interface
should interact. These matters truly do cross package boundaries and
if you phrase things that way it becomes obvious that the TC is
resolving a cross-package issue rather than stepping on a maintainer's
toes.
* You can phrase things in such a way that we (and our users) get a
decision even if the TC cannot come to a super majority. The TC would
need to at least come to a majority decision, but that may be easier.
* Things are not phrased in terms of overriding maintainers. Even that
can have some value depending on the personalities.
