From: dxld@darkboxed.org 
  
 Hi Simon, 
  
 On Wed, Oct 22, 2025 at 10:34:05PM +0900, Simon Richter 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. 
  
 *Yay* indeed :D. 
  
 > 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? 
  
 That was essentially the plan in my head, yeah. I expect ISC will get RMed 
 so we can replace it with a metapackage that just pulls in 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. 
  
 Which METHOD are you talking about auto, dhcp, static, manual? The defaults 
 vary. Another "yey" I found while working on this see the code ;-). 
  
  - inet6 auto has accept_ra=2 by default (which is questionable IMO), 
  - inet6 dhcp has accept_ra=1. 
  - inet6 static has accpet_ra=0. 
  
 > 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. 
  
 My implementation retains the previous behaviour with dhclient as best it 
 can, accept_ra=1 being the exception for now. So I'm not sure what you mean 
 exactly? 
  
 > >   - 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? 
  
 dhcpcd.service and dhcpcd@.service can simply declare 
 Before=networking.service and all is well AFAICT. No need for the big guns 
 -- yet :-). 
  
 The ordering is just the wrong way around in dhcpcd/unstable rn 
 (After=networking.service). 
  
 > > 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. 
  
 Not sure either TBH. Point is I don't think this was the intended effect 
 either way. 
  
 Thinking about what to do if we ever want to change the default again in 
 the future without similarly abusing dhcpcd-base: Do you think it would 
 make sense to introduce a dhcp-client (meta)package? 
  
 We could have the isc-dhcp-client transisional metapackage Depend on 
 dhcp-client and that would Depend on dhcpcd-base in turn while ifupdown 
 Recommends: dhcp-client. 
  
 dhcp-client could ship a marker file or something else ifupdown can pick up 
 from inet*.defn or just a up.d/down.d script -- though I'd have to think 
 through the implications of potentially changing details of up/down 
 ordering in that case. 
  
 > > 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. 
  
 I tend to agree, but I think we can do one better and have the two packages 
 interoperate cleanly instead of just avoiding each others interfaces -- 
 that's what dhcpcd.sh should achive modulo the boot ordering problem. 
  
 > 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. 
  
 I think upstream would be aminable to all of this. The changes make sense 
 purely from the perspective of dhcpcd's operation mode as far as I 
 understand it after experimenting with it and reading the code for a solid 
 week -- which may not be saying much for this beast, but hey ;-). 
  
 One caveat is that the per-iface modes are going away in dhcpcd v11 
 according to upstream, so we're patching what's about to be dead 
 code. However that's part of the reason I decided to go the extra mile and 
 make this all work with global manager mode. 
  
 This way assuming we ship the per-iface -> manager change to Trixie users 
 we have a clean and easy upgrade path in Forky+ once dhcpcd v11 drops the 
 other daemon modes. 
  
 The good news is that much of the hairy stuff in dhcpcd.sh should also be 
 able to go away once that happens. 
  
 > We'd also need to define a conflict resolution policy for dhcpcd vs 
 > systemd-networkd if we are touching dhcpcd. 
  
  
 [continued in next message] 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)