Please unblock package dhcpcd

[ Reason ]
As someone found out during the soft freeze, a daemonized dhcpcd competes with network-manager and other network configuration tools for control over the network interfaces and resolver.

Back when I took over maintenance of the package, I ended up spliting the init.d script and systemd unit into a separate bin:dhcpcd package precisely to avoid this. Apparently, that wasn't enough. I therefore just added a "Conflicts: network-manager" to bin:dhcpcd to further drive the point that having two networking daemons on the same host is a bad idea. This is the only change.

Meanwhile, bin:dhcpcd-base remains perfectly harmless on hosts running systemd-networkd or network-manager, since it doesn't come with startup scripts and is instead executed via ifupdown or some other network configuration framework as per administrator configuration.

[ Impact ]
Without this fix, bug reports similar to #1107683 are likely to be filed after Trixie is released.

[ Tests ]
None needed. It's only a dependency change (Conflicts: network-manager).

[ Risks ]
No code change.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock dhcpcd/1:10.1.0-12

[network-manager maintainer speaking here]

Am 14.06.25 um 06:52 schrieb Martin-Éric Racine:

In the past, network management systems did not declare conflicts
against each other.

If what you say is true, and dhcpcd interferes with networkd,
NetworkManager, ifupdown and its variants, why was only a Conflicts
against the network-manager added?

This feels like a very ad-hoc workaround.

su 15.6.2025 klo 18.26 Michael Biebl (biebl@debian.org) kirjoitti:

Indeed, but it if even an experienced Debian developer ended up filing
a bug wondering why 2 network configuration daemons compete for the
same interfaces, it strongly indicates a need for idiot-proofing
dependencies.

Because, as the bug report that caused this change showed,  it's the
most obvious case. Ideally, I'd also have a Conflicts against
networkd, but it's not a separate package, and it needs to be
explicitly enabled, so we'll manage fine.

Please also note that the dhcpcd binary itself doesn't compete for
control of the interfaces and resolver; it's as passive as dhclient
was, hence why dhcpcd-base (it could just as easily been called
dhcpcd-bin) remains perfectly harmless even on a host that uses
networkd or network-manager. In the later case, IIRC, we even have a
netowrk-manager backend that can use the dhcpcd binary?

Btw, it's interesting that you phrased this as dhcpcd interfering with
others, and not the other way around. Biased, much?

Martin-Éric

Hi Martin,

Have you thought the implications of this this change all the way through
to user impact?

What's about bookworm users who currently have both dhcpcd and
network-manager installed? Is the observed breakage in #1107683 so bad it's
unlikeley there are any?

What if some exist and are relying on NM config for conectivity? Would this
break their systems on upgrade? I'm honestly not sure how apt tiebreaks
with conflicts. Which package would get removed in that case?

I'm happy to do some testing with debvm if we agree on this being a
concern.

Hi Martin,

Have you thought the implications of this this change all the way through
to user impact?

What's about bookworm users who currently have both dhcpcd and
network-manager installed? Is the observed breakage in #1107683 so bad it's
unlikeley there are any?

What if some exist and are relying on NM config for conectivity? Would this
break their systems on upgrade? I'm honestly not sure how apt tiebreaks
with conflicts. Which package would get removed in that case?

I'm happy to do some testing with debvm if we agree on this being a
concern.

Hi Martin-Éric, Daniel,


What's the answer here?


I'd like to see some reply to the concerns raised. Daniel, if you could
try and reproduce the scenario you're worried about that would be
appreciated.

Paul

to 3.7.2025 klo 20.12 Paul Gevers (elbrus@debian.org) kirjoitti:

As already stated, there is no impact. The Conflicts merely is
idiot-proofing the dependencies to avoid two networking daemons
fighting for control of the same interfaces. I've filed a bug against
network-manager to have a Conflicts against bin:dhcpcd to address the
same case, in reverse.

I'll happily address genuine issues. Daniel's "concerns" are whataboutisms.

Martin-Éric

to 3.7.2025 klo 20.27 Martin-Éric Racine (martin-eric.racine@iki.fi) kirjoitti:

Sure enough, neither of the two people who expressed concerns ever got
around demonstrating the negative impacts they foresee as requested by
Paul.

Meanwhile, Trixie is now released, making this bug a moot point. Closing.

Martin-Éric