Hi Sam and others, thanks for shifting the perspective.
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. I'm not sure how such policy would help resolve the conflict. Given reverse dependencies of popular packages, avahi-daemon is the de-facto default implementation, but does that preclude resolved from performing resolving in the absence of avahi-daemon (as requested by Luca)? Other packages have two main mechanisms to interact with mDNS implementations. They may resolve (works with either in principle) and they may publish (each has their own format and location here). We cannot reasonably ask either to adopt the other's format. Would you have an idea of what kind of policy could be enacted and how it would help resolve the conflict? > For what it's worth, as someone who is not involved in the TC, I > definitely think our users would be best solved by resolving things so > that a default desktop installation of Debian has avahi-daemon as a > working mdns resolver without systemd-resolved getting in the way. If you install a desktop environment, it will presently install avahi-daemon. task-desktop Recommends libnss-mdns which in turn Recommends avahi-daemon. From what I have read, we all (including Luca) agree that this is what we want. That "without systemd-resolved getting in the way" part is more subtle. We saw that Fedora opted for disabling resolution in resolved and not just publishing as originally intended. A kind soul (thanks) pointed me at the reason for that. If resolved is acting as a resolver, it is presently listed first and does not return to other resolvers, so avahi won't get a pass if resolved has resolution enabled. https://bugzilla.redhat.com/show_bug.cgi?id=1867830 As a result, I am now convinced that the problem is not just that having resolved and avahi do concurrent publishing is a problem, but also having both enabled as resolvers is a problem. I expect others to agree given the evidence and think this rules out options where resolved defaults to resolving only or where avahi-daemon disables only the publishing functionality in resolved. Practically this reduces our choice to "resolved has mDNS disabled by default" vs "avahi-daemon disables mDNS in resolved". Given that it was mentioned often enough, having a resolution reaffirm that avahi-daemon should be the default in either case seems fine to me. As such I now see the following possible ballot options: (S) The CTTE reaffirms that avahi-daemon is the default mDNS implementation in Debian trixie. Therefore systemd-resolved should disable the mDNS functionality in its default installation in Debian trixie. (Requires a 3:1 majority overruling a developer.) (A) The CTTE reaffirms that avahi-daemon is the default mDNS implementation in Debian trixie. This does not preclude other resolvers such as systemd-resolved operating when avahi-daemon is not installed. To achieve this, avahi-daemon should disable systemd-resolved using a resolved configuration file. (Requires a 3:1 majority overruling a developer.) (F) Further discussion The main changes here are reaffirming the default implementation and discarding the options where resolution is enabled in both implementations on the grounds that resolved would be preferred where avahi-daemon should be preferred. In principle, we could also reconfigure nsswitch.conf to prefer avahi-daemon over resolved. I am not putting this up as an option yet as there is no proposal nor patch for this. Does anyone see nuances of the matter that have not yet been explored? My impression is that whilst Luca opted for not participating he expressed relatable reasons earlier and Michael clarified his reasons during the discussion. Helmut
