From owner-freebsd-ports@freebsd.org Fri Jul 3 07:53:18 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 F1CFE36DAAD for ; Fri, 3 Jul 2020 07:53:18 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: from mail-ej1-f66.google.com (mail-ej1-f66.google.com [209.85.218.66]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49ynJZ1cMyz3fq5; Fri, 3 Jul 2020 07:53:17 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: by mail-ej1-f66.google.com with SMTP id w16so33223084ejj.5; Fri, 03 Jul 2020 00:53:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=GQ8895v8MDZ8VMKOpmjCsL5kC8nngprlxj5L+vyOvPE=; b=DxKQBWvxVltrp/0BhB9cxbaKOCHU3/VTj+X8ZUok6esYvhUekohyrwpqZ6VKfttX0B N2MY0F9X1noGH0zmYWRBp3eMvasOSxsy8XXLehgwas9D/aQ7C+LqQXJ9veIty6XkOSxS zFAO0ku695+uWEpVXDpevuBsHSuNWvOtUBMVtjFTznN2aCQjbt5wGntrWZz2NFEw1+B5 hWE3BUmyICJr9oDgjmz7AF+SiLU6nC9erMGiJdryb7cuEzVJ3U3vkPZUoo0Ndq8RHgt3 XJb6lWr0yjkYE6ICWTDnJTgTsmt9HW6qI9jH/q7rYwjo0zePs61PpR5ADLJoX+y82UIn tQCQ== X-Gm-Message-State: AOAM5312yoR4MgddZF8hjImki6jFe4LC6meDk3JDCYtffELN5gRhIM+M On5yq4uhe+/yiEJ3XA72Umfbgw2MX10= X-Google-Smtp-Source: ABdhPJyliCdZftgw7+lP+iJqqyE71DJjip2HL/BNwJxXuA/2vj7nczQeoJCBK+RhTyRGHDb4x0MyoA== X-Received: by 2002:a17:906:4acc:: with SMTP id u12mr7458520ejt.358.1593762796278; Fri, 03 Jul 2020 00:53:16 -0700 (PDT) Received: from ?IPv6:2a02:8109:98c0:1bc0:5e5f:67ff:fef4:ffd8? ([2a02:8109:98c0:1bc0:5e5f:67ff:fef4:ffd8]) by smtp.gmail.com with ESMTPSA id g6sm8813281ejz.19.2020.07.03.00.53.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Jul 2020 00:53:15 -0700 (PDT) Subject: Re: set_rcvar() function use? To: Hiroki Sato , timp87@gmail.com Cc: freebsd-ports@freebsd.org, manu@FreeBSD.org References: <20200703.035403.856368268140192104.hrs@FreeBSD.org> From: Mateusz Piotrowski <0mp@FreeBSD.org> Message-ID: <34921b6e-ce3a-13e4-0cc1-3ca47b5a9cef@FreeBSD.org> Date: Fri, 3 Jul 2020 09:53:13 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200703.035403.856368268140192104.hrs@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 49ynJZ1cMyz3fq5 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mpp302@gmail.com designates 209.85.218.66 as permitted sender) smtp.mailfrom=mpp302@gmail.com X-Spamd-Result: default: False [-1.17 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; ARC_NA(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[209.85.218.66:from]; DMARC_NA(0.00)[FreeBSD.org]; NEURAL_HAM_LONG(-0.85)[-0.848]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.32)[-0.319]; RCVD_IN_DNSWL_NONE(0.00)[209.85.218.66:from]; NEURAL_HAM_MEDIUM(-1.01)[-1.005]; FREEMAIL_TO(0.00)[FreeBSD.org,gmail.com]; FORGED_SENDER(0.30)[0mp@FreeBSD.org,mpp302@gmail.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[0mp@FreeBSD.org,mpp302@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com] 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: Fri, 03 Jul 2020 07:53:19 -0000 Hi, On 7/2/20 8:54 PM, Hiroki Sato wrote: > 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. AFAIR, manu@ was concerned at some point that using set_rcvar() extensively might result in slowdowns on embedded systems. Regards, Mateusz