From owner-freebsd-ports@freebsd.org Thu Jul 2 18:54:21 2020 Return-Path: Delivered-To: freebsd-ports@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C013235D967 for ; Thu, 2 Jul 2020 18:54:21 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49yS1n4fZVz4BqG; Thu, 2 Jul 2020 18:54:21 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from localhost (unknown [IPv6:2400:4051:a743:3c00:16:ceff:fe34:2700]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: hrs) by smtp.freebsd.org (Postfix) with ESMTPSA id D857C19B89; Thu, 2 Jul 2020 18:54:20 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Date: Fri, 03 Jul 2020 03:54:03 +0900 (JST) Message-Id: <20200703.035403.856368268140192104.hrs@FreeBSD.org> To: timp87@gmail.com Cc: freebsd-ports@freebsd.org Subject: Re: set_rcvar() function use? From: Hiroki Sato In-Reply-To: References: X-Old-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-PGPkey-fingerprint: 6C0D 2353 27CF 80C7 901E FDD2 DBB0 7DC6 6F1F 737F X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="--Security_Multipart(Fri_Jul__3_03_54_03_2020_015)--" Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 18:54:21 -0000 ----Security_Multipart(Fri_Jul__3_03_54_03_2020_015)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pavel Timofeev wrote in : 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 ----Security_Multipart(Fri_Jul__3_03_54_03_2020_015)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iMoEABMKAC4WIQRsDSNTJ8+Ax5Ae/dLbsH3Gbx9zfwUCXv4tSxAcaHJzQGZyZWVi c2Qub3JnAAoJENuwfcZvH3N/TPACCQG57IywI2O3e1OCbZzkgMEkjJvXrwgBWB74 1xn0wRoZcET9ENt3A7PIyaSAwH+DsqizwSiQh77i5+jdkY9JWZTa0QIJAVowj7KS f0/cq7kVxTUa4cRQY98ff6foeDp0BTboqbc5prUzrnSvJJ5SAyVi2nVMi/z9Xj+Z R5OE8SN1ZzMvvp6M =yATc -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Jul__3_03_54_03_2020_015)----