[ On Wed, December 16, 1998 at 13:01:29 (-0800), Curt Sampson wrote: ]
> Subject: Re: Package Paths Proposal v2
>
> There's no way to switch these at run time with many packages,
> anyway, because the paths are compiled directly into the binaries.
Oh, I fully realize that. Fixing this problem is the *next* step! ;-)
> Your choices are basically the following:
>
> /etc for config files
> /var for spool
> /usr/pkg/{bin,sbin,share,etc.} for everything else
>
> which means that /etc and /var can't change, or
>
> /pkg/etc for config files
> /pkg/var for spool
> /pkg/usr/{bin,sbin,share,etc.} for everything else
>
> which means that they can.
(I really do like that second option best.... ;-)
> With the former proposal you *always* know that *all* your config
> files are in /etc. This is a good thing.
Even if some folks think having all config files in /etc is a good
thing, it doesn't follow that everyone does, nor does it follow that the
pkg system should force everyone to live that way.
> With the latter, you can get the same result either with
>
> /pkg -> /
>
> or with
>
> /pkg -> (whatever)
> /pkg/etc -> /etc
> /pkg/var -> /var
Exactly. This is good. This is ever so much easier and more flexible
with the /pkg option (i.e. the one shown second above ;-).
> > > 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.
>
> I didn't know that pkg_add had an upgrade option now; that's why
> I didn't include this.
Well, I'm not so sure how/if/why it works, but it seems that for some
packages, at least those you install from pkgsrc and which only register
themselves with pkg_add, you can indeed just install newer versions of a
package on top of older versions. I don't know if you're supposed to be
able to do this, or if it really works properly, but it seems like a
good thing that it does work this way.
> I consider /etc to be sacred. Programs should be *extremely*
> conservative about changing or deleting files in there.
I know what you mean, but if you're going to be deleting the binaries
then either you should delete the related config files, or at least
rename them to something that shows they are no longer used or active so
that someone doesn't come along later and get confused by their presense.
There'll always be conflicts, such as where one config file might be
used by two separate packages, but such things should be dealt with on a
case-by-case basis.
Somewhere along the line some trust has to be granted. If you don't
trust the pkgtools to play with your config files then why do you trust
them to play with your binaries? Trust of course is earned too, so
we've got to show that these tools are well designed and carefully
tested and worthy of the trust administrators must have in them.
--
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>