Le 18/08/2022 à 16:59, Luca Boccassi a écrit :
No, custom and unsupported setups are unsupported. Compatibility is
provided for default environments, anything outside of it can and will
break at any given time, and it's not really feasible to do otherwise
given the uncountable amount of possible permutations. This time
there's a clear and unambiguos NEWS entry with a notification, which
doesn't even always happen.
What I meant is that I thought systemd-networkd (which partly relies on
systemd-resolved) was considered supported since it was shipped with
systemd and thus installed by default (unlike, for example, netplan),
albeit not enabled.
Should I understand that the only supported way to configure the network
in Debian is ifupdown with a plain /etc/resolv.conf file, and everything
outside of this scope is considered custom and thus, unsupported ? I'm
not being ironical here, it's a legitimate question.
Wrong, I always receive e-mails with news as well as changelogs during
upgrades, with the more recent examples being on July 13, 22 and 25. I
don't know why it didn't work this time, but I can hardly believe that
it's apt-listchanges' fault.
And yet it is, and it's been a known issue for quite some time:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977422
OK, you're right on this point, I didn't know that. Apologies. But it
also means that other sysadmins will be in the same case too when the
upgrade will take place (when bookworm is released, or when systemd
251.3-2 will be backported to bullseye) and will have their DNS
resolution temporarily broken after the upgrade.
But I guess you'll probably argue that it's their fault for using
systemd-resolved.
I think you don't understand my position: I don't care about resolvconf
or openresolv, I just want to use systemd-resolved (not the systemd
resolvconf interface, but the systemd-resolved service itself!) and
avoid breakage during upgrades for all users.
Look, I'm just trying to help here. You made a change, it has serious
consequences for systemd-resolved users, and I hinted them to you,
that's all. I think this is a bad change, but that's another matter.
Being obtuse and condescending won't help.
Name-calling won't help either.
Right, but at least admit that you're being a bit harsh to me since the
beginning of this thread, rejecting all my arguments and refusing to see
the problem here, basically saying that the resulting breakage is not
your fault and systemd-resolved users brought it on themselves by using
it because it's "unsupported".
Again, I don't care about resolvconf or openresolv, I care about
sysadmins who use systemd-networkd/resolved on their servers or
containers, and I'm just trying to avoid problems for them as well as
for myself in the future.
systemd brought a lot of controversy when it was adopted in Debian, and
I myself was amongst the people who were quite unhappy when it happened
(I still think that Jessie was too soon, it was not mature enough, but
that's another story).
Now that we started to familiarize with its different parts and all in
all find it very convenient that they're installed by default, you
slowly remove them one by one (systemd-machined, systemd-timesyncd,
systemd-boot, and now systemd-resolved... Which will be the next ?),
forcing us sysadmins to constantly update our automated installation
procedures (debian-installer hooks, ansible/puppet recipes, container
images, etc etc), and defeating the very purpose of systemd to be "a
suite of basic building blocks for a Linux system" that we finally embraced.
It's almost as if you want to discourage us to use the non-init-related
parts of systemd.
Regards,
--
Raphaël Halimi
