[ On Sun, January 10, 1999 at 10:04:47 (-0800), I can teach you how to fish... wrote: ]
> Subject: RE: Default package installation: intermixed vs. separate
>
> Greg A. Woods sez:
> /*
>  * Isn't this all politics?  Is there any technical reason why installing
>  * packages into /usr is bad (especially if you keep in mind that the pkg
>  * system will include a database that lets the origin of every file be
>  * determined?
> 
> Yes.  Size and location.

But "size" is mostly about economics (which normally turns instantly
into a political arument if you think too hard about it) and location
*is* politics.

> I want my / and /usr to have BASE SYSTEM BINARIES in them, keeping them
> a _known size as determined at installation time_.
> 
> I want my /usr/local to contain NON-BASE SYSTEM BINARIES in it.  I can
> destroy my /usr/local, enlarge it and repopulate it with a minimum of
> grief.
> 
> The only place an /etc makes sense is under root.  Config files
> aren't likely to overrun root in any case.

Uh huh.  This all makes sense.  I don't really want to prevent these
distinctions.

> /var shouldn't be exported anyway.

Well, that depends -- I export it so that /var/spool/ftp can be shared,
but then /var/spool/ftp *really* belongs under /usr/share in that case,
just as WWW files do, but that's another debate.  People have also been
known to export /var/spool/news because sometimes sharing news over NFS
is more effective than shared access via NNTP, but again that's a
separate debate.

> If you WANT to integrate your system, well, fine and dandy, but
> I think the default should be (/etc, /var, ${LOCALBASE}).

Your preferred default unfortunately totally prevents anyone from going
one step further and totally segregating 3rd-party stuff from system
stuff, as several of us have said is paramount to.

The "B" option permits your behaviour *and* total segregation *and*
total integration, all with only *two* optional symlinks.

Using /etc/pkg, /var/pkg, and $LOCALBASE would also work just fine,
though seems to be lacking a certain amount of orthoganality that the
"B" option has.

> My question of elegance is:  is there any way we can do this without
> a stupid symlink?

Yes, but only by guaranteeing that all config files and run-time files
are separately and uniquely identified in the PLIST and that pkgsrc and
pkg_* tools provide mechanisms to separately locate them if desired.

The real question of elegance is:  do you need one or two symlinks, or
do you need M*N where M is the number of packages and N is the average
number of files in a package?  I vastly prefer options which support the
former and detest options which require the latter (remember SunOS-5
/opt?).  The former is trivial -- the later is not scalable.

> Should there be /etc/pkg.conf in which one could specify the locations,
> or are we talking binary packages, here?  [in which case I think I'll
> drop out of the discussion since I'm wont to compile my own stuff
> anyway.]

Some folks might like /etc/pkg.conf to default these things, though I
think symlinks work equally well -- they're just less easy to create an
audit trail from.  These things can be specified on the command-line for
pkg_* tools (and they could be in /etc/mk.conf for pkgsrc builds), but
using a more permanent form of configuration registration (either
symlinks or /etc/pkg.conf) leads the system to be less error prone.

>  * It could point at "/usr" to enable the "mixed" variation.  (Of course
>  * this latter idea suggests that without a feature to separately identify
>  * config and run-time files in PLIST one would also probably want to have
>  * /usr/pkg/etc and /usr/pkg/var symlinks.)
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> GAAAAAHHH! <smacks own head> [now, where's that brick with the words
> "BEAT HEAD HERE" chiseled into it...?]

I'm not sure if you're expressing revalation or frustration here....

(hopefully the former!  ;-)

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