Subject: Re: /usr/pkg/etc vs. /etc
To: Todd Vierling <email@example.com>
From: Curt Sampson <firstname.lastname@example.org>
Date: 12/10/1998 14:01:51
On Thu, 10 Dec 1998, Todd Vierling wrote:
> : The whole concept of /usr/pkg/etc makes sense to me only for things
> : that don't change between systems, such as files to be called from
> : rc.local. We don't put ssh configuration files in /usr/pkg/etc;
> [because it was a special hack specific to the ssh pkg,]
Yes, but my questions is, *why* do we have a special hack specific
to the ssh package? What's so different about it that it should
work the way it normally does if you don't use the pkgsrc version,
but anything else in pkgsrc should have files go in a different
place than if you compiled from the original source?
> : it seems to me we shouldn't put other programs' configuration files
> : there either.
> That's a lot of programs. No, let me correct: that's a *LOT* of programs.
It's not a *LOT*, it's as many as you have installed. I don't expect
most people out there have more than a few dozen packages installed,
not all of which will install things in etc. I've got 63 on one of
my machines right now, and that produces only a half dozen files
in /usr/pkg/etc. Dump those in with the hundred-odd files that are
already in /etc, and you won't notice the difference.
> loathed the move of ssh's config files to /etc, not because it broke "put
> all pkg files in one place," but it assumed that ssh was one of the "few"
> programs that would need it. What about ssleay.cnf (which I specifically
> moved to /usr/pkg/etc to keep it with the rest of the config files)? What
> about /usr/pkg/etc/procmailrc?
Exactly my point! Why not move these?
> If someone wants to share /usr/pkg, he should be perfectly capable of
> symlinking /usr/pkg/etc (or even /usr/pkg/etc/httpd) elsewhere.
True enough. But you've just made two assumptions that I'd like
you to defend.
1. There is nothing that should ever be shared in /usr/pkg/etc.
Sample config files should not go there, nor should the startup
scripts for applications. (This means, too, that it's not possible
to upgrade the script that starts, say, Postgres or MySQL across
all machines when you put in a new package.)
2. We should have an /etc/rc.d directory, and the files in it should
use the format that the packages use.
Personally, I think that we shouldn't be making decision 2 until
we get a bit ore consensus on how we want to change our rc system,
and I think there is a good argument for keeping some etc-like-stuff
that is common to all machines (though easily overridden).
I don't see the advantage of keeping every last bit of package-related
stuff under /usr/pkg, except for people developing package stuff
that want the ability to blow it all away easily. We don't normally
separate the configuration files for NetBSD and non-NetBSD programs
(most everyone puts the configuration files for /usr/local/sbin/sshd
in /etc, for example). Perhaps you can enlighten me as to the
advantages of seprating the configuration files for package programs
and non-package programs.
> Please, no. Try symlinking /usr/pkg/etc or /usr/pkg/etc/httpd or use "httpd
> -f". (After all, the /usr/pkg/etc/httpd/httpd.conf is just the compiled-in
I could say the same to you, if you want to keep your config files
in /usr/pkg/etc. However, given a shared /usr, my method has the
advantage of the server failing to start when httpd is run on a
random, unconfigured machine, rather than starting with someone
else's configuration file (and making who knows what available to
the whole Internet).
I'd be intrested in opinions from other than me and Todd here, too.
I usually find massive numbers of people telling me that I'm wrong
to be a reasonably convincing argument, even if I don't understand
why I'm wrong. :-)
Curt Sampson <email@example.com> 604 801 5335 De gustibus, aut bene aut nihil.
The most widely ported operating system in the world: http://www.netbsd.org