From nobody@FreeBSD.org  Fri Jul  5 02:07:54 2002
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 6D6DB37B400
	for <freebsd-gnats-submit@FreeBSD.org>; Fri,  5 Jul 2002 02:07:54 -0700 (PDT)
Received: from www.freebsd.org (www.FreeBSD.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 312DD43E09
	for <freebsd-gnats-submit@FreeBSD.org>; Fri,  5 Jul 2002 02:07:54 -0700 (PDT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.12.4/8.12.4) with ESMTP id g6597sOT097768
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 5 Jul 2002 02:07:54 -0700 (PDT)
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.12.4/8.12.4/Submit) id g6597sKs097767;
	Fri, 5 Jul 2002 02:07:54 -0700 (PDT)
Message-Id: <200207050907.g6597sKs097767@www.freebsd.org>
Date: Fri, 5 Jul 2002 02:07:54 -0700 (PDT)
From: Igor Sobrado <sobrado@acm.org>
To: freebsd-gnats-submit@FreeBSD.org
Subject: [directory hierarchy] /usr/contrib
X-Send-Pr-Version: www-1.0

>Number:         40222
>Category:       bin
>Synopsis:       [directory hierarchy] /usr/contrib
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jul 05 02:10:02 PDT 2002
>Closed-Date:    Fri Jul 05 12:16:10 PDT 2002
>Last-Modified:  Fri Jul 05 12:16:10 PDT 2002
>Originator:     Igor Sobrado
>Release:        4.6-RELEASE
>Organization:
University of Oviedo
>Environment:
FreeBSD localhost 4.6-RELEASE FreeBSD 4.6-RELEASE #2: Thu Jul  4 09:59:34 CEST 2002     sobrado@localhost:/usr/src/sys/compile/HP-OB4100  i386
>Description:
      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, ...).

      Somtimes that software is useful for the operating system (administrative Perl scripts that can be a part of the operating system in the future.)  Those scripts can be the path to the interpreter hard-coded to /usr/contrib/bin.  If a user needs a modified release of that software (like a different release of Tcl/Tk) it can add it safety without breaking the operating system by replacing the fully functional releases.  We can think on problems that happens at present, for example with the binutils chain.
>How-To-Repeat:
      It is only an improvement.  And it does not violates POLA.
>Fix:
      It is only a reasonable OS improvement.
>Release-Note:
>Audit-Trail:

From: "Sergey N. Voronkov" <serg@tmn.ru>
To: Igor Sobrado <sobrado@acm.org>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/40222: [directory hierarchy] /usr/contrib
Date: Fri, 5 Jul 2002 15:24:25 +0600

 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
 
 perl - part of the base system 4.X
 
 man hier (see /usr/local).
 
 >       Somtimes that software is useful for the operating system
 >       (administrative Perl scripts that can be a part of the operating
 >       system in the future.) Those scripts can be the path to the
 >       interpreter hard-coded to /usr/contrib/bin.  If a user needs a
 >       modified release of that software (like a different release of
 >       Tcl/Tk) it can add it safety without breaking the operating system
 >       by replacing the fully functional releases.  We can think on
 >       problems that happens at present, for example with the binutils
 >       chain.
 
 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.
 
 Serg N. Voronkov,
 Sibitex JSC,
 Tyumen, Russia.

From: "Simon 'corecode' Schubert" <corecode@corecode.ath.cx>
To: Igor Sobrado <sobrado@acm.org>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/40222: [directory hierarchy] /usr/contrib
Date: Fri, 5 Jul 2002 12:38:58 +0200

 --=.bc'jisfccRHt7/
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: 7bit
 
 On Fri, 5 Jul 2002 02:07:54 -0700 (PDT) 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, ...).
 
 apart from gzip and bzip2 (and for 4-S perl) being part of the base
 system, you may want to try /usr/local. this is where ports get
 installed and it's the perfectly right place to add your own binaries or
 files.
 
 cheers
   simon
 
 -- 
 /"\   http://corecode.ath.cx/#donate
 \ /
  \     ASCII Ribbon Campaign
 / \  Against HTML Mail and News
 
 --=.bc'jisfccRHt7/
 Content-Type: application/pgp-signature
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.0.7 (FreeBSD)
 
 iD8DBQE9JXdFr5S+dk6z85oRAopGAJ0SyH4gIcDnCqDXGeJ0ZH+eHJgE9ACguJYY
 hCHRqE0cGlajrJxWI5GYZEE=
 =M+0M
 -----END PGP SIGNATURE-----
 
 --=.bc'jisfccRHt7/--
 

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
 
 

