[Pkg-utopia-maintainers] Bug#1121101: debian/rules unsuccessfully attempts to disable support for using dhcpcd

[John Scott]

Source: network-manager
Version: 1.52.1-1
Severity: normal
Tags: upstream

This issue is a cascade of a couple mistakes. For context, I'm planning on tinkering with my home network and advanced IPv6 features. In anticipation that Network Manager's in-house DHCP client wouldn't be up to the task, and instead preferring that DHCP functions be handed off to a dedicated helper, I took a look at NetworkManager.conf(5). There one finds
dhcp
	This key sets up what DHCP client NetworkManager will use. Allowed values depend on build configuration; this version of NetworkManager was built with support for the following clients: internal, dhcpcd.

As recent discussion on debian-devel hints, ISC's dhclient is on its way out (disabled in Debian at https://salsa.debian.org/utopia-team/network-manager/-/commit/bbd537d4ffdb795581fdd9efeb4fbec4bb420cc3 last year) and dhcpcd is a sort of successor in this function. Setting 'dns=dhcpcd' in NetworkManager.conf has sometimes been hit-or-miss for me, and now I know why. The Debian package does indeed have support for dhcpcd enabled (despite trying to disable it in debian/rules, more on that in a moment). However, there is no Depends/Recommends/Suggests relationship to keep the dhcpcd-base package installed.
Note the split between the dhcpcd binary package, which comes with its own startup scripts, and dhcpcd-base, which is designed to be run on-the-fly by a helper like Network Manager. Thus as a user, marking the dhcpcd-base package as manually installed really is the wrong thing to do as it's not intended to have any function unless a higher-level tool like Network Manager invokes it. If I were to cease using Network Manager, the package would stick around despite not being intended to be useful on its own. Thus it's more like a library, and the network-manager binary package should at least have a Suggests: relationship on dhcpcd in this case.

While researching why there is no package relationship, I discovered that dhcpcd support is technically supposed to be getting disabled at build time anyway, so it's by a series of coincidences that it's getting built in anyway. In all uploads since the switch to Meson one finds the following in debian/rules:
override_dh_auto_configure:
	dh_auto_configure -- \
		… \
		-Ddhcpcd=false

This prompted me to ask "Is this really necessary? Why would we in Debian want to disable dhcpcd support at build time and make it completely impossible for a user to switch on at runtime? Can't we just stick with upstream's defaults?" It is a fortunate feature for me personally that this is getting left on anyway, and I'll describe how. Normally Meson has a notion of options and features that allows them to take on default values: thus you should only have to include parameters in debian/rules that are about tailoring the software to Debian's aims, and can stick to an upstream project's judgment about what features to enable if that is wanted. It is unfortunate that this capability isn't being used. If one looks at upstream's meson_options.txt one finds:
# dhcp clients
option('dhclient', type: 'string', value: 'no', description: 'Enable dhclient support (deprecated)')
option('dhcpcd', type: 'string', value: '', description: 'Enable dhcpcd support')

This makes no sense: these are clearly intended to be boolean options, but instead of using Meson's boolean option type here it wants a string answer. For boolean options Meson expects 'true' or 'false'. (Note that Meson has its very own option type for features at https://mesonbuild.com/Build-options.html#features which can take 'enabled', 'disabled', or 'auto', and as explained there this has special benefits for packagers. Use of that should be preferred.) This string-handling code expects answers of 'yes' or 'no', as 'no' is set for dhclient. For dhcpcd it's simply an empty string, and it's not obvious what the intention is supposed to be. In debian/rules we override this with 'false'. Due to the use of incorrect type this intention doesn't get picked up on, as meson.build has:
foreach client : [ 'dhcpcd', 'dhclient' ]
	client_path = get_option(client)
	client_enable = (client_path != 'no')
	if client_enable
		…

As a string comparison, 'false' compares not equal to the word 'no', and so it gets interpreted as a 'yes'! And then the value of the client_path variable, which is intended (here) to be an actual filesystem path to the binary and not a boolean, is the word 'false'. And that's why in the build log after the Meson run you get this very silly message:
DHCP clients (default internal):
	dhcpcd: true false
	dhclient: false (deprecated)

In my view a plan for handling this issue is as follows:
 • Network Manager upstream should fix errors in their Meson port by using correct types and taking advantage of the facilities it provides.
 • Network Manager should expose build-time features using Meson's standard facilities and set reasonable defaults that ought to be adequate for any general-purpose distribution.
 • debian/rules can then remove redundant parameters and evaluate what should be built or not.

In the absence of a reason not to, I expect upstream will consider build-time support for dhcpcd to be a reasonable default. (In particular Network Manager's internal client can still be used as the runtime default.) At that point, the network-manager binary package should add an explicit Suggests: on dhcpcd and explicitly enable it as a backend in debian/rules, for the sake of interface stability for users.
If, for whatever reason, it is intentional that the dhcpcd backend be disabled at build-time in the Debian package, then the minority of users who've been using it should get a warning. This can be done in a Debconf-ish preinst script or the like that does e.g. '/usr/sbin/NetworkManager --print-config | grep -F dhcpcd' and defers a package upgrade.

There does not appear to be any upstream issue or work about the Meson problems or discussion about what reasonable defaults are, and I'd appreciate if someone with better perspective on Network Manager maintenance can take care of that.

Thanks

-- System Information:
Debian Release: 13.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.12.57+deb13-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages network-manager is related to:
pn  isc-dhcp-client  <none>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-utopia-maintainers/attachments/20251120/3c6b0d06/attachment.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6270 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-utopia-maintainers/attachments/20251120/3c6b0d06/attachment.p7s>