On Wed, 16 Dec 1998, Curt Sampson wrote:

: Ok. This, to my mind, blows requirement three, since you're now
: given no way to separate the stuff the package system installs in
: etc and var from the /etc and /var directories, but if you don't
: have a problem with this, I don't either.

I interpret that requirement as for `binaries' only.  I'd rather see all
stuff in the absolute /etc and /var.

: > People using the existing package system -- and more importantly, existing
: > binary pkgs -- have to do Nothing to use the new system; simply adding a
: > symlink at /usr/pkg (instead of letting pkg_add create the directory)
: > suffices to intermix binaries.  People who don't have to mix don't change a
: > thing.
: 
: Ok, I see. You just wanted backwards compatability.

Partly that, and ...

: > Um, `our' new system reads that the default is not to intermix binaries.
: 
: I don't agree with this (though my disagreement is not particularly
: strong); I think the novice is much better off with intermixed
: binaries. What advantage accrues to a non-developer from not mixing
: them?

... partly because it is the way it works already.

Novices already deal with software in /usr/local (c.f. FreeBSD); as of the
1.3.3-compiled pkgs, /usr/pkg/lib no longer needs to be in /etc/ld.so.conf
on a.out, eliminating the last major novice-problem with pkgs.  Personally,
I loathe the way that Linux mixes *everything*.  But for mixing stuff in,
there's always a place in INSTALL that a note about the symlink can be put.
(Remember that from a fresh install, /usr/pkg does not exist at all.)

: > Because neither our current system nor the distrib-lists -> pkg proposal in
: > the works have that fine of granularity such that you can pkg_delete
: > something installed with the system distribution.  So, you move the system
: > stuff out of the way so that your pkg installed stuff will not conflict.
: 
: I'd say we should add that granularity, then, if we can. I'll live
: if it doesn't happen, though, since I don't have time to do the
: work myself.

`Catch-22'.  No one else has the time, either.  8-)

: Here are my current thoughts on how to install /etc and /var files:
: 
: 1. The package, when compiled, always looks in /etc and /var for
: the files appropriate to those directories.
: 
: 2. Packages are set up to place `fresh' or `example' etc and var
: files in /usr/pkg/share/examples/<pkgname>/{etc|var}. Nothing is
: placed in /etc or /var.

Grumble.  `var' should not be there - what example are you making for a
volatile file?  :)

And without `var', why have `etc' in the path... just make it
share/examples/pkgname/file.conf.  (And see edit-v2, also:  I mention not
even having a pkgname subdir for uniquely named single config files.)

: 3. For every file in /usr/pkg/share/examples/<pkgname>/etc, pkg_add
: checks to see if the file exists in /etc. If not, it copies it
: there. If one is there, pkg_add prints a note to say that this file
: has possibly been upgraded, and should be checked. pkg_add does
: the same for var.
: 
: 4. pkg_add has an option which does just step 3 for installed
: packages. (This is how one installs the /etc and /var stuff on a
: machine that's sharing /usr/pkg with other machines.)
: 
: 5. pkg_delete, when run, does not remove /usr/pkg/share/examples/<pkgname>,
: but instead renames it to <pkgname>.old. This is so that one can
: diff the files after uninstalling one version and installing a new one.

If we make a @configfile pkg_add option, this becomes trivial.

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)