Subject: Re: Package paths: consensus?
To: NetBSD Packages Technical Discussion List <firstname.lastname@example.org>
From: Soren S. Jorvang <email@example.com>
Date: 01/11/1999 02:52:08
On Sun, Jan 10, 1999 at 12:32:56PM -0500, Greg A. Woods wrote:
> [ 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
Erm, I want 'not B' and I have read everything in this thread pretty
> 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
I also think 'most people' (there it is again :-), very much do
not like this "virtualization" of the filesystem layout.
I and probably others instantly think 'symlink tree madness' whenever
_symlinks by design_ comes up. This may be a bit of an .. emotional
argument, but I really do think they complicate the system in a
Most of us have all seen the evil they have done in many commercial
> 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 too see value in segregation.
The point is that (host-specific) configuration and (less so) spool files
aren't ordinary files package-wise.
The downside I see to A is that it clutters /etc and makes the operations
examplified by 'rm -rf /usr/pkg' (which I consider far from silly)
On the other hand, I don't consider a pure /var important enough to warrant
the /opt-like baroqeness of /var/pkg/foopkg/spool .
Thus the various compromises/variations I suggested.