Your message dated Fri, 21 Nov 2025 18:56:22 +0000
with message-id <[email protected]>
and subject line Bug#1121101: fixed in network-manager 1.54.2-2
has caused the Debian Bug report #1121101,
regarding debian/rules unsuccessfully attempts to disable support for using
dhcpcd
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1121101: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1121101
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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>
signature.asc
Description: This is a digitally signed message part
smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---
--- Begin Message ---
Source: network-manager
Source-Version: 1.54.2-2
Done: Michael Biebl <[email protected]>
We believe that the bug you reported is fixed in the latest version of
network-manager, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Michael Biebl <[email protected]> (supplier of updated network-manager package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Fri, 21 Nov 2025 18:31:01 +0100
Source: network-manager
Architecture: source
Version: 1.54.2-2
Distribution: unstable
Urgency: medium
Maintainer: Utopia Maintenance Team
<[email protected]>
Changed-By: Michael Biebl <[email protected]>
Closes: 1121101
Changes:
network-manager (1.54.2-2) unstable; urgency=medium
.
* Fix dhcpcd build option.
The intended build option "false" did not actually disable it as
expected, so use "no" instead.
Thanks to John Scott (Closes: #1121101)
Checksums-Sha1:
a5d558197cd29e90daaa54b68c262fde84e7727d 3275 network-manager_1.54.2-2.dsc
1ad8b068bc863288a6b8c23b9841d55f27d90d5b 58612
network-manager_1.54.2-2.debian.tar.xz
90d3d931a5d4ffe35760450c1a699a1e2709dec9 11671
network-manager_1.54.2-2_source.buildinfo
Checksums-Sha256:
aeabbb41dd01881e7b241af62b1a4bc3fcc01c98db23ff51aa8ebd2f5a6b956e 3275
network-manager_1.54.2-2.dsc
3e2d4355203dcea85906348a3b03d79c9225865bdafc6f85edc317edb9a4d3e7 58612
network-manager_1.54.2-2.debian.tar.xz
0bc69deb796d3fc59d20fd21e22207ef1679d660f9aeb3d7a2105b72c3b16add 11671
network-manager_1.54.2-2_source.buildinfo
Files:
4e7beae470407985fb5945b5e9d9080e 3275 net optional network-manager_1.54.2-2.dsc
164952df7c40517af6c893e300c24f52 58612 net optional
network-manager_1.54.2-2.debian.tar.xz
31503a6b78e7e247552b204f87cfa63e 11671 net optional
network-manager_1.54.2-2_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEECbOsLssWnJBDRcxUauHfDWCPItwFAmkgog0ACgkQauHfDWCP
ItwAPw//Seke+EVFBmWqfbvO5jb+i6Nu8iGVxQEmM7Rql4AaqOcsQn837DhjzJyG
chVD8mHix7hAooSzZylSkePIuhkc0x+7BGpXO89rzqviN+Pm6TClWYCaMIsX7vwc
lZz0KNLWIPbl2AU5/hV2UwswsvfENpWCVUSWqwHkD4FaAVPc/F4kd7nqhVRhdIj/
8pcruPQXJ3ub6qoTfxOYU72UVBtV/y04WjVufPsr6Ejqr6cTtqf6SpunV+5h5ME5
IdaUI3C2BOgl1leWF0aRNvbYbo34YPly186RO9WpXIl+1BB+0Hq5YkrNxVsW+VbG
BT8FTw3BOL7saDFGB60u77ufeL5dTz6vXmNHr2HIE1ER8OCG0sheUY+c0uWT2iAZ
0XxVPT4Ijyvj/utp1mIRp4/NEUVJnoYIlKFQfVjrQYIlQh77ILzxs+1BflzEAMBq
N6tzPYZ6kq7e6xKIi+0sZO6tbblwzqJEZBS5LPUailOAO5EHel1GfcYk+QZyx8re
PkNj1KgZl3N3yGGZ8LpsXa+gbPeZKT2sufpY03+YQGRkMxOYrSs2FUe5zVioJr8w
dw5TUSQ5AGsKNiCN0H26OayrR7x8TrgJgIsZiv/3fIX3UKb1hfnmBesWx/75ybDM
z0qvRZmIDppq51PK1r54MYiwNi3HNDQr+2kPRwoqmyaP79pfnks=
=6Ac/
-----END PGP SIGNATURE-----
pgpuqCypBRLMB.pgp
Description: PGP signature
--- End Message ---
