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

[Luca Boccassi]

Control: merge -1 1101762

On Fri, 28 Mar 2025 18:35:41 -0400 =?UTF-8?Q?Jeremy_B=C3=ADcha?=
<jeremy.bicha at canonical.com> wrote:
> Source: systemd
> Version: 257.4-5
> Severity: serious
> X-Debbugs-CC: debian-release at lists.debian.org
> 
> systemd is unable to migrate to Testing because it abruptly dropped
> these packages:
> - libnss-resolve
> - systemd-resolved
> 
> which are dependencies of debian-cloud-images and openvpn-systemd-
resolved.
> See https://qa.debian.org/excuses.php?package=systemd

The second one only exists for resolved, so: #1101536

The first one is news to me, I wasn't aware of it, I thought it just
used networkd. Seems strange that one subset of images deviates wildly
from distro's defaults...

It's been stated that resolved is a 'key package' due to that. But I
thought those were defined by RT, and yet it doesn't show up:

$ wget https://udd.debian.org/cgi-bin/key_packages.yaml.cgi -q -O- | grep resolved
$

Paul, could you please confirm whether resolved is a key package and
thus cannot be removed anymore, or isn't and can? Thanks.

> It is also used by netplan.io's autopkgests. The systemd upload
> triggered the failure of that autopkgtest which is also blocking
> migration to Testing.

As far as I know netplan.io works fine with pretty much anything, and
it's just some of the tests that have that particular setup, but they
should work without it too:

https://salsa.debian.org/debian/netplan.io/-/merge_requests/17

> Please try to find a less disruptive way to handle the resolved
situation.

I am really sorry for the disruption, but unfortunately when features
need to be dropped, there's bound to be some of that. Let's keep in
mind though, that we are talking about an optional 2% popcon package.

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.

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.

Besides, the generic feedback from random Debian users seems to be
largely positive, joyous even:

https://fosstodon.org/@daltux@snac.daltux.net/114241049303960781
https://fosstodon.org/@dwardoric@chaos.social/114241412595005926
https://fosstodon.org/@eugenio@snac.eutampieri.eu/114241396099978535
https://fosstodon.org/@nafmo@vivaldi.net/114242626006732520
https://fosstodon.org/@asl@mastodon.launay.org/114245405068810570
https://fosstodon.org/@TheGingerDog/114245701525734541
https://fosstodon.org/@ttyS1@bsd.network/114242208525201480
https://fosstodon.org/@ParadeGrotesque@mastodon.sdf.org/114242559527495102

So, just one simple question: why the **** should I even bother
anymore?