On Thu, 2 Jan 2003 sobrado@string1.ciencias.uniovi.es wrote:

> >Synopsis:       Proposal:  Reimplementing the /usr/contrib directory hierarchy

I think that proposals usually should be discussed first via a mailing
list and then a PR submitted once discussed (even if not agreed).

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

Some software is partially maintained specifically by NetBSD. (For
example, our cvs software is patched for improved error handling and
better error messages.)

So is your suggestion to place all software included in "base" sets that
are mostly from outside projects, like bind, dhcp, ipf, tcpdump, et cetera
in /usr/contrib?

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

I am not sure I understand how your examples apply to NetBSD.

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

NetBSD already has this. Third-party software is mostly in the packages
collection. See hier(7):

     /usr/      contains the majority of the system utilities and files
...
                pkg/      packages maintained by groups other than the NetBSD
                          Project.

                          bin/      contributed binaries
                          sbin/     contributed system utilities
                          include/  contributed include files
                          libexec/  contributed daemons
                          libdata/  contributed data files

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

Already done via packages collection.

>    BSD/OS and HP-UX currently offer a /usr/contrib directory.

BSD/OS's /usr/contrib is like NetBSD's /usr/pkg -- except NetBSD's is
better because the files and packages (and dependencies, et cetera) are
recorded.

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

This is like /usr/pkg.

> Its layout is:
>
>   /usr/contrib/bin
>   /usr/contrib/etc
>   /usr/contrib/lib
>   /usr/contrib/sbin

This is like /usr/pkg/{bin,etc,lib,sbin}

>   [...]
>   /usr/contrib/nmh/bin
>   /usr/contrib/nmh/lib

This is a litle like pkgsrc using Package Views
(/usr/pkg/packages/$PKGNAME/).

Using regular pkgsrc, nmh files are installed to /usr/pkg/{bin,etc,man}
and /usr/pkg/libexec/nmh/, for example.

I think /usr/pkg is basically what you are looking for. When using pkgsrc,
you can define your LOCALBASE as /usr/contrib. See packages(7) manual
page.

   Jeremy C. Reed
   http://bsd.reedmedia.net/