rc.d and ports

[Oliver Eikemeier]

Mike Makonnen wrote:

> On Tue, Feb 24, 2004 at 10:59:07AM +0100, Oliver Eikemeier wrote:
> 
>>I guess I don't fully understand what modifications you suggest for the
>>ports. What is needed to fit into rc.d?
> 
> The modification I ask for in my initial email :-)
> If ports want to be a part of rc.d then they must use appropriate rc.d
> mechanisms. My rc.d modification to support
> /usr/local/etc/{rc.conf,defaults/rc.conf,rc.conf.d} are necessary
> so that ports configuration knobs don't pollute the enviroment for
> base system scripts.  But other than that, it should be up to the
> ports to fit into the rc.d scheme.

I guess we agree here. I'll post a follow-up with uses
${PREFIX}/etc/{rc.conf,defaults/rc.conf,rc.conf.d} too. The problem here
is that you'll have to support different prefixes, like /usr/X11R6.
 
> The problem with your patch is that it is a bunch of hacks to
> rc.d to semi-incorporate ports into the rc.d mechanism. My point
> is: don't hack rc.d to semi-incorporate ports. Instead, we should
> fully incorporate ports into rc.d.

... which this patch tries do.

>>>>I guess we don't need this (and shouldn't do it, since 
>>>>${PREFIX}/etc/defaults/rc.conf
>>>>might be read-only). Defaulting xxx_enable to "NO" seems to be 
>>>>sufficient, with
>>>>
>>>>[ -z "$xxx_enable" ] && xxx_enable="NO"
>>>>or
>>>>xxx_enable=${xxx_enable:-"NO"}
>>>>before calling load_rc_config $name
>>>
>>>Again, why special-case ports scripts ?
>>
>>Because the defaults belong to the port, not to the base system. I want them
>>to go away with the port. Nobody (and especially not ports) should edit
>>whatever/defaults/rc.conf, and how would I otherwise cope with the situation
>>that default flags may change?
> 
> Then the ports can use /usr/local/etc/rc.conf.d. When the port is deleted
> it can just delete the appropriate conf file in that directory without the
> need to edit any files.

${PREFIX}/etc/rc.conf.d files may be edited by the user, so you can't simply
delete them.

>>I guess I incorporate ${PREFIX}/etc/defaults/rc.conf and another change in
>>PR 56736, the main point there was that I wanted them to participate in 
>>rcorder,
>>which I believe is a good thing, especially when you consider the 
>>possibility
>>to move sendmail or other parts of the base system to ports.
>>
>>So I understand that sourcing ${PREFIX}/etc/defaults/rc.conf is the main
>>reservation that you have against this patch?
> 
> No. As I have tried to state already I don't like it because it is an
> unnecesary hack. As for participating in rcorder(8), first the ports
> have to support all the rc.d mechanisms. Your patch simply hacks rc.d
> to allow those ports that choose to use some of the rc.subr functionality
> to participate in rcorder(8)ing. What should happen is that our ports
> infrastructure should fully support rc.d and all ports scripts should
> be modified to work with rc.d. Otherwise, we will have lots of confused
> users wondering why some ports are ordered with the base system scripts and
> others are not.

I get your point, but currently there is no way to convert *all* ports, we
don't have the manpower to convert and test them all. So we need a transition
path, where we may deprecate older scripts at some point. I guess we agree
that ${PREFIX}/etc/rc.conf should be sourced by ports rc.d scripts, but this
is not enough to integrate ports in rc.d without breaking the existing ports
base. The patch, supplemented by ${PREFIX}/etc/{rc.conf,defaults/rc.conf,rc.conf.d}
*is* a step forward in that direction.

-Oliver