From: tglaser@b1-systems.de 
  
 >> (@all please keep me in Cc, d-devel is too high-volume to subscribe) 
  
 On Thu, 23 Oct 2025, Daniel Gr€€ber wrote: 
  
 >(merging this back into the main thread) 
  
 Huh. Funny, because while I set the References header so it would 
 merge into the main thread, you managed to clear it out completely, 
 starting a new thread. 
  
 I€€€ve added References again, hoping MUAs will be good enough to 
 merge threads again. 
  
 >On Wed, Oct 22, 2025 at 08:22:07PM +0200, Thorsten Glaser wrote: 
 >> €€€ but there€€€s a fourth: just €€€inet dhcp€€€ and no inet6 stanza, 
 [€€€] 
 >Right. I don't explicitly reason about that configuration since kernel 
 >defaults apply so it's just not really managed by ifupdown at this point, 
  
 Yes, precisely: ifupdown and the DHCP client it calls should not 
 change kernel defaults to break this, as it€€€s the default. 
  
 >Thinking about this some more I may consider requiring `inet6 auto` in the 
 >future for this configuration, but not without a proper transition and 
 >ample notice. 
  
 That directly contradicts what you wrote above. That would mean 
 ifupdown would break kernel defaults without the user explicitly 
 asking for it, by merely the user specifying IPv4 configuration. 
  
 This will be a net loss because at the moment, IPv6 €€€just works€€€ 
 with no configuration for many people because of the kernel default, 
 and this should not change to the worse. 
  
 >> (I€€€ve been bitten by ifup/ifdown issues when listing both inet 
 >> and inet6 for the same interface in the past.) 
 > 
 >Can you elaborate here? 
  
 Unfortunately not, it€€€s been a while. 
  
 >> I€€€ve never seen inet6 auto used anywhere, only inet6 static (and 
 >> I€€€ve not personally encountered inet6 dhcp yet, and given rtadvd 
 >> and rtsol work, I don€€€t quite see the use for most networks). 
 > 
 >Strange, given that this is what d-i will produce by default -- if the 
 >installation network has IPv6 RAs at least. 
  
 As of which release? ;-) 
  
 I€€€m _somewhat_ sure the bullseye installer didn€€€t, and I€€€ve since 
 switched away from d-i to just debootstrap plus a small shell script 
 that does what d-i does to the installed system (except it doesn€€€t 
 copy the live CD€€€s network config), as has been a growing trend 
 among (at least) Grml enthusiasts for years. 
  
 >My ifupdown now overrides the --slaac config for the interface it's upping 
 >so you can revert this to get a clean config or leave it, doesn't 
 >matter. It'll work. 
  
 OK. 
  
 >> While there, I do have more questions related to it. 
 >> 
 >> +option ntp_servers 
 >> 
 >> Where would that be handled? If I wanted to, where do I have 
 >> to look to write integration for this for? (I use a custom 
 >> OpenNTPD packaging.) 
 > 
 >See dhcpcd-run-hooks(1). Unfortunately we don't have .d support there yet 
 >see #1101003. 
  
 Ah, okay. (Not needed at this time, so just curiosity.) 
  
 >> +# hands off 
 >> +nohook resolv.conf, hostname, timezone, lookup-hostname 
 >> 
 >> Is there a way to control this from ifupdown (for both ISC 
 >> and dhcpcd)? 
 > 
 >Not at the moment, no. 
  
 OK. 
  
 >IMO if you need to make changes that deep it's alright to have to go to the 
 >dhcp client config files to do it honestly, unless you disagree? 
  
 I find €€€hands off my resolv.conf€€€ (the standard config tends to not 
 change the system hostname, domain and timezone, but since I saw this 
 in the manpage I added it) is the one single change to DHCP client 
 configuration I need in most places where I need any. This could also 
 be handled by the hooks or something, but if there isn€€€t any mechanism 
 for this at the moment, don€€€t lose any time for this, the other issues 
 are more important. 
  
 Just I don€€€t consider €€€hands off my hostname, domain and timezone€€€ 
 something I should even *have* to specify, and €€€hands off my resolv. 
 conf€€€ 
 the one useful high-level toggle here (defaulting to write it is okay, 
 but perhaps I run a recursive resolver myself and have that in the conf). 
  
 >> Note that it could also be started from /etc/init.d/dhcpcd, so 
 >> ordering there also needs to be correct. 
 > 
 >Naturally, but I do think that should also be possible. I'm just not 
 >familliar with sysvinit's ways. 
  
 Yes, I was just pointing out that not everyone uses systemd. 
 An X-Start-Before: in the LSB pseudoheader should suffice, but 
 the debian-init-diversity mailing list is available to help, 
 once you have a concrete setup. 
  
 >> Likely not going to happen, as it has no security support. 
 > 
 >Well given that we've shipped isc-dhcp-client in Trixie already without 
 >properly moving all users over that ship has kinda already sailed. Now we 
 >have to support it. See #1106121. 
  
 It€€€s not the first package we ship in a stable release for users€€€ 
 convenience that has no support. (And it allows people to decouple 
 €€€upgrade to trixie€€€ from €€€switch to kea€€€, as kea in bookworm was€€€ 
 not quite ready.) 
  
 >If we remove the release-notes notice at least fewer users might try to 
 >switch and consequently run into problems. Idk. if that'd really be a 
 >good idea its just a thought. 
  
  
 [continued in next message] 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)