On Thu, Aug 08, 2024 at 02:42:29AM -0300, Crystal Kolipe wrote:
> On Thu, Aug 08, 2024 at 05:18:41AM +0000, Andrew Christopher Hawk wrote:
> > I was checking out dhcpleased(8)'s manual page, and a certain sentence
> > had me bugging out a bit, so I tried to fix up the sentence in
> > question.
> 
> Whilst I agree that the wording could be improved, by adding:
> 
> > +and uses any such information to configure interfaces on which the
> 
> ... you are actually slightly changing the meaning, and introducing the
> implication that dhcpleased itself is responsible for all of the interface
> configuration via DHCP.
> 
> However, by way of example, when nameservers are configured via DHCP,
> dhcpleased passes details of those nameservers to resolvd, which needs to
> be running for those proposals to be added to resolv.conf.
> 
> So this documentation change needs a bit more thought.
> 

hi.

not sure if we want to get into the resolvd stuff or not. putting that
aside for now, i realise that any changes should probably take into
account the text in slaacd(8). i think the text there probably mirrors
the original intent, and is more helpful because it says what slaacd
does with the information:

DESCRIPTION
     slaacd is a stateless address autoconfiguration (SLAAC) daemon for
     clients.  It listens for IPv6 router advertisement messages, for example
     those sent by rad(8), on interfaces with the AUTOCONF6 flag set.  slaacd
     derives IPv6 addresses and default routes from received router
     advertisements and installs them in the kernel.  See hostname.if(5) and
     ifconfig(8) on how to enable auto configuration on an interface.

i wonder whether it'd be better for dhcpleased to more closely mirror
this...

jmc