From owner-freebsd-commit  Mon Sep 18 07:21:06 1995
Return-Path: owner-commit
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id HAA17192
          for freebsd-commit-outgoing; Mon, 18 Sep 1995 07:21:06 -0700
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id HAA17180
          for cvs-all-outgoing; Mon, 18 Sep 1995 07:20:59 -0700
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id HAA17169
          for cvs-etc-outgoing; Mon, 18 Sep 1995 07:20:56 -0700
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA17161
          ; Mon, 18 Sep 1995 07:20:46 -0700
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id HAA26408; Mon, 18 Sep 1995 07:20:39 -0700
To: paul@FreeBSD.org
cc: jkh@freefall.freebsd.org (Jordan K. Hubbard),
        CVS-commiters@freefall.freebsd.org, cvs-etc@freefall.freebsd.org
Subject: Re: cvs commit: src/etc rc 
In-reply-to: Your message of "Mon, 18 Sep 1995 14:51:23 BST."
             <199509181351.OAA14322@server.netcraft.co.uk> 
Date: Mon, 18 Sep 1995 07:20:38 -0700
Message-ID: <26406.811434038@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-commit@FreeBSD.org
Precedence: bulk

> Yuck, not because of SYSV but because of packages sticking stuff
> in /etc.  I keep my root partition  small and as read only as
> possible. This breaks that philosphy big time since it can grow
> without bounds as I add packages.

In theory, yes, but there are two mitigating factors:

	1. Very few packages need to fuss with this.  A very small
	   handful of utilities, from gated to apache, actually have
	   "system startup" behavior.  I rather doubt that people will
	   be starting emacs or tclsh from here.. :-)

	2. Such startup files are typically going to be *very small*,
	   say one or two lines.  Even the most bit starved root
	   would be unlikely to fall over from this.

> I'm not happy about this at all since we had a long discussion
> about this on ports and I came up with a perfectly workable solution
> that has basically being ignored, but I guess Jordan knows best.

I don't remember this discussion and I certainly wasn't ignoring it
when I committed the change.  It was more a matter of me cleaning out
my inbox and finding this old proposal from Garrett..

Honestly, I don't know why you always have to be so confrontational in
bringing up such issues!  "Jordan knows best" is hardly my attitude, I
was simply trying to do some good and folks like Julian have already
been quite enthusiastic in their support for it.  Rather than assuming
us nasty U.S. people have it in for you personally at each and every
turn, you might perhaps try assuming innocence before guilt?  I can
assure you, you'll have *far* fewer fights that way!

As a point of fact, I see no reason why *both* mechanisms could easily
exist.  /etc/rc.local.d for system local changes and
/usr/local/etc/rc.local.d for truly local ones.  The only objection I
could see being raised is that invoking things out of /usr/local/etc
at startup time (and while root) could be construed as a massive
security hole.  Especially if you're mounting your /usr/local from a
common fileserver for which you've no control.

Thoughts, folks?  I'm not an unreasonable person and have no axes to
grind where this change is concerned.

					Jordan