On Wed, 16 Dec 1998, Todd Vierling wrote:

> : I don't agree with this (though my disagreement is not particularly
> : strong); I think the novice is much better off with intermixed
> : binaries. What advantage accrues to a non-developer from not mixing
> : them?
> 
> ... partly because it is the way it works already.

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.

> Novices already deal with software in /usr/local (c.f. FreeBSD); as of the
> 1.3.3-compiled pkgs, /usr/pkg/lib no longer needs to be in /etc/ld.so.conf
> on a.out, eliminating the last major novice-problem with pkgs.

That does not eliminate the last major novice-problem. (By `novice,'
anyone new to NetBSD, whether they've never touched Unix before or
are extremely experienced sysadmins on several varieties of Unix.
We still have the following:

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.

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

Neither of these two pieces of knowledge are common to *any* other
form of Unix, and they'll hit new NetBSD users fairly early on with
a bad experience. Experienced Unix users will eventually figure it
out, but hate the way that NetBSD does things differently for no
obvious advantage, new Unix users may give up in frustration because
no book or Linux-using friend can help them.

I don't think backward compatability for something that's relatively
new anyway (something that didn't exist in the previous major
release!) and that affects relatively few, easy to contact people
is worth this price. And note that this won't affect anyone except
people doing fresh installs after 1.3.3, anyway; upgrades will
continue to work as they are now because /usr/pkg will be a directory
rather than a link. So there's already a fair degree of backward
compatability there already.

> Personally, I loathe the way that Linux mixes *everything*.

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?

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

> : Here are my current thoughts on how to install /etc and /var files:
> : 
> : 1. The package, when compiled, always looks in /etc and /var for
> : the files appropriate to those directories.
> : 
> : 2. Packages are set up to place `fresh' or `example' etc and var
> : files in /usr/pkg/share/examples/<pkgname>/{etc|var}. Nothing is
> : placed in /etc or /var.
> 
> 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? 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.

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

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. That way you know exactly where everything is, rather than
having to check to see if it's a single config file or several
(which may differ even between program versions), you've got an
easy way to find the config file without using pkg_add or digging
around in PLISTs (saving a lot of effort on an automated /etc/* vs
share/*/etc/* compare utility, and so on.

In short, given the choice between more consistent and less
consistent, I'll go for the more consistent option.

> If we make a @configfile pkg_add option, this becomes trivial.

Sure.

cjs
--
Curt Sampson  <cjs@cynic.net>   604 801 5335   De gustibus, aut bene aut nihil.
The most widely ported operating system in the world: http://www.netbsd.org