set_rcvar() function use?
Hiroki Sato
hrs at FreeBSD.org
Thu Jul 2 18:54:21 UTC 2020
Pavel Timofeev <timp87 at gmail.com> wrote
in <CAAoTqfss_-=N4EGd=XKDA+tzqvK5YZ7Ci6QJZvvip2xc64fYrw at mail.gmail.com>:
ti> Hello, dear community. I'm confused, please, help me.
ti>
ti> There is a rc.subr function which was buried[1] and resurrected[2] after a
ti> couple of years in almost the same form.
ti>
ti> I don't know what happened behind the scenes, but I have a question.
ti> Is it a preferable way to define a rc.conf variable these days in rc
ti> scripts (again/over and over)?
I resurrected it because I wanted to change the standard style to use
set_rcvar() to declare the user-configurable variables, their default
values, and descriptions without losing backward compatibility.
There is no clear consensus on this migration, however.
The primary motivation was to add multi-instance support in rc
scrupts[1]. To support this, the set_rcvar() style was required.
[1] https://lists.freebsd.org/pipermail/freebsd-current/2014-October/052706.html
Another issue I am aware of is that rc scripts installed by ports/pkg
that they cannot have related entries in /etc/defaults/rc.conf for
the default values. So a lot of ports tend to end up with
assignments in the rc scripts like this:
: ${foo_enable=YES}
This introduces inconsistency and it is difficult to find
documentation about which knobs are available. The set_rcvar() style
should mitigate this and also implements a support to obsolete a
variable when needed. set_rcvar_obsolete() will convert the old
value to the new variable automatically or emit an error if there is
no compatibility between the old and the new.
I committed set_rcvar() part only in [1], not whole of the
multi-instance support. This is because it was quite difficult to
control which version of rc.subr is installed. If rc scipts in ports
use set_rcvar() on older versions of FreeBSD which do not support it,
the port breaks. At this moment all of the supported FreeBSD
versions have the resurrected set_rcvar(), so I think it is now safe
to use it globally. Probably we might want to add a version number
or feature flags in rc.subr to prevent this kind of situation.
I am planning to revisit the multi-instance support shortly because I
am using it for a long time and I think it is useful. While I did
not receive a strong objection to it so far, it is also true that
adopting the set_rcvar() style was not discussed properly. I would
like more feedback before moving forward.
-- Hiroki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 342 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20200703/ef4c22bd/attachment.sig>
More information about the freebsd-ports
mailing list