Subject: Re: Package paths: consensus?
To: NetBSD Packages Technical Discussion List <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 01/10/1999 12:32:56
[ On Sun, January 10, 1999 at 02:53:00 (+0100), Soren S. Jorvang wrote: ]
> Subject: Re: Package paths: consensus?
> FWIW, I think what most want(ed) is not so much A itself as 'not B'.
This makes absolutely no sense to me (though I'll go along with your
perception of their reasoning -- I just think they've all missed the
The "B" option, being the most flexible allows implementation of either
"A" or "C" with a maximum of two necessary symlinks.
On the other hand "A" is totally frozen and cannot be adapted (at least
not in a scalable manner) to any other form. "C" is somewhere in
IMNSHO people wanting "not B" are *not* reading the proposals. The key
point they seem to be missing is that these locations are where the
packages will look for the files, *NOT* where the files might actually
Choosing "A" leads to making it nearly impossible to segregate package
files from system files, and such a choice is in effect no different
than simply giving up /usr/pkg all together -- you may as well set
PREFIX=/usr and be done with it.
*I* am only aruging for "B" (or possibly "C) because I do see value in
segregation of third-party files. If I did not I would argue instead
for "A" *and* the total abolishment of /usr/pkg.
> I can think of several variations of A/C that make some sense.
> /etc/pkg/fooapp/* and /var
> /etc/fooapp and /var
These examples make sense for where the files actually exist, but *not*
for where the files are searched for by the software. "B" makes both of
> Also, like now some packages (e.g. ssh) may have special requirements
> that justify bending the rules.
SSH's requirements are no different conceptually than those of any other
package, or indeed of any software integrated into the system.
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>