Prev: ipsec-tools fix broken in CURRENT
Next: libvpx-0.9.1 doesn't seem to want to compile on current.
From: Hiroki Sato on 4 Aug 2010 23:25
Hi,

This may be discussed already but I could not find which was correct,
so please point out it if we already have a consensus...

Well, I am wondering if an rc.d script installed by a port must have
": ${foo_enable:=NO}" line. An example in the porter's handbook
includes this, and I can understand it works fine. My question is
"this is really needed or not".

When $foo_enable is not defined, checkyesno() displays "WARNING:
$foo_enable is not set properly - see rc.conf(5)" and it is
interpreted as NO. I was thinking this message is useful for letting
people know which knob(s) should be configured by themselves after
the installation, but recently someone pointed out this was not
consistent and the default value should be defined as NO in the
script.

I can understand setting it as NO by default and allowing a user to
override YES/NO in rc.conf work fine and intuitive. However, is
there a case that the $foo_enable is set as YES by default? If not,
what is the reason why the warning is displayed instead of simply
thinking it as NO when $foo_enable is undefined?

My feeling is that 1) $foo_enable should be interpreted as NO if not
defined and a user should configure it (YES/NO) by herself after the
installation, and 2) other variables like $foo_flags or $foo_pidfile
should have their default values to allow the software be able to run
simply by adding a line foo_enable=YES into rc.conf.

While I do not have a strong opinion on 1), I am not sure if it is
the correct interpretation. Setting the variable as NO by default
will make the warning message disappear, but in that case it is
difficult for the user to find the knobs. And if it is equivalent to
NO when the variable is not defined, I don't understand what is the
advantage of setting it as NO explicitly by default.

Since most of ports I am maintaining do not have this line, I need to
fix them if setting the variable as NO consistently is preferable.

-- Hiroki
From: Doug Barton on 5 Aug 2010 01:34
On 08/04/10 20:25, Hiroki Sato wrote:
> Hi,
>
> This may be discussed already but I could not find which was correct,
> so please point out it if we already have a consensus...
>
> Well, I am wondering if an rc.d script installed by a port must have
> ": ${foo_enable:=NO}" line.

That particular style is not mandated, but the policy is that all ports
should ship with a default setting of _enable=no. The default is a
security issue, in that an affirmative step by the user should be
required to enable newly installed services. This also mirrors policy
for almost everything in the base. Although in the last few years more
services in the base have defaulted to on, of the 20 or so things in
/etc/defaults/rc.conf that are enabled by default there are only 3 that
are actual services; devd, sendmail_submit, and cron. Most of the rest
are either boot-time things (like cleanvar_) or configuration elements
of services that are themselves disabled by default (like
named_chroot_autoupdate and named_symlink_enable). Requiring the
explicit setting of _enable to no (rather than letting it error out)
also mirrors the practice in the base of having /etc/defaults/rc.conf
which explicitly disables everything.

I find it impossible to believe that at this stage in the game there are
still users who are confused by how to enable services, and if they are
the example in the porter's handbook provides sample text for the
comments of the rc.d script to explain what to do. There are also a
non-zero number of ports that include instructions in their pkg-message
files.

> Since most of ports I am maintaining do not have this line, I need to
> fix them if setting the variable as NO consistently is preferable.

I believe the examples in
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/rc-scripts.html
are fairly thorough, and relatively well documented. If you have any
questions about the text please don't hesitate to bring them up, I am
always looking for ways to improve it.


hth,

Doug

--

Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/

Computers are useless. They can only give you answers.
-- Pablo Picasso

_______________________________________________
freebsd-ports(a)freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"

 | 
Pages: 1
Prev: ipsec-tools fix broken in CURRENT
Next: libvpx-0.9.1 doesn't seem to want to compile on current.