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 in them. 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 > etc/? You can locally have what you want - just add another rc.conf in your local configuration. -- B.Walter BWCT http://www.bwct.de ticso_at_bwct.de info_at_bwct.deReceived on Fri Feb 20 2004 - 04:58:31 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:44 UTC