Subject: Re: Package Paths Proposal v2
To: None <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 12/16/1998 15:20:16
[ 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
> 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 <email@example.com> <robohack!woods>
Planix, Inc. <firstname.lastname@example.org>; Secrets of the Weird <email@example.com>