su 15.6.2025 klo 18.26 Michael Biebl ([email protected]) kirjoitti: > > [network-manager maintainer speaking here] > > Am 14.06.25 um 06:52 schrieb Martin-Éric Racine: > > > [ 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). > > In the past, network management systems did not declare conflicts > against each other.
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. > 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? 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
