Package: systemd-resolved
Version: 257.4-9
Severity: wishlist
X-Debbugs-Cc: josh@joshtriplett.org

(Please note, this is a wishlist request, and low priority. It is not
meant to make additional work, and can wait until the current situation
calms down. Thank you for all your maintenance work.)

Since systemd-resolved -9 uses configuration to disable the mDNS
functionality by default (satisfying the requirement that the "default installation" of systemd-resolved have mDNS disabled), would you
consider providing a *non-default* package systemd-resolved-mdns that
contains only a configuration snippet turning it back on (numbered to
come after the one in the base package turning it off)?

That way, users whose configurations do want to use mDNS with
systemd-resolved could depend on `systemd-resolved-mdns` and have it
Just Work.


-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.12.20-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd-resolved depends on:
ii dbus [default-dbus-system-bus] 1.16.2-2
ii libc6 2.41-6
ii libssl3t64 3.4.1-1
ii libsystemd-shared 257.4-7
ii systemd 257.4-7

Versions of packages systemd-resolved recommends:
ii libidn2-0 2.3.8-2
pn libnss-myhostname <none>
pn libnss-resolve <none>

Versions of packages systemd-resolved suggests:
ii polkitd 126-2

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Josh,

On Wed, Apr 02, 2025 at 11:52:23AM -0700, Josh Triplett wrote:

That way, users whose configurations do want to use mDNS with systemd-resolved could depend on `systemd-resolved-mdns` and have it
Just Work.

That's an interesting idea. On the CTTE side, it was discussed whether systemd-resolved could Conflicts: avahi-daemon and that was ruled out
rather early. I do not see how this would carry over to
systemd-resolved-mdns though. There, that conflict would really make
sense rather than breaking use cases.

Or it could go one step further still and we could have both
avahi-daemon and systemd-resolved-mdns declare Provides and Conflicts
for a virtual mdns-resolver package for others to depend on.

The CTTE questioned whether avahi-daemon would be the default resolver
in the long run, so this approach would also enable a way to eventually transition the functionality in a smooth way.

I agree that this is all not urgent and we may defer it after trixie.
Yet, it is an interesting way to think about the problem. Thank you.
This is all my own views without a CTTE hat.

Helmut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)