Subject: Re: Package paths: consensus?
To: NetBSD Packages Technical Discussion List <tech-pkg@netbsd.org>
From: Soren S. Jorvang <soren@t.dk>
List: tech-pkg
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
> point).
> 
> 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
> between.
> 
> 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
carefully.

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

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
not-so-good way.

Most of us have all seen the evil they have done in many commercial
Unicen.

> 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)
non-trivial.

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.


-- 
Soren