Feature Request: /usr/local/etc/rc.conf support
ticso at cicely12.cicely.de
Fri Feb 20 05:58:31 PST 2004
On Thu, Feb 19, 2004 at 02:11:04PM -0800, Freddie Cash wrote:
> Just curious why everyone is trying to come up with such complex
> solutions to this issue.
> Everything else is split along the lines of base <---> ports. Why
> should this be any different?? There's an etc/ directory for the base
> system, and an etc/ directory for the ports. The beauty of this
> system is that ports don't muck around in the base system (with the
> exception of the few that support and override_base option).
The nice about having this in /etc is that this is a machine directory,
while /usr/local might be shared over multiple machines.
The fact that most /usr/local/rc.d scripts start unconditionally
without checking rc.conf legitimation first always frustrated me.
BTW the fact that a lot of port rc.d scripts just do a start when
called stop is more frustrating.
Nevertheless I think defining anything is much better than the current
situation of having mixed handling.
> It's really annoying to have to keep changing between /usr/local/etc/
> to edit configuration files, and /etc/ to enable daemons that are
> started by scripts in /usr/local/etc/rc.d/.
/usr/local/etc is not so much a problem, because you relocate them
for binaries that won't start without beeing confirgured first.
In the same way a /usr/local/etc/rc.conf would hurt as long as
/etc/rc.conf is included as well and ports don't put active entries
A port upgrade is always a problem in shared environment, because they
often add global start scripts - I don't like to see automatically
enabled or disabled services in /usr/local/etc/rc.d then.
> There's an rc.conf for the base system, why not an rc.conf for the
> ports? Why does a port have to modify anything in the base system's
You can locally have what you want - just add another rc.conf in your
B.Walter BWCT http://www.bwct.de
ticso at bwct.de info at bwct.de
More information about the freebsd-ports