Subject: Re: Package paths: consensus?
To: NetBSD Packages Technical Discussion List <>
From: Greg A. Woods <>
List: tech-pkg
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.
> Examples.
> /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
them possible....
> 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      <>      <robohack!woods>
Planix, Inc. <>; Secrets of the Weird <>