From: Igor Sobrado <sobrado@string1.ciencias.uniovi.es>
To: Simon 'corecode' Schubert <corecode@corecode.ath.cx>
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:15:49 +0200

 > apart from gzip and bzip2 (and for 4-S perl) being part of the base
 > system, you may want to try /usr/local. this is where ports get
 > installed and it's the perfectly right place to add your own binaries or
 > files.
 
 Simon,
 
 I am thinking about avoiding problems with FreeBSD in the future.  See what
 happened to Solaris  (I sent a description of this problem, that I hope will
 arrive without problems to the freebsd-gnats-submit mailing list.)
 
 It is possible changing those binaries.  But it is not a good idea having
 two copies (with a different behavior) of some binary in system
 directories that are provided in each PATH environment variable.  Different
 users will see different behaviors as a consequence of having those paths
 in another order!
 
 What about system behaviour?  Changing those binaries in /usr/bin (a very
 bad answer to the problem) will change the operating system behavior.
 It will be very hard to diagnose a problem on a remote BSD installation.
 
 Cheers!
 Igor.
 
 -- 
 Igor Sobrado, UK34436 - sobrado@acm.org
 
 

From: "Alexey V. Neyman" <alex.neyman@auriga.ru>
To: bug-followup@freebsd.org
Cc:  
Subject: Fwd: Re: bin/40222: [directory hierarchy] /usr/contrib
Date: Fri, 5 Jul 2002 15:57:40 +0400

 I believe the submitter meant this description.
 
 ----------  Forwarded Message  ----------
 Subject: Re: bin/40222: [directory hierarchy] /usr/contrib
 Date: Fri, 05 Jul 2002 12:54:16 +0200
 From: Igor Sobrado <sobrado@string1.ciencias.uniovi.es>
 To: "Alexey V. Neyman" <alex.neyman@auriga.ru>
 
 > Have you noticed the /usr/local directory in the default
 > installation? It serves almost the same purpose that you described.
 
 Yes, I am aware of /usr/local (BSD operating systems) and /opt (SVR4.x
 operating systems) too.  The problem I am trying to avoid is another
  one:
 
 About two years ago, Sun Microsystems released Solaris 8.  That OS
  release provided a lot of Gnu stuff (and other optional software
  too...) in /usr/bin.
 
 Some of the new add-ons are broken (for example, bzip2 has a race
  condition that sometimes deletes not only the output of that command
  but also the file that is being compressed.)  Perl, and Tcl/Tk, does
  not works for all users (it does not work when building the MICE
  related video-conferencing software.)  ...and there is the well known
  zlib problem too.
 
 The problem is that users cannot change that software without breaking
  the operating system (there are a lot of new administrative scripts
  that depends on those versions and that are hard-coded to /usr/bin/*).
   Changing that software makes the system behaviour unpredictable for
  service staff.
 
 Adding that software to /usr/contrib/[s]bin will allow a user to add a
  new release of that software without changing the operating system
  behaviour.
 
 IMHO, it is a good improvement.  And there is some people in the Sun's
 technical staff that agrees with me.
 
 Igor.
 
 --
 Igor Sobrado, UK34436 - sobrado@acm.org
 
 -------------------------------------------------------
 
 -- 
 ,----------------------------------,
 | L'enfer ou tu iras, j'irai aussi | Alexey V. Neyman
 | Et ce sera mon paradis...        | mailto:alex.neyman@auriga.ru
 `--------------------( Frollo )----'
State-Changed-From-To: open->closed 
State-Changed-By: billf 
State-Changed-When: Fri Jul 5 11:55:31 PDT 2002 
State-Changed-Why:  
as it stands now, we install all software in the base system 
into the same hierarchy. the PR system is not really the place 
to change that. freebsd-arch@ might be a better place, though 
i don't know how much luck you'll have in convincing people 
to make such a drastic change. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=40222 
>Unformatted:
