Bug#1103785: Consider not installing the symbolic link from resolvconf to resolvectl

[Ken Milmore]

Package: systemd-resolved
Version: 257.5-2
Severity: wishlist

I am raising this bug for further discussion following dhcpcd bug #1103719 [1] and upstream at [2], which relates to attempting to use dhcpcd together with systemd-resolved.

The dhcpcd-base package supplies hook scripts for configuring name server information from DHCP and possibly other sources. These scripts integrate with resolvconf, but do not seem to work properly with the limited resolvconf compatibility provided by resolvectl in the systemd-resolved package.

Since dhcpcd-base is now the default DHCP client for trixie, it seems likely that some users will try to use the two packages together. In particular, anyone who uses ifupdown to configure networking and also installs systemd-resolved is likely to encounter problems.

The possibility has been discussed of patching the dhcpcd hook scripts to play different when the systemd version of resolvconf has been detected (as opposed to the "usual" resolvconf provided by the resolvconf or openresolv packages).

A possibly neater solution, which may benefit several other packages, might be to allow systemd-resolved to coexist with resolvonf/openresolv. AFAICT, this would necessitate minor changes to the systemd-resolved package as follows:

- Do not install a symbolic link from /usr/sbin/resolvconf to /usr/bin/resolvectl.
(Optionally, the link might be placed at /usr/sbin/systemd-resolvconf which preserves the multi-call behaviour).

- Remove the "Provides: resolvconf" and "Conflicts: resolvconf" dependencies so that systemd-resolved can be installed alongside resolvconf/openresolv.

Changes would also be required to resolvconf/openresolv to add a subscriber script which invokes resolvectl to supply DHCP information whenever it detects that systemd-resolved is operating.

The hook scripts recently added to ifupdown [3] and isc-dhcp-client [4] might also benefit from simply deferring to resolvconf. So some coordination between package maintainers would be necessary.

The alternative to this approach is for each package which is involved in name server configuration (and does not use the resolved D-Bus interface directly) to maintain its own bespoke scripts for interfacing to systemd-resolved, or to fail to support it. This seems to be the odd consensus that has developed so far.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1103719
[2] https://github.com/NetworkConfiguration/dhcpcd/issues/500
[3] https://sources.debian.org/src/ifupdown/0.8.44/debian/if-up.d/resolved/
[4] https://sources.debian.org/src/isc-dhcp/4.4.3-P1-7/debian/resolved/