> On Thu, 2 Jan 2003 sobrado@string1.ciencias.uniovi.es wrote:
> 
> I think that proposals usually should be discussed first via a mailing
> list and then a PR submitted once discussed (even if not agreed).

Yes, I agreed.  And we are discussing about this matter in the
tech-userlevel mailing list.  I was not aware about the right way
to propose a change and I did a mistake, but it was fixed some
hours ago.  Now we are in a NetBSD mailing list.

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

No, but taking a look at the 4.4BSD/Lite2 source code will help.
My proposal is not moving ALL that software to /usr/contrib.

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

An excerpt from the tech-userlevel mailing list:

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

Is that a better example?

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

I am not speaking about optional software packages, but about the
software provided in the base system.  And there are real advantages
on moving *some* packages to /usr/contrib, as the Regents of the
University of California did in 1994 with 4.4BSD-Lite2.

> Already done via packages collection.

I am speaking about the base system, the ports system works just fine.

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

I do not agree.  We cannot compare BSD/OS's /usr/contrib (where are
packages that are provided in the base system) with NetBSD's /usr/pkg
(where optional software is added).  NetBSD has NOT something like
/usr/contrib.  Packages in the base system are not optional components
of the operating system.

> This is like /usr/pkg.

I do not agree.

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

No, it is not the same.  Packages in /usr/pkg are optional and a user
can decide if he wants (or not) those packages.  Packages in the base
system are NOT optional components, and problems with those packages
have not easy workaround (examples are the problems that SUNW has with
bzip2 in Solaris 8, and the FreeBSD Foundation has removing Perl from
the base system), instead of freezing older stable releases in /usr/contrib.
That was the point.

Cheers,
Igor.

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