Subject: Re: Keeping /etc/defaults and /etc/rc.d in-sync
To: Jason R Thorpe <>
From: Frederick Bruckman <>
List: tech-userlevel
Date: 12/26/2001 18:17:15
On Wed, 26 Dec 2001, Jason R Thorpe wrote:

> On Wed, Dec 26, 2001 at 03:24:35PM -0600, Frederick Bruckman wrote:
>  > It's fine to say that "rc.d" isn't meant to be modified by the user, but
>  > if you need/want to replace, say, openssh, ntpd, or bind with a
>  > different version, there's no better way to do it than to install the
>  > replacement in /usr/local or /usr/pkg and change the path in the rc.d
>  > script.
> If you're installing an updated version of something, presumably you'd
> also remove the old versions in /usr/{bin,sbin}, yes?

Well, no. So what if I did? Then the new scripts would fail.

It's one thing if you're following the directions in a security
advisory because of a recently uncovered exploit, it's another if you
just want to download the latest version of "ntpd" to try it. In the
latter case, you might want to revert.

Besides, it's not true that "rc.d" has no user configurable parts
inside. As we've totally failed to come to any agreement on how to
handle pkgsrc rc.d scripts, we tell people to copy them into rc.d

So sure, since I already have to maintain diffs over rc.d, so I can
reproduce my configuration on a new system, I could live with "make
build" overwriting it. But I wouldn't be happy about it. I have
learned my lesson not to try to customize anything in "/usr" that
would be overwritten, but "/etc" is supposed to be the safe haven.