Hi Michael,
On Thu, Jan 16, 2025 at 01:19:42PM +0100, Michael Biebl wrote:
> I also want to mention [0] here.
It is unfortunate that "implementation issues" lacks verifiable details.
> Do you consider [1] an RC bug, i.e. something that should/must be addressed
> one way or another for trixie?
Generally speaking that is not for me nor the CTTE to decide. However, I
see the current behavior as far from optimal and hope that we find a
solution in time for trixie. Laurent raised it to RC and you you also do
(as you state next). It would take a release manager to downgrade it.
> I personally do, and if you agree, this would mean option (D) is not a
> simple recommendation but you have to say that you would override my wish as
> maintainer of avahi-daemon to not ship such a config snippet. Afaics, this
> would then also mean a 3:1 majority.
I agree that (D) also requires a 3:1 majority. Thanks for clarifying.
> Otherwise option (D) would mean I'll most likely close [1] as wontfix, i.e.
> would leave this issue unresolved.
Let's not go down that path.
> I haven't seen any convincing arguments so far why the mDNS functionality in
> resolved must be turned on by default.
I hear that. Likewise Luca expressed that he remains unconvinced of your
view. Quite clearly, no answer is obviously right here.
In experimenting with the drop-in approach I noticed another downside
that wasn't as clear to me earlier.
Let's say resolved defaults to MulticastDNS=yes (as it does now) and
avahi adds a drop-in setting MulticastDNS=resolve. Consider an
administrator sets MulticastDNS=no in /etc/systemd/resolved.conf and
then installs avahi-daemon. Due to the order of how dropins are applied,
this causes MulticastDNS=resolve to become the effective value upon
installing avahi-daemon and this indeed is counter-intuitive.
If avahi-daemon were setting MulticastDNS=no, this could be surprising
the other way round. This is the way SteamOS disables it and it has
caused confusion among users (as is evident from a systemd issue
referenced earlier).
Luca, would you have an idea on how to reduce these negative
consequences of the drop-in approach that you suggested?
I now see a more nuanced set of outcomes:
(SN) The CTTE overrules the systemd maintainers and requests that
MulticastDNS defaults to no.
(SR) The CTTE overrules the systemd maintainers and requests that
MulticastDNS defaults to resolve.
(AN) The CTTE overrules the avahi maintainers and requests that
avahi-daemon installs a dropin setting MulticastDNS to no.
(AR) The CTTE overrules the avahi maintainers and requests that
avahi-daemon installs a dropin setting MulticastDNS to resolve.
(FD) Further discussion
All options but the last require a 3:1 majority.
Helmut
