Hi!

I published a PR about this matter today (standards/19639).  Julio Merino
observed that this proporsal should be sent to this mailing list first,
for a previous discussion of this idea by the NetBSD developers.  Sorry
for that mistake.  I will appreciate any comment/suggestion about this
proposal.  This is the PR:


Proposal:  Reimplementing the /usr/contrib directory hierarchy

The /usr/contrib directory hierarchy was part of the standard 4.4BSD/Lite
and 4.4BSD/Lite2 filesystem layout.  It was removed from the free BSD
operating systems (FreeBSD, NetBSD, and OpenBSD), but it is available in
most commercial releases yet (like BSD/OS and HP-UX).  I will outline the
rationale behind this proposal.  I hope I will not fail when trying to
show the big picture.

1. It is useful to differentiate between software that is under the
   control of the NetBSD Foundation, and other software packages.

   Software that is not being maintained by the NetBSD Foundation
   can be moved to /usr/contrib.  Some examples are gzip, bzip2,
   rcs, cvs, and so on.

2. It allows the NetBSD maintainers to reduce the risks derived from
   running software that is not under the NetBSD Foundation control.

   There are a lot of examples showing those risks.  Even if some of
   those risks will never happen, other are real threats that must
   be considered.

   An example of the former is the implementation of bzip2 provided
   by Sun Microsystems (SUNW) in Solaris 8.  They ported an old
   release (0.9.x) of bzip2 to Solaris.  It is a mostly working
   version of that good compression tool, but it has a race condition
   (only observed in the Solaris operating system) that sometimes
   removes both the compressed file and the original file when
   compression process in interrupted.  They will not provide an
   updated bzip2 release through the patch system (either as a public
   patch or as a private patch) and it is a required component, that
   cannot be removed from the system without breaking key components
   like the patching subsystem itself.

   An example of the latter has been recently observed in FreeBSD.
   Perl was a required component of FreeBSD (up to release 4.7 and,
   soon, 4.8).  Perl is not under the control of the FreeBSD
   developers.  Each stable release doubles the size of the previous
   stable version, making it too big (currently over 40MB).

   The FreeBSD developers decided removing it from the base system
   for FreeBSD 5.x.  Removing that package from the FreeBSD operating
   system was not easy, they changed important areas in the kernel
   to allow building a new kernel without requiring Perl.

   Obviously, providing an older stable release was not the answer
   to most users, that want to run the latest stable releases.
   Freezing an older release in /usr was the wrong thing to do.
   But that older, small, and stable release can be provided in
   /usr/contrib/{bin,etc,lib,...}, allowing users to install and
   run newer releases without conflicts (/usr/contrib/bin can be
   removed from the user's path without breaking the operating
   system functionality).

3. It allows the NetBSD Foundation to recover the nice design
   provided by 4.4BSD/Lite and 4.4BSD/Lite2 releases.

   It helps classifying software in two groups: packages under the
   control of the NetBSD Foundation, and packages under the control
   of third parties.

   It allows a user to decide what version of a given software wants
   to run.  Some packages are under a strong evolution, changing
   frequently in incompatible ways between releases.  It is against
   the design of the BSD operating systems.  A user can decide the
   features he wants on some packages that support a lot of extensions
   (I am running modified releases of Perl, Tcl/Tk with OO-features,
   InfoZIP compression tools with a lot of enhancements, and so on.)

   Software that is not under the control of the NetBSD Foundation
   can change in an incompatible way, or can add a lot of those
   features that can be important for some user groups.

4. It is followed by a lot of developers.

   BSD/OS and HP-UX currently offer a /usr/contrib directory.
   Operating systems that do not have an /usr/contrib directory
   hierarchy run on a lot of problems (FreeBSD and Solaris had
   those problems in the last years.)

5. It is a clean design.

   It is easy to implement without breaking the operating system
   (except shell scripts with hardcoded paths, that should be fixed
   to be more flexible.)  I think that there are not hardcoded
   paths to those binaries in the NetBSD operating system.

/usr/contrib layout

The /usr/contrib directory has a well-known set of packages on all
the operating systems that provide this hierarchy.  It can be the
directory where some NetBSD packages reside (gzip, bzip2, rcs, cvs,
and so on).  In most systems, it serves Perl, Tcl/Tk, Python, and
other shell script interpreters.  It is the home directory of nmh too.
Its layout is:

  /usr/contrib/bin
  /usr/contrib/etc
  /usr/contrib/lib
  /usr/contrib/sbin
  [...]
  /usr/contrib/nmh/bin
  /usr/contrib/nmh/lib
  [...]

Exceptions to this rule.

Some packages that ARE NOT under the control of the NetBSD Foundation
should stay in /usr.  Most important examples are GCC (gcc, g++),
GNU roff, and others.  Common sense shows the packages that can be
moved to /usr/contrib, but looking at the 4.4BSD/Lite filesystem
hierarchy will clearly show how to proceed.

/usr/contrib is the place where compression tools (except compress),
shell script interpreters, and nmh reside.

Thanks for you attention,
Igor.

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