Subject: re: standards/19639: Proposal: Reimplementing the /usr/contrib directory hierarchy
To: Igor Sobrado <email@example.com>
From: matthew green <firstname.lastname@example.org>
Date: 01/03/2003 19:40:46
> 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.