Date: Fri, 5 Jul 2002 04:10:05 -0700 (PDT) From: Igor Sobrado <sobrado@string1.ciencias.uniovi.es> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/40222: [directory hierarchy] /usr/contrib Message-ID: <200207051110.g65BA55R096345@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/40222; it has been noted by GNATS.
From: Igor Sobrado <sobrado@string1.ciencias.uniovi.es>
To: "Sergey N. Voronkov" <serg@tmn.ru>
Cc: Igor Sobrado <sobrado@acm.org>, freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/40222: [directory hierarchy] /usr/contrib
Date: Fri, 05 Jul 2002 13:08:20 +0200
> On Fri, Jul 05, 2002 at 02:07:54AM -0700, Igor Sobrado wrote:
> > It should be nice to have a /usr/contrib in FreeBSD, in the same way
> > as it is supported in BSD/OS or HP-UX. /usr/contrib can be used to
> > support optional software useful for the operating system but that
> > it is not a part of it (bzip2, gzip, zip, perl, Tcl/Tk, expect, nmh,
> > ...).
>
> bzip2, gzip - externaly maintained parts of the base system
In other words... contributed software.
> perl - part of the base system 4.X
Ok.
> man hier (see /usr/local).
I am aware of the BSD directories hierarchy (where /usr/local is used
to store optional software -now-, or locally developed software -some years
ago-). I am aware of the SVR4.x directory hierarchy too (where /opt
is used to store optional software packages following a directory hierarchy
in the form /opt/<vendor>/{bin, lib, sbin, ...}
> Depends of what do you want to get from changing release version of external
> software. It is a known huge number of features and errors, that makes the use
> of new versions of such utilities a very big problem without breaking entry
> system functionality :-(.
>
> As an example, take a look onto gcc version differences and changes in
> CURRENT branch.
>
Agreed!
I was thinking on other problem that I do not want to see on *BSD:
About two years ago Sun released Solaris 8. That new release of Solaris
provided a lot of new software (not only Gnu stuff but also software from
other sources too.)
Sun Microsystems decided to install that software directly in /usr/bin.
They hard-coded the path to those interpreters (perl) and binaries (bzip2)
into other binaries and scripts.
Now users are not able to change those packages without breaking some system
dependencies and changing the operating system behaviour.
Why a user must change those binaries? Well, bzip2 release provided with
Solaris has a race condition that *sometimes* erases not only the output
of that compression tool but ALSO the file that is being compressed.
Other tools has the well-known zlib problem.
The standard Perl does not works for all users (some of us wants to build
the MICE video-conferencing tools from source code too.) Etc...
Hard-coding the path to that contributed software in /usr/contrib will allow
users to install new (perhaps customized is the right word) releases of that
software without changing the operating system behaviour.
Technical staff will be sure that they will know the behaviour of the
operating system (if the users does not change the contents of /usr/contrib
of course!). In other words, the operating system behaviour (even if it
is wrong) will be under control.
That is the reason I propose to install that contributed software in
/usr/contrib.
This directory is common on other BSD operating systems, like BSD/OS
(BSDi, and now Wind River). It has been adopted too by HP-UX since,
at least, 1995.
Cheers!
Igor.
--
Igor Sobrado, UK34436 - sobrado@acm.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207051110.g65BA55R096345>