Bug#1101532: systemd: unable to migrate to Testing because of removed packages

[Noah Meyerhans]

On Tue, Apr 01, 2025 at 08:24:37AM +0200, Helmut Grohne wrote:
> > In the interest of trying to contribute potential solutions, one
> > possibility that comes to mind is to use a generator to avoid
> > conflicting with avahi.  If the generator determines that avahi is
> > installed (I don't think it's possible to determine if it's actually
> > enabled at that phase), we can disable MDNS support with a drop-in
> > fragment in /run/systemd/resolved.conf.d/.  Have you considered such an
> > approach?
> 
> A solution to this end was considered during the discussion phase. There
> are various variants of it such as avahi-daemon installing the fragment.
> The gist is the same. Avahi should be the default implementation and
> resolved should only act as a mDNS resolver when avahi does not.

That makes sense.

> The option did not make it to the ballot that was voted on. The rough
> consensus reached was that having resolved disable its mDNS
> functionality on installing Avahi or enable mDNS on uninstalling Avahi
> would be more confusing to users than simply leaving mDNS disabled in
> resolved while letting users opt back in by changing the configuration
> file or dropping a fragment. The expectation is that few users would be
> depending on mDNS as implemented by resolved, because it additionally
> needs to be enabled per interface in networkd and no present component
> would perform such entablement in Debian. In other words, using the mDNS
> functionality already requires user changes. At that point we were back
> at simply changing the default state aligning Debian's defaults with
> Fedora and Ubuntu.

This also makes sense, and I can see how it's potentially confusing for
users to have systemd-resolved's behavior change depending on the
installation or removal of another package.  This does seem like
something that could be clearly explained in the release notes, though.
As you note, there are likely few users configuring mdns in
systemd-resolved today.  The people who are doing so are performing
specific actions to do so, and should be similarly able to resolve the
interaction with avahi in whatever way makes the most sense for their
use case.

> Do you actually see that behavior of having resolved automatically
> disable mDNS when Avahi gets installed as better? Few spoke up for that
> option during the discussion phase, so I'd be interested in reasons
> still. Maybe we moved too quickly there? In any case, a decision has
> been made. We may consider doing another decision if new information
> emerges, but time is running out and I am not seeing that new
> information just yet.

So, to be clear, I'll point out that I don't use mdns myself at all, so
I can't claim to speak for mdns users.  What I'm mostly concerned about
right now is avoiding the collateral damage that may follow the TCs
decision.

The TC decision of changing the systemd-resolved default mdns behavior
to "off" for trixie was rejected by the maintainer as it would
potentially break users upgrading from bookworm.  This is a legitimate
concern and we know that many users won't read the release notes, so
people would be surprised by it.

The TC seems to have disliked the precident set by the drop-in option
based on a precident that it sets, but I'm not sure I agree with the
concerns.  We already have the ability for one package to modify the
behavior of another, e.g. with dpkg-divert, which has existed
approximately forever.  There's an expectation that such behavior is
coordinated between the maintainers of the involved packages, just as
would be the case here.  So I don't think this would have set a
precident that hasn't already been established.

So, to answer your question, yes, I do think that automatically
disabling systemd-resolved's mdns support is likely a safer behavior
than flipping systemd-resolved's default.  This specifically concerns
the upgrade scenario.  However, as you note, the decision has already
been made, so it's too late to change any minds there.  I don't know
what to suggest to the TC at this point, but the current situation risks
leaving a fairly large subset of our users without a clear path forward.
I don't agree with Luca's decision to drop systemd-resolved altogether
in response to the TC's decision, but I do recognize that he's the one
who's going to be on the receiving end of the hate mail from user's when
their DNS breaks when upgrading from bookworm, so I'm somewhat
sympathetic to his position.

noah