On 2023/03/06 14:16, Klemens Nanni wrote:
> 06.03.2023 13:49, Raf Czlonka пишет:
> > To quote sthen@[0]:
> > 
> >     But that isn't, it is talking about <daemonname>_execdir,
> >     <daemonname>_flags, etc where you need to replace the <daemonname>
> > 
> > [0] https://marc.info/?l=openbsd-tech&m=165364961710717&w=2
> 
> I find this dance in rc.d.8 not helpful:
> .It Ar daemon Ns _flags
> 
> daemon_flags and foo_flags control the same value in the end.
> daemon_flags is set in rc.d scripts themselves and foo_flags can
> overrule those from rc.conf.local.
> 
> So why not mark them up as daemon_flags in rc.d.8 so that they become
> more discoverable via tags?
> 
> rc.d.8 still expains all the fuzz around replaing "daemon" with "foo"
> in detail, right in the same ENVIRONMENT section around the list.
> 
> When I read rc.d(8) to write my own script, I am looking for
> daemon_flags and not foo_flags, so that makes sense and seems to have
> priority over foo_flags wrt. markup since this is rc.d(8).

This ENVIRONMENT section of rc.d(8) is *specifically* talking about
lines added to rc.conf.local.

Most readers are not writing their own scripts, and we have way too many
users who say things like "I edited the rc.d(8) script to change the
flags" who will run into problems at update time. I'd like to avoid any
changes that reduce distinction between "foo_flags" in rc.conf(.local)
and "daemon_flags" in rc.d/foo.

> rc.conf.local(8) also explains the 'daemon vs. foo' dance, with the
> weird markup, but there it is fine and not important, since it is not
> the authorative source rc.d variables.


Reply via email to