Subject: /opt vs. /usr/local

From: "L. Todd Masco" <[email-masked]>

Err... perhaps I can shed some light here, having lived in many OS worlds.

/usr/local/* has indeed been the standard for the BSD world; /opt/* has
 been standard for the SVR4 world.

In the /opt/* paradigm, it's not unusual to have users have long paths,
 including all the packages they like and excluding ones they don't.  For
 example, if you don't like the gnu suite, just don't put /opt/gnu in
 your path.

Frankly, having run systems (as the only Sys Admin on networks of 10-20
 machines), I like the /opt/* marginally better for networked machines
 sharing file systems (via NFS, AFS, whatever), but /usr/local/* for
 a personal standalone on my desk.

(It's much like /etc/rc.local (BSD) <-> /etc/rc.{init,0-6} (SVR4) style
 startups: the SVR4 are big and confusing at first, but in the long run
 are much easier to maintain.   I'd see this be fixed in NetBSD than
 the /opt <-> /usr/local thing, but that might be a religious war.)

In any case, it really doesn't matter which is settled on: let's just
 settle on one and stick to it.
--
L. Todd Masco  | "Which part of 'shall not be infringed' didn't
[email-masked]  |   you understand?"

---

From: David Jones <[email-masked]>

>  example, if you don't like the gnu suite, just don't put /opt/gnu in

One thing I do for programs residing in their own dirs: I have a script for
each package I want to run in ~/bin.  Each script sets the proper environment
variables, adds the binary to my PATH, then runs it.  When the script exits,
my environment returns to normal.  Advantages: nothing in my PATH except
~/bin and the "system" directories, and nothing app-specific in my
environment.

Note that this is something users can do on a per-user basis, without permission
from the sysadmin.

>  settle on one and stick to it.

We should settle on the NetBSD standard, whatever that is.  The idea of
NetBSD is that you can compile a package for it (on any NetBSD port) and
it will install the same way across all ports.  If the Amiga people do one
thing, the PC people another and the Mac people a third, it's gonna be
a self-inflicted mess.

-- 
David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto
           email: [email-masked], finger for PGP public key
        finger [email-masked] for latest Toronto Free-Net information
          <A HREF="http://www.eecg.toronto.edu/~dej">Click me!</A>

---

From: Charles Ewen MacMillan <[email-masked]>

On Mon, 5 Sep 1994, David Jones wrote:

> Date: Mon, 5 Sep 1994 12:01:44 -0400
> From: David Jones <[email-masked]>
> To: [email-masked]
> Subject: Re: /opt vs. /usr/local
> 

 Yes. I realize this. The basis of my argument is however from the 
perspective of someone who has the dumbest users possible.

 My site provides tons of of help to users, but still takes into 
consideration the utter stupidity of the novice. I would say that less 
than half of my users understand how to edit their .* files without 
blowing it.

 This is not an insult to my users, it is a sign of the changing times, 
when the average user of the Internet is closer to the average person 
than to the average computer user.

> thing, the PC people another and the Mac people a third, it's gonna be

 Agreed, and in spite of understanding the other side of the argument 
better now, I would stick still with /usr/local, as I believe it is in 
common usage in the other ports.

 Then again, as long as the destination of a build/install is 
configurable, it really does not matter very much.

Charles Ewen MacMillan  | Tezcat.COM - Wicker Park 
  <[email-masked]>    | Offering Internet Access 
Modem: 312-850-0112/0117| Via Interactive UNIX to 
Voice: 312-850-0181     |    the Chicago Area.
WWW: http://tezcat.com/ | Mail: [email-masked]

---

From: Hubert Feyrer <[email-masked]> "Re: /opt vs. /usr/local" (Sep 5, 12:01pm)

> ~/bin and the "system" directories, and nothing app-specific in my

I've seen something different here: Users have something like
  source /usr/local/pack1/install.sh
  source /usr/local/pack2/install.sh
  ...
in their .login or whatever, and those scripts set environment variables for
the whole session. Advantage is users don't have to think about which packages
they want to use and which not. Disadvantage: some things in PATH and
environment set that may not be needed.

The "source" command can also be hidden by an alias, leading to "use pack1 ;
use pack2", or whatever.

I thought about that, but it's (more) work for the individual users, and that's
what I not want.

> thing, the PC people another and the Mac people a third, it's gonna be

You're right, but I still feel not good about throwing all binaries into one
directory, all man pages into another one, etc.

Again my standard-example: try replacing the system's (g)cc.

Hubert

-- 
=============== Hubert Feyrer ============================================
      Weekdays: Rennerstr. 19, D-93053 Regensburg,  Tel. 0941/701788
      Weekends: Bachstr. 40,   D-84066 Mallersdorf, Tel. 08772/6084
      Internet: [email-masked] == IRC: hubertf
==========================================================================
    Click <A HREF="http://dusk.rz.uni-regensburg.de/~hubert">here.</A>
                           (soon to be back!:-)

---

From: Charles Ewen MacMillan <[email-masked]>

On Mon, 5 Sep 1994, L. Todd Masco wrote:

> Date: Mon, 5 Sep 1994 01:56:38 -0400
> From: L. Todd Masco <[email-masked]>
> To: [email-masked]
> Subject: /opt vs. /usr/local
> 
> 

 This is stating the obvious, but we are after all dealing with 
 the BSD realm rather than SVr4.

>  example, if you don't like the gnu suite, just don't put /opt/gnu in

 However, the same can be accomplished with having /usr/local/gnu and so 
on, which is already how _many_ BSD systems are constructed.

>  a personal standalone on my desk.

 Adding extra search paths for executables, especially over an NFS 
mounted directory, adds to rather irritating delays for start times, which
can be significant in heavily loaded multi-user systems.

 I too manage Suns, as well as the BSD machines I run, which are now 
actively populated by my users, and there is no /opt directory on my 
system, only local.

 There is also no /opt directory on any other BSD based system on which I 
have an account.

>  settle on one and stick to it.

 I most certainly advocate the usage of /usr/local. /opt has been 
introduced to this only very recently, and enough of us already have 
running systems with the other more BSDish tree structure.

---

From: Charles Ewen MacMillan <[email-masked]>

On Mon, 5 Sep 1994, L. Todd Masco wrote:

> Date: Mon, 5 Sep 1994 05:32:39 -0400
> Charles Ewen MacMillan writes:
> This strikes me as a religious argument: there's no reason to stick with
>  either tradition purely because "this is BSD," should people think one
>  system is better than the other.

 No, it is not a religious argument. I am coming from the perspective of 
someone with an installed software base, and users on the system. Change 
to make my life easier is rapidly defeated if anything is changed on the 
user side.

> 
> As I said, I don't see that the /opt/* is tremendously better
>  than /usr/local/*, but that line of reasoning could be applied to
>  the other example I gave, rc.local vs. /etc/rc.*.  In that case,
>  I think that /etc/rc.* is clearly better, and keeping to one
>  initialization script is just plain dumb.
> 
> Only on starting a shell;  The hash table is built at the shell's start-up
>  (ironically enough, on csh-using systems; ksh is a SVR4-shell, and it
>  doesn't use a hash table in the same way), not at the time of execution
>  of a new program.  
> --

 Pardon me, I was being unclear there. What I am referring to is the 
difference in the load time for an executable, if your path is say:

               /bin:/usr/bin:/usr/local/bin:.

                           vs.

               /bin:/usr/bin:/usr/local/bin:/opt/bin:.

---

From: [email-masked] (Rob Healey)

>  system is better than the other.
	AMEN BROTHER!

>  initialization script is just plain dumb.

	If we could somehow get the pkg utilities from SVR4, the init
	system from SVR4 and a damned properly working getty I'd be
	in hog heaven! OINK!

	For 1 and 2 I'm not holding my breath as POSIX doesn't deal with them.
	For number 3 I just installed FlexFax and scrapped the braindead NetBSD
	getty.

	In the IDEAL case the SVR4 pkg system is what we'd want, a bitch to
	create for the devloper but it makes the end user/system mangler's job
	MUCH easier to install and remove cleanly vs an in order traversal
	of some arbitrarily huge file system tree to find all the little
	droppings from some tar/script install.

		-Rob

---

From: Charles Ewen MacMillan <[email-masked]>

vs.