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

[Luca Boccassi]

On Mon, 31 Mar 2025 19:31:10 -0400 Noah Meyerhans <noahm at debian.org>
wrote:
> On Mon, Mar 31, 2025 at 10:30:41PM +0100, Luca Boccassi wrote:
> > There are several issues. First and most importantly, the TC wants
half
> > of resolved (mdns) gone, but there seems to be some
misunderstanding
> > going around that it can just be compiled out, but that's not true,
at
> > most you can flip a boolean entry in a config file. They will never
> > accept something like that. I already tried to propose some
> > alternatives that are less disruptive but with much stronger
guarantees
> > that ensure avahi always wins, and their answer was escalating to
DAM.
> > 
> > Secondly, even if there was a way to just carve out half of it,
that
> > still leaves every single host relying on it for reachability dead
in
> > the water on a simple in-place upgrade, requiring physical access
to
> > fix. At least if the package is completely removed, chances it gets
> > noticed in time are _much_ higher, as you need to dist-upgrade, and
> > acknowledge that it gets removed - autoupdaters largely will refuse
to
> > do so automatically. So the choice is, drop it and get shit for it
now,
> > or leave it nerfed and get shit for it later. Lovely.
> 
> These are legitimately nontrivial problems to solve.  But from a
> practical point of view, unless some bespoke user process is managing
> resolv.conf, systemd-resolved is the best solution to DNS client
> management when systemd-networkd is operating as the DHCP client. 
This
> is why we use it in the cloud images.
> 
> Ripping out systemd-resolved entirely leaves gap in functionality
that
> is not filled by available alternatives.  I'd very much prefer to
work
> constructively toward a solution that addresses the TC's requirements
> without giving up on providing systemd-resolved altogether.  I'm sure
> such a thing exists.
> 
> 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?

Thanks for the suggestion. On the specifics, a generator can generate
units, but not config files - ie, it has access to
/run/systemd/generator* but not where a config file would be looked at.

More generically, if you haven't seen on the MR, I had proposed several
alternatives to the submitter that are much safer and clearer, such as
a package conflict. The MR submitter's answer to the _mere suggestion_
was escalating to DAM.

Do the cloud images use avahi at all? Assuming I'm looking at the right
manifest:

https://cdimage.debian.org/images/cloud/trixie/daily/20250324-2061/debian-13-generic-amd64-daily-20250324-2061.json

it seems not, so how about this: I'll take a personal risk and we can
try once more with the pkg conflict. I'll reinstate the package, with
an added "Conflicts: avahi-daemon" so that users have to choose one or
the other, and avahi is the default so it always wins unless someone
has very specific and customized use cases like yours.

If everything goes fine, then all good. If instead the TC escalates
again to DAM, then I'll remove the package again, and work to find an
alternative that you can use with networkd in the cloud images, and try
and find time to implement it.

How does this sound?