Hi,as said, I wanted to add a few more remarks which hopefully make you better understand my reasoning why I think building systemd with "-Ddefault-mdns=no" is the right course of action for the time being.
avahi-daemon is currently installed on about 50% on all machines according to popcon. This is basically a result of task-desktop recommending it explicitly, cups recommending it and gnome having a hard dependency on it. So it's safe to say that on desktop installations and installations with printing support, avahi-daemon will be available. For a very long time, Avahi has been the only mDNS implementation available in Debian. The observation that the Avahi code base is old and showing signs of age is correct. After Lennart had lost interest in Avahi, Trent Lloyd had basically been its sole maintainer for many years. Thankfully, the situation has changed upstream and a new team has formed at [0] which actively handles issues and pull requests.
mDNS support in resolved is still relatively new and not complete: E.g. it misses the publishing parts and I'm not sure if systemd upstream has plans to implement this kind of functionality, i.e. it is unclear to me if and how it could supplant Avahi fully at this point.
Second, in [1], Luca argued that "resolved needs to work out of the box upon installation, and that includes mDNS".
I understand (and actually think it's a laudable goal), that Luca wants to have mDNS (resolve functionality) available for basically everyone. But:
a/ systemd-resolved is not installed by defaultb/ enabling mDNS functionality globally (i.e. having MulticastDNS=yes as default in /etc/systemd/resolved.conf) does not mean it will work out of the box. One has to enable it explicitly "per link" as well. If you are using networkd, you can achieve that by setting "MulticastDNS=yes" [1] (the default being no). NetworkManager has a similar switch, and ifupdown has no equivalent config option.
It is thus incorrect to say, that by building resolved with "-Ddefault-mdns=yes" it would work out of the box. It will always require explicit configuration anyway.
So I find Luca's argument very weak.Third, I also find the idea of one (unrelated) package silently disabling functionality of another package upon installation via the suggested drop-in snippet in [2] an anti pattern. I asked Simon, whose opinion I value greatly and who has been co-maintaining avahi [3]. He basically agreed and called it a "strange action at a distance". Taking this idea further, would you consider it a good idea, if say installing rsyslog would ship a config snippet disabling the journald functionality? I would not and would find this behaviour very unpredictable.
No other distribution I know of does it this way. Fedora and Ubuntu e.g. instead build systemd with "-Ddefault-mdns=no".
Fourth, limiting this decision to trixie only.In principal I agree that this decision should be time limited and not absolute. Assuming though, that the overall situation does not change significantly in forky, we will have this dispute all over again.
Wouldn't it be better to tie this decision to certain constraints?One such change could be that systemd-resolved is installed by default (a change that hopefully is decided Debian wide) or systemd-resolved gains feature parity with Avahi (most notably the publishing parts that are used by 3rd party software).
Or the maintenance status of Avahi changes in a bad way.In summary: Building systemd with "-Ddefault-mdns=no" will result in systemd-resolved shipping a /etc/systemd/resolved.conf containing "MulticastDNS=no".
This can be easily overridden by an explicit drop-in snippet, say /etc/systemd/resolved.conf.d/mdns.conf, containing "MulticastDNS=yes".
Explicit configuration is needed on a per-link basis anyway.This is a configuration which is consistent with other major distributions like Fedora or Ubuntu.
The CTTE decision should be (time) limited but not for trixie alone. It should take into account changes in resolved and Avahi. Regards, Michael [0] https://github.com/avahi/avahi [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077937#71[2] https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html#MulticastDNS=
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077937#46
OpenPGP_signature.asc
Description: OpenPGP digital signature
