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>