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
