On Tue, 15 Dec 1998, Todd Vierling wrote:

> Curt, considering I've completely butchered this, could you give me some
> input?  ;)

It's hardly butchered. :-) In fact, it's pretty similar to my
original proposal. The major change has to do with moving $PREFIX
so that it does not cover etc and var, and adding a configuration
directory. 

Here I'll deal with another message you sent as well. Sorry, BTW,
for being slow to respond; I am tracking this thread, but have not
had a lot of time to reply in the last couple of days.

My biggest objection is to having both /etc and $PREFIX/etc. There
are a few points I see related to this.

1. Shared configuration files are actually quite rare in most
circumstances. (I've yet even to see a list of config files likely
to be shared amongst a set of fairly heterogenous systems, such as
a dozen workstations each owned by a different professor in a
university.) In those circumstances where they're not rare (such
as a homogeneous workstation lab), they're not at all limited to
configuration files for packages, and a more general mechanism than
just doing it for packages will be needed anyway.

2. With the symlinked /etc/config pointing to /pkg/etc/config, it's
rather too easy for a user on one machine to inadvertently edit
the config file used by a number of other machines. If I were the
admin, and I were going to symlink to shared config files, I'd want
to set up partition that is read-only to all but one machine for
this, to avoid this problem. Also, if I were doing this, I'd probably
want to be doing it for other files that are not package related
(such as resolv.conf). If I've separated my pkg material, I end up
polluting it with non-pkg material (/usr/pkg/etc/resolv.conf or
whatever), or having two directories where shared config files
reside.

3. Long after this discussion is over, someone's going to add a
package, do the `obvious' thing, and have it search for the config
files in $PKGDIR/etc, which is Wrong. A large argument will ensue,
tying up the mailing lists and wasting a lot of developer time. :-)

In short, sharing config files is not normal, it's a Serious
Administrative Decision that we should not encourage in novice
sysadmins. In the non-novices, it will be dealt with for the
non-package stuff, and so there's no need for the package system
to provide another mechanism to do this.

Also, I want to stress again the importance of having One True
Configuration Directory on a system, regardless of where programs
come from. I've seen important, production name servers give out
incorrect data for hundreds of domains because of an understandable
operater error related to config file location. These errors are
indeed operator errors and Not Our Fault, but I've seen enough of
them to be convinced that they're never going away, and we should
do our best to provide safety nets, so long as they don't get too
much in the way.

My other, though lesser, concern, is with your scheme we have three
places to put files:

    $PREFIX/whatever
    /etc
    /var

No problem, except how do we set things up so we can use something
other than /etc and /var when debugging PLISTS and whatnot? Basically,
it looks like we would have to drop this requirement:

> 3. It must be possible to have the package system install files in a
>    separate area, where they are not mixed in with the standard system
>    binaries.

If nobody else is particularly unhapppy about it being dropped, I
can live with it easily enough. (I do a lot of my package work on
a machine I wipe once in a while anyway.)

If we do decide to drop it, then we look at using /pkg -> /usr 
rather than /pkg -> / to get the integrated packages. You mention:

> Right.  That's the `logistical problem' that I mention; saying that /pkg ->
> / or /usr gives you the ability to replace system binaries *assumes* that
> the user will be making the symlink like that, and that leaves people that
> do /pkg -> /usr/pkg stuck.

I'm not sure I understand this. Those who do /pkg -> /usr/pkg didn't
want system binaries replaced, right? It's the same situation now;
if you install a new version of BIND from the package system, you
don't wipe out the old version. 

But with my idea of including PLISTs for system files in our base
install, this isn't that much of a problem anyway, I think. The
plist for bind would initially have /usr/sbin/named in it, and
that's what would get deleted when you removed it. Then when you
installed a new BIND pkg, it would end up in the package prefix
area instead.

> Yeah, pkg/libdata/pkgdb would probably be best, then.

Sure.

> : (do we then need a per-host database
> : saying the the config/var files are installed?)...
> 
> `Yipe!'  :)

The correct answer, I think, is `It's not worth the effort.' Some
packages will work just fine with no host-specific files; others
will fail in part and give obvious error messages (with ssh, for
example, it looks to me as if the client would run, but the server
wouldn't). Others will fail in full. We should supply documentation
explaining what needs to be done to `complete' an install in terms
of /etc and /var (generally just copying files from /pkg/usr/share/examples
or whatever that directory turns out to be). It may be possible to
automate this to some degree. The easiest way to do this might be
to add an option to pkg_add that would install only var and etc
files, copying them from /pkg/{usr/}share/examples/pkg_name/{var|etc}/*.

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