Bug#1091864: tech-ctte: Avahi and systemd-resolved cannot a run mDNS responder at the same time

[Sam Hartman]

>>>>> "Helmut" == Helmut Grohne <helmut at 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.