Pavel Timofeev <tim...@gmail.com> wrote in <CAAoTqfss_-=N4EGd=xkda+tzqvk5yz7ci6qjzvvip2xc64f...@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
pgpGu8YqCnq10.pgp
Description: PGP signature
