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

[Noah Meyerhans]

On Tue, Apr 01, 2025 at 08:59:44PM +0000, Luca Boccassi wrote:
> > > 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
> >
> > No, in fact most cloud environments don't support multicast networking
> > at all, so disabling it is entirely safe.
> >
> > > 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.
> >
> > That works for me.
> >
> > > 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?
> >
> > Well, we obviously would prefer to find a solution that doesn't involve
> > removing networkd altogether, should it come to that, but I'd hope we
> > don't get to that point.
> 
> LOL, he already escalated, not even had time to rinse the changes
> through the CI and he already got them to send a warning. Guess he had
> the complaint ready to send to DAM in the draft folder.
> 
> That answers the question of whether it's safe to add back resolved
> then - you mentioned you don't need the stub resolver, but just
> something to manage dhcp -> networkd -> resolve.conf, right? I think I
> can cook something up, I'll get on that next, who needs sleep anyway

Please let's not get ahead of ourselves.  I think Stefano was simply
pointing out something that had happned in the past, not any new DAM
involvement.

Keeping systemd-resolved in place is vastly preferable to any
cloud-specific workaround.  We used to have such a thing, before moving
to systemd-networkd/resolved, and are not excited about the prospect of
going back thered.

noah