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

no, because it's not really valid.  i've had multiple compilers
installed on my netbsd boxes and using the right one is, as always,
a matter of choosing the right one either explicitly or via $PATH.
suggestions about using "gcc-new" should be ignored!

the netbsd build process does not use "gcc" but "cc" - or more
recently "$TOOLDIR/bin/$GNU_ARCH_PREFIX--gcc" or something, so
other compilers installed called "gcc" are not going to be used
by either the build process for userland or the kernel.
   
   > 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.

i don't see what moving software *now* buys us except to hurt our
users into updating their $PATH and having software no longer where
they expect it to be.  i don't see any "real" advantages, nothing
you have meantioned seems to be particularly compelling to me.


no /usr/contrib, please.


.mrg.