Re: Finishing deprecation of isc-dhcp-client in ifupdown*
Hi,
On 10/22/25 4:13 AM, Daniel Gröber wrote:
tl;dr: ifupdown + dhcpcd-base in Trixie is broken in all but the most
defaultest configurations, consequently isc-dhcp-client deprecation is a
wash. It's a mess. Lets fix it.
Yay.
The biggest obstacle I see is actually making sure at least one of ISC
dhcp-client or dhcpcd is installed when using DHCP.
Would it make sense to make ifupdown prefer dhcpcd if both it and the
ISC client are installed, then make the ISC client package pull in
dhcpcd? This way, anyone currently using dhclient through ifupdown would
get dhcpcd installed, but people with a static configuration would not
need to install a DHCP client (the ifupdown package only Recommends a
DHCP client, so doing a proper transition is difficult).
Proposed ifupdown unstable upload:
https://salsa.debian.org/debian/ifupdown/-/merge_requests/28
I'll take a look this weekend.
After a comprehensive review of the situation I see the following problems
with ifupdown + dhcpcd-base:
- [Independent control] over IPv6 and IPv4 operation from ifupdown is
broken. A single `inet` stanza will enable both, so `inet6 static` also
does SLAAC/DHCPv6.
The default interface config has "accept_ra" enabled, so SLAAC is
enabled as soon as the link is up. If we "fix" that, it will be about as
controversial as systemd's decision to drop into an emergency shell if a
non-root filesystem fails to mount, when the sysvinit script failed to
pass the exit code along and just continued booting.
- Non-deterministic [daemon conflics] between ifup's dhcpcd instances and
dhcpcd.service may cause boot or renew problems.
Horrible idea: can we build a systemd generator that creates units to
resolve these conflicts?
As a reminder: starting with Trixie dhcpcd-base is now Priority:important
(#1038882) instead of isc-dhcp-client. AFACT this only affects new
installations, not upgrades so we've split the userbase.
The important change, I think, was changing the first preference in
ifupdown's Recommends field, but the effect is the same.
The dhcpd *package* additionally provides a system service that will start
dhcpcd in dual-stack global manager mode at boot. It will bring UP most
interfaces automatically with IPv4 DHCP, IPv4-LL and IPv6 SLAAC and/or
Stateful DHCPv6 as appropriate, but regardless of ifupdown configuration or
whether a per-iface instance is already running(!), see [daemon conflicts].
I think that is a bug in dhcpcd -- other tools make sure to ignore
interfaces configured through ifupdown.
As before, I fully expect a lot of installations to depend on this bug.
A dhcpcd patch could be suitable for Trixie even, but so far dhcpd's
maintainer has refused to consider downstream changes -- else I'd have
fixed this well before Trixie already :-]. Truth be told I'm pretty annoyed
I had to spend more than a full blown focused work week on designing,
implementing, documenting this hacky fix on the ifupdown side instead of
spinning a 10 LoC dhcpcd patch in half an hour, but here we are. Ugh.
FWIW, I think that kind of integration work is the job of a
distribution, so I'm totally fine shipping a patched package even if
upstream does not accept the patch.
We'd also need to define a conflict resolution policy for dhcpcd vs
systemd-networkd if we are touching dhcpcd.
My favourite policy would be
1. explicit configuration wins over autodetection
2. clear hierarchy for the rest, documented in Debian Policy
So, anyone autodetecting interfaces needs to consult either all the
other configuration files (which is bullshit, but doable), or we create
another interface between packages (e.g. /var/run/managed_interfaces)
and document it in Debian Policy. I would not feel confident deploying
the latter in a stable update, though.
Simon
Reply to: