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

[Stefano Rivera]

Hi Luca (2025.03.31_21:30:41_+0000)

Speaking for myself, as a technical committee member, I haven't run any 
of this by the rest of the committee.

>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.

For clarity, what you describe as being never acceptable is roughly what 
helmut's PR proposed: Flipping the default configuration from enabled 
to disabled. Not compiling it out. It could be re-enabled by 
configuration.

You were not required to compile it out.

The goal here is not to remove mDNS from systemd-resolved, but to 
disable it by default, as avahi is (currently) the default mDNS 
implementation in Debian (for trixie). This is expected to change in the 
future, as systemd-resolved matures. Avahi is an ageing codebase, and I'd 
imagine that systemd-resolved will probably replace it for most users in 
the future.

> 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.

It's hard to discuss alternatives after we've already concluded our 
discussion and voted. Engaging with the committee early helps us to make 
better decisions. We're here to work together, not to burn each other 
out.

But, again, for clarity: The escalation to DAM was for summarily 
reverting the NMU implementing the TC's decision, without leaving any 
indication that other implementations were being pursued.

>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.

There are other ways of approaching this, like release notes and NEWS 
entries. This feels like the more nuclear option...

>Finally, and I understand you can't possibly care, but the only things
>I am getting out of working on this are burnout and grief, a constant
>barrage. Getting hate from random anonymous trolls is one thing and
>pretty much comes with the job description of systemd maintainer, but
>for some reason pile-ons from fellow project members just hit
>differently. My problem, of course.

Hate from anonymous trolls is unacceptable.

I guess it's going to be an unavoidable part of the job description for 
the systemd maintainer. But that doesn't mean we're all against you. 
systemd solves real problems, and I personally appreciate it upstream, 
and the work that's gone into it in Debian. You've been doing great 
technical work.

But there's also a social side to this. You've run into conflicts with 
other package maintainers and decisions had to be made about how to 
solve technical issues. We're trying to help make systemd in Debian 
better for everyone. Please let us help.

Still hoping we can find a path through this.

Stefano

-- 
Stefano Rivera
   http://tumbleweed.org.za/
   +1 415 683 3272