[ On Sat, January 9, 1999 at 15:00:58 (-0800), Curt Sampson wrote: ]
> Subject: Re: Package paths: consensus?
>
> 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.

That wasn't the impression I got -- It seemed to me that only one person
was shooting and a whole bunch of other people voted for the "A" option
without showing that they understood the implications.

> 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.

Sure, this is just fine, but the issue here is where does the *admin*
find the files, not where does the application find them.  Arranging
this for the *admin* is *trivial* and need not be the enforced standard
for where the application looks for the files (hint: $PREFIX/etc -> /etc).

>     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?

That's not a very good argument.  Third party software generally does
whatever the author thought "right", and only rarely does a package
actually expect, by default, to find its configuration files in
$PREFIX/etc.  Indeed the vast majority of software that sticks to the
GNU makefile standards works this way:

`sysconfdir'
     The directory for installing read-only data files that pertain to a
     single machine-that is to say, files for configuring a host.
     Mailer and network configuration files, `/etc/passwd', and so
     forth belong here.  All the files in this directory should be
     ordinary ASCII text files.  This directory should normally be
     `/usr/local/etc', but write it as `$(prefix)/etc'.  (If you are
     using Autoconf, write it as `@sysconfdir@'.)

Proposal "B" would make it transparent to the user whether a package was
installed via pkg or directly from the original sources.

>     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?

For one reason, and one reason only -- some admins wish to segregate
third-party software from "system" software.  If/when UUCP is only
available as a third-party package then indeed it should look for its
configuration files in $PREFIX/etc/uucp.  If it simply becomes an
optional *system* package (i.e. its source is still maintained locally
in the "official" NetBSD source repository), then installing it as a
sepaate *system* package should be transparent to the current state of
having it be installed as part of the overall system.

>     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.

You've already used this argument in point 1.  I.e. I think these are
the same points....

>     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.

This argument is moot if you put a couple of simple symlinks in place.

>     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.

Again, as with point 5, strategic use of one or two symlinks solves this
problem.

> 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.

This is *NOT* a job for the pkg system -- this is an issue to do with
standardization of the site hierarchies.  These problems will exist, for
example because a site has modified its policies, or because an admin is
new to a site, and *NOTHING* the NetBSD pkg system defines will ever
eliminate them.  No matter how much any of us would prefer it, NetBSD
will never become the predominant operating system in the world.

Again, this is exactly the same as point 1+4.  If, and *ONLY* if a site
decides this is important they may create simlinks to ensure that admins
do find config files all in /etc.  This is *NOT* something NetBSD can,
or should even try to, mandate.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>