Date: Tue, 24 Feb 2004 13:14:52 +0100 From: Oliver Eikemeier <eikemeier@fillmore-labs.com> To: Mike Makonnen <mtm@identd.net> Cc: freebsd-arch@FreeBSD.org Subject: Re: rc.d and ports Message-ID: <403B403C.7040701@fillmore-labs.com> In-Reply-To: <20040224103932.GA20467@mobile.acs-et.com> References: <20040223084146.GA4202@mobile.acs-et.com> <4039D9FF.40208@fillmore-labs.com> <20040224072401.GB1125@mobile.acs-et.com> <403B206B.7000101@fillmore-labs.com> <20040224103932.GA20467@mobile.acs-et.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?403B403C.7040701>