Le 17/08/2022 à 00:36, Luca Boccassi a écrit :
Personally I see this as a regression, since resolved used to be part of
systemd and thus readily available without installing additional packages.
No support was provided before for resolved, it was completely inhert,
hence it is not a regression. It is a change in behaviour, and thus
noted in the NEWS file as expected.
Yes, but this goal could be achieved by letting resolved in the main
systemd package, and splitting only systemd-resolvconf in its own package.
Having a single-file-package that is confusing and harder to find is
not something we want to do, unless there are extremely compelling
reasons for it. Supporting resolvconf is not one.
Could you at least address the temporary break in DNS resolution ? This
is still a serious bug, which would deserve its own bug with priority
grave (if not critical). Since systemd-resolved is mainly used on
servers, it could result in a very bad surprise for sysadmins when
bookworm is released.
Perhaps it could be fixed by promoting systemd-resolved to a recommends
(instead of suggests) in systemd, so that it's installed during the
upgrade ? Or don't stop the service if /etc/resolv.conf is symlinked to
/run/systemd/resolve/stub-resolv.conf, so that the admin has the time to
read the NEWS entry (which, again, didn't work on my system, whereas it
was supposed to be sent in an e-mail by apt-listchanges), and install
systemd-resolved before rebooting ?
Also, I understand that you don't wish to revert your changes, but is
there a reason why resolvconf, openresolv and thus systemd-resolved
could coexist thanks to the alternatives system ? I know it would be
more work for maintainers of those three packages, but IMHO it would be
worth the effort.
And, last but not the least, I see that /etc/resolv.conf is now part of
systemd-resolved files, which means that it would be deleted when the
systemd-resolved package is removed from the system. I think it would
also deserve its own bug with some high priority.
Regards,
--
Raphaël Halimi
