[ On Mon, January 11, 1999 at 02:52:08 (+0100), Soren S. Jorvang wrote: ]
> Subject: Re: Package paths: consensus?
>
> On Sun, Jan 10, 1999 at 12:32:56PM -0500, Greg A. Woods wrote:
> > 
> > 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.

Sorry.  Perhaps I'm not expressing my ideas clearly enough.

I thought it was abundantly clear that "A" was not sufficient to cover
everyone's needs, and I figure that between "B" and "C" the choice for
full orthogonality would be quite obvious.  I thought Curt's original
first proposal also made all these distinctions quite clear.

Obviously though it's taken a lot more discussion and debate to clarify
the implications of these options.

> I also think 'most people' (there it is again :-), very much do
> not like this "virtualization" of the filesystem layout.

I think this is very mich an issue of "virtualization".  The only option
is to make an arbitrary fixed decision that can never keep everyone
happy.  I agree with Curt's recent assessment under the "intermixed
vs. separate" thread, though I think the motivation for segregation
stems from long-term use of prorprietary binary-only Unix
implementations which did not have good pkg management tools.  Even when
interference with/by the vendor is not a motivation, segregation can be
used for other political purposes, such as showing how much effort the
local admin has put into making the system a comfortable and well
rounded environment.  I'm not quite so pessemistic as Curt about how
well non-NetBSD users can adapt to the idea of separate heirarchies.
I've seen both experienced and inexperienced users adapt to various
levels of segregation in various operating systems.  I've even got a
small group of clients still running SunOS-4 systems where I religiously
segregated everything non-native to SunOS.  I think the important thing
is that if segregation is the default then the default user environment
must work flawlessly (i.e. the PATH, INFOPATH, MANPATH, etc. must all be
set up properly all of the time, even in single-user-mode).

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

That's why I keep emphasizing that the "B" option (and "C") allow for
all other options with only two symlinks, whereas "A" would require a
forest of symlinks in /etc (and possibly in /var) to maintain
segregation.

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

I do not want SunOS-5's /opt either.  It is not a scalable solution,
even when its management is completely mechanized (as it is in SunOS-5).
The complexity is so great that one must understand it at the meta level
and trust that all the tools are doing all the right things -- manual
inspection and verification is nearly impossible.  Not to mention the
number of cycles wasted chasing one's tail through a maze of symlinks
for every file access.

> The point is that (host-specific) configuration and (less so) spool files
> aren't ordinary files package-wise.

Well, yes, and no.  It depends on your requirements and perceptions.
They are most definitely associated to some degree with their parent
package.  They do require storage private (or at least dedicated) to a
particular host in *some* circumstances.  Those circumstances are
relatively rare, but they're extremely important since how they are
handled will possibly make the decision as to whether or not a given
system can feasibly be used in those circumstances.

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

Indeed.  Even if one uses the PLIST itself to mechanically decide which
symlinks are necessary in /etc to move pkg files off to some other
location, I still don't think it's a scalable option.  An old VAX might
never get out of namei() et al!  ;-)

> On the other hand, I don't consider a pure /var important enough to warrant
> the /opt-like baroqeness of /var/pkg/foopkg/spool .

Note that "B" (or "C") may result in /pkg/var or /var/pkg or a symlink
of the same name.  The package name does not necessarily enter into
things.

Whether or not /var is important to segregation depends on the
application.  /var files are almost always private to a given machine,
but they may also be unique enough that some people will want to
segregate them based on wether they are system files or pkg files.

I personally would almost always integrate /var files even when I
segregate /etc files.  That decision may be irrational too -- I
generally think of stuff in /var as disposable, and I generally hope
that applications will create missing directories/files in /var on their
own (which reminds me -- I need to patch syslog!).  It also seems to
make sense in my -current development environment where I share packages
and /var (and effectively a mirror of /etc) between an operational
system partition and a test/backup system partition.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>