On Sat, 9 Jan 1999, Thorsten Frueauf wrote:

> > So you want every pkg config file in /etc? Well, so again at least
> > I object to that, because I want this seperated *by default*.
> -----------------------------^
> 
> obviously add "don't" in here :)

Sorry, I'm really not clear on this. You object to putting them in
/etc because you *don't* want them separated? Doesn't putting them
somewhere other than /etc separate them from the rest of the config
files system?

> > If its an option (like linking /usr/pkg/etc to /etc) its ok, as its
> > done on purpose by the user.

Well, I campaigned for having a way to separate them if somebody
wanted to, but I was pretty much shot down here. I can accept that,
though, because I feel that separating them is the extremely odd
case, not what would typically happen.

Anyway, before I get into the reasons to have packages use only
/etc, I feel I'd better clarify what this proposal says, in case
there's any confusion or misunderstanding. Here's this bit of the
proposal as it stands:

    1. Machine-specific configuration files that are actually used
    by programs go in /etc. This is the *only* place where programs
    would ever search for their config files.

    2. If there are non-machine-specific data files, they would go
    in the appropriate directory for that: /usr/pkg/libdata or
    /usr/pkg/share.

    3. Example configuration files would be installed under
    /usr/pkg/share/examples/<package-name>.

    4. (Optional, but I'd be nice if someone codes it.) There would
    be an option to pkg_add to install just the example config
    files from /usr/pkg/share/examples/<package-name>, if config
    files currently don't currently exist in /etc. This would mean
    you could do a full pkg_add on your NFS server, and then do
    this partial pkg_add on all your NFS clients.

Here's a summary of the reasons to have package config files go in
/etc by default.

    1. Inconsistent within the package system. What reason is there
    to look in /usr/pkg/etc/apache for apache config files, rather
    than in /etc, but look in /etc for ssh config files? They're
    both packages after all.

    2. Inconsistent the standard installs of programs: if you just
    grab a program and compile it, it most likely dumps its config
    files in /etc. Why should one have to worry about whether BIND
    or sendmail was compiled inside or outside /usr/pkgsrc when
    one is setting up a name server?

    3. Problems with moves between package system and base install:
    pieces of software come in and out of our tree. As an example,
    gtexinfo is being imported, and uucp will likely one day move
    to a package when we have a better packaging system for installs.
    Why should a user who was using /etc/uucp/sys in 1.4 have to
    switch to /usr/pkg/etc/uucp/sys in 1.5?

    4. It's not normal Unix. /usr/pkg/etc is not where any other
    Unix system in the world puts any config files, so this can
    create a bad experience if this happens by default for new
    users. At least if it happens on your system, we can say `well,
    he changed the default install' and hopefully recover the new
    user that way. But otherwise it's going to be seen as a gratuitous
    incompatability by a *lot* of people.

    5. It breaks quite quickly if you share /usr amongst multiple
    machines, since the whole point of putting files in /etc is
    that they're machine-specific config files.

    6. There are circumstances where you do want to share some
    config files amongst multiple machines. However:
	a) These are fairly rare, and such a configuration should
	   only be attempted by a sysadmin who really knows what
	   he's doing.
	b) There's no particular reason that the files you want
	   to share would be limited just to those programs in
	   /usr/pkg.

My biggest worry would be things like #3: you just can't know where
a config file for something like named is. I've seen this one, in
particular, bite a rather tired sysadmin whose named started up
with the wrong set of config files, and take out DNS for a couple
of hundred domains. If we want to be thought of as reliable, we
can't have gotchas like this sitting in the system waiting to pop
up. You can't deny that life becomes at least a little easier if
you always look in /etc for config files, rather than trying to
decide whether the /etc or the /usr/pkg/etc ones are the correct
ones, most up to date, or being used by a particular program.

cjs
--
Curt Sampson  <cjs@cynic.net>   604 801 5335   De gustibus, aut bene aut nihil.
The most widely ported operating system in the world: http://www.netbsd.org