> i can't see how any of those (except for the ones i don't use :) would
> be better served by putting them in /usr/contrib.  the only result i
> can see is massive confusion and resentment.  anyone who wants to use
> them will be happier finding them in /usr/bin, and anyone who wants to
> know which tools are from whom can easily look in the source tree.  if
> your intent is merely to separate netbsd controlled material from
> non-netbsd controlled material, then in order for it to have an
> effect, it must be a steadfast rule with no exceptions.  i'd be
> opposed to moving lots of stuff.  i think it (whichever program we
> decide to talk about) makes much more sense living where it already
> is.

Some movements happened in the past:

  - named homedir has been moved from /var/named to /var/chroot/named
  - MPC6xx files (powerpc) were moved to their own directory
  - setkey(8), and sysctl(8) were moved from /usr/sbin to /sbin

and even more complex ones:

  - dlopen(3), dlclose(3), dlsym(3), and dlerror(3) were moved to libc.

All those changes were good and I do not remember complains about it.

I do not intend to separate NetBSD controlled software from non-NetBSD
material.  That is one of the advantages, but not the main goal.  It is
much more important to me avoiding mistakes that happened in the past (for
example to Solaris and FreeBSD).

/usr/contrib allows maintainers to minimize the impact of running
software not controlled by the NetBSD Foundation.  That software can
change in an incompatible way.  I think that the key is that it is
mostly software that currently is in strong evolution.

On the other hand, /usr/contrib is clean and elegant.  This directory
layout was available in the 4.4BSD/Lite and 4.4BSD/Lite2 releases,
that is not a new feature but a part of 4.4BSD, and it is currently
being used by some of the most important Unices (for example BSD/OS,
and HP-UX).

Briefly, /usr/contrib can make the directory layout of NetBSD more clean,
and, at same time, it will provide a greater robustness of NetBSD protecting
it against unexpected changes.  It will allow, for example, to provide
frozen utilities with the operating system without preventing users to
add their own improved releases of that software.

In other words, /usr/contrib directory can be in the default user's PATH
environment variable (minimizing this way users confusion), but allowing
users that do not want to use that third-parties software to remove
/usr/contrib from their PATHs.

IMHO, what looks really confusing to me is installing customized versions
of that software in /usr/local.  In this case, the operating system
behaviour will depend on what directory is found first, and it will be
worst that providing those packages in another directory.

Most important points are that:

  - /usr/contrib was standard, it was a part of the 4.4BSD/Lite
    directory layout, and it is currently being used in some OSes.

  - Software has been changed (most times between /usr/sbin and /sbin)
    in the past without receiving users complains on this matter.

> >/usr/contrib is the place where compression tools (except compress),
> >shell script interpreters, and nmh reside.
> 
> it seems to me that there's not really that much that we could
> reasonably put there.

There are not *a lot* of things to put on that directory.  Only some
packages.  It is not as big change as it appears, but it can, IMHO,
greatly improve the NetBSD directory layout.

Let me publish the list of software provided in two of those operating
systems:

  - 4.4BSD/Lite2, the original version released by the Regents of the
    University of California in 1994:

      - MH-6.8 in /usr/contrib/mh-6.8
          (currently nmh in /usr/contrib/nmh-1.0.4 looks more reasonable)
      - kermit-5A, perl-4.036, rcs, flex-2.5.2, gzip-1.2.4, X11R5 stuff, ...

        (it should be even possible installing software like flex, and gcc
        in /usr/contrib and make a link to it from /usr/bin...).  Let me
        return to this point soon.

  - HP-UX B.11.00 D

      - gzip, perl, traceroute, X11R6, ...


Please, do not discard that proposal so fast!

There is a lot of possibilities provided by this small change that need
to be considered carefully.

Let me give another example: some users complain in the newsgroups about
problems building the NetBSD kernel.  Sometimes they have changed the GCC
release provided with NetBSD with an updated one.  We run into a problem:
NetBSD users want the most recent stable releases of gcc and g++,
but those releases are not automatically incorporated to NetBSD because
those releases need to be *carefully* tested building not only the kernel
but also the entire system.  NetBSD provides gcc with "cc" as an alias (link)
to it.  I read in a lot of posts that "those users should install new
compilers in /usr/local, renaming the binaries to something like "gcc-new".

IMHO, it is a bad workaround.  Suppose now that gcc is installed in
/usr/contrib, and that the Makefiles define 'CC = /usr/contrib/bin/gcc'
(yes, a hardcoded path to the approved gcc release).  In this case, those
users will be able to install the most recent gcc releases on their
workstations and servers without breaking the system building process.

Two ways to serve the old gcc to those users that want it as default
compiler: either providing /usr/contrib/bin in the PATH, or setting
up links to /usr/contrib/bin/gcc at /usr/bin/[g]cc.

IMHO, less complains from users!  Now, their are able to run the latest
stable releases of gcc and g++, and the operating system will continue
using fully-tested older stable releases of gcc, for critical tasks
like building a new kernel or an entire world.

Igor.

-- 
Igor Sobrado, UK34436 - sobrado@acm.org