[ On Wed, December 16, 1998 at 11:25:55 (-0800), Curt Sampson wrote: ]
> Subject: Re: Package Paths Proposal v2
>
> Neither of these two pieces of knowledge are common to *any* other
> form of Unix, and they'll hit new NetBSD users fairly early on with
> a bad experience. Experienced Unix users will eventually figure it
> out, but hate the way that NetBSD does things differently for no
> obvious advantage, new Unix users may give up in frustration because
> no book or Linux-using friend can help them.

Yup.  Most experience Unix users I know complain that /usr/local should
be the default prefix for all add-on packages.

Having a separate location for packages and local stuff isn't a "new
invention" though.  BSD/OS has had /usr/contrib/bin all along.

> > Personally, I loathe the way that Linux mixes *everything*.
> 
> Right. But you've not yet provided a good technical reason to make
> non-intermixed the default. What advantage does it give to someone
> who is neutral in the intermixing issue?

On my own systems, which are used primarily for software development and
testing, I didn't want to mix "local" stuff that I had installed
directly from source with "package" stuff that I had installed from
pkgsrc, mostly because I didn't want to futz with pkgsrc stuff -- just
install it in a completely isolated hierarchy (otherwise I would just
install directly from source and skip the "extra" pkg steps), but also
because I wanted to be able to have different "versions" of the same
things in /usr/local/bin and /usr/pkg/bin.

However for customer production systems I'm seriously considering just
integrating everything in with the system binaries.  I've yet to think
of any really good reason why I should create all the extra over-head
just to handle the possiblity that I might want to have two different
versions of the same thing installed simultaneously, esp. not on a
production system.  I think the same applies for 99% of all end users
who are not also software developers.

I.e. if the pkg system cannot accomodate both a completely separate
hierarchy, then it's of no use to me.  It doesn't also *have* to
accomodate a completely integrated heirarchy, but that would be much
more elegant....

> Without the dir, you may not know exactly which package that config
> file belongs to. Since we're going to be putting some stuff in
> directories, I think we should be consistent and do it with all
> stuff. That way you know exactly where everything is, rather than
> having to check to see if it's a single config file or several
> (which may differ even between program versions), you've got an
> easy way to find the config file without using pkg_add or digging
> around in PLISTs (saving a lot of effort on an automated /etc/* vs
> share/*/etc/* compare utility, and so on.

I think it's a given that if you want to find out what files belong to
which packages you must use the pkg_* tools.

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