On Wed, 16 Dec 1998, Curt Sampson wrote:

: Right. For those that are already familiar with it. If we grow more
: or less exponentially, which I think is a reasonable assumption at
: this point, a change now would, a year from now, affect only a
: small proportion of NetBSD users anyway.

Before I say anything else, I'd like you to propose this as a _separate_
proposal, so that others can see and talk about it.  I have a nagging
feeling that it'll be shot out of the sky faster than a MiG in the wrong
airspace.

: 1. Makefiles and build systems need to be updated to add
: -I/usr/pkg/include -L/usr/pkg/lib when compiling programs that use
: include files and libraries installed as packages.

Not much different form /usr/local.

: 2. /usr/pkg/bin must be added to the default path to have a `usable'
: system in many people's eyes.

So we should probably add it to _PATH_DEFAULT and to
`dot.{profile,cshrc,login}' afor the root uid and the skeletons.

And DOCUMENT it.

This isn't, in my eyes, any compelling reason to mix third party software in
with the stuff in /usr/bin.  Yes, we want to spread NetBSD around to more
users, but we don't want to make the system a mess (and yes, the whole /etc
symlinks thing was a mess, in retrospect) in order to do it.  It's not
necessary.

: Right. But you've not yet provided a good technical reason to make
: non-intermixed the default. What advantage does it give to someone
: who is neutral in the intermixing issue?

The ability to find out what is third party and what is not without
troweling through /var/db/pkg.  An easy way to know what will be upgraded,
and what _won't_, when you upgrade NetBSD as opposed to third party pkgs.
Both of these reasons have approximately the same marginal value as the
-I/-L and $PATH argument.

: > But for mixing stuff in,
: > there's always a place in INSTALL that a note about the symlink can be put.
: > (Remember that from a fresh install, /usr/pkg does not exist at all.)
: 
: That's good for experienced users who read all the install notes;
: that's not the audience I'm aiming at.

Frankly, I don't give a damn about new users to UN*X that won't even read
the README file that tells them how to install the stuff.  Talk about
`technical support nightmare'.  All the newer users I know of -- and I know
quite a few -- at least read that much.

At what audience are you aiming?

I've said my piece about this bit, and I'm backing out of the `default mode
of operation' debate for a while at least.  I'll let everyone else have a
say.

: > Grumble.  `var' should not be there - what example are you making for a
: > volatile file?  :)
: 
: Empty scorefiles. Don't some programs need them present, and not
: know how to create them?

If they do, then it should be created by a program, not by a human, and the
starter files should go in libdata.  (Binary scorefiles in particular are
typically host-byte-order dependent.)

: Also for directory creation; if
: /usr/pkg/share/examples/<pkgname>/var/games/somegame is a directory,
: pkg_add should create a /var/games/somegame directory if it doesn't
: exist. In fact, we may need to add an mtree to this to get permissions
: right.

Yecch.  @exec install -d ... should be Just Fine, and this could be
abstracted with a @-command to make it `usable across shares'.

: > And without `var', why have `etc' in the path... just make it
: > share/examples/pkgname/file.conf.  (And see edit-v2, also:  I mention not
: > even having a pkgname subdir for uniquely named single config files.)
: 
: Because then we'd end up with the entire set of IPF examples being
: copied over to /etc on install, for example.

Uniquely named SINGLE config files.

: Without the dir, you may not know exactly which package that config
: file belongs to. Since we're going to be putting some stuff in
: directories, I think we should be consistent and do it with all
: stuff.

This does sound laudable enough, though.  Of course, something like
ssleay.cnf should be pretty obvious as to what pkg it goes to.  Changing the
emphasis on the above:  UNIQUELY named single config files.

That said, for this point I don't care much either way anymore.

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)