rc.conf.d support for local_startup directories?

[Brooks Davis]

On Mon, Feb 06, 2006 at 09:30:07PM -0800, Doug Barton wrote:
> Howdy,
> 
> A post on -ports recently, and some other stuff I've been working on got me
> thinking. Is there any reason not to offer rc.conf.d support in the
> local_startup directories? I think that this would simplify a lot of issues,
> port authors could install the file with appropriate defaults, then
> deinstall it when they are done. No more messy stuff left over after a port
> is deinstalled.

What messy stuff?

> The only disadvantage I can see to this is that because of how the conf
> sourcing code is written, the variables in a file in an rc.conf.d directory
> will always override those in /etc/rc.conf[.local]. This could lead to two
> problems, one would be a potential POLA violation, the other is that there
> is a convenience factor now in just putting port_enable=yes in
> /etc/rc.conf.local, and having it still be there after you install the port.
> If rc.conf.d support became more widespread for ports, then users would have
> to either re-enable that port at every install, or (more likely) port
> authors would start enabling their port by default. One could make the
> argument that this is reasonable behavior, so I'm not sure this is a problem
> per se, just something to consider.

Deleting a config file that has modified by the user is wrong, unless
we add a really-really-delete option for pkg_delete and new plist
directives to go with it.  If I had to reconfigure my daemons after each
update I'd be really pissed.

> There is at least one way around this problem that I can see off hand, but I
> thought I'd throw it open for discussion first and see what people think.
> I've attached the simplest implementation I could think of to start the
> discussion.

I really don't like this idea, or at least your proposed use of
it.  It's exactly the sort of thing we got away from in the base
when /etc/default/rc.conf was created.  If we want defaults for
ports that aren't stuffed into rc.d scripts, we should create
${PREFIX}/etc/defaults/rc.conf.d/.  There's something to be said for
that since it would left us have /etc/defaults/rc.conf style comments
for variables.

> Index: rc.subr
> ===================================================================
> RCS file: /usr/local/ncvs/src/etc/rc.subr,v
> retrieving revision 1.47
> diff -u -r1.47 rc.subr
> --- rc.subr	10 Dec 2005 20:19:08 -0000	1.47
> +++ rc.subr	7 Feb 2006 03:50:33 -0000
> @@ -876,10 +876,12 @@
>  		fi
>  		_rc_conf_loaded=true
>  	fi
> -	if [ -f /etc/rc.conf.d/"$_command" ]; then
> -		debug "Sourcing /etc/rc.conf.d/${_command}"
> -		. /etc/rc.conf.d/"$_command"
> -	fi
> +	for dir in /etc $local_startup; do
> +		if [ -r "${dir%/rc.d}/rc.conf.d/$_command" ]; then
> +			debug "Sourcing ${dir%/rc.d}/rc.conf.d/${_command}"
> +			. "${dir%/rc.d}/rc.conf.d/$_command"
> +		fi
> +	done
>  
>  	# XXX - Deprecated variable name support
>  	#

If we've going to do this, we might consider deprecating local_startup
and creating a new local_startup_prefixes or similar to get the etc/rc.d
parts of the paths out of the way since we're planning to desupport
non-rc.d scripts at some point in the future.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20060206/cb5c7831/attachment.bin