Software Installation – Where to Copy-Paste-Install Software

From the README file in

 cat /opt/scala/doc/README

I took this:

Scala Software Distributions
----------------------------

- scala-<major>.<minor>.<patch>.tar.bz2     Unix distribution
- scala-<major>.<minor>.<patch>.tar.gz      Unix distribution
- scala-<major>.<minor>.<patch>.zip         Windows distribution

The standard distributions require Java 1.5 or above. If you don't
know which version of Java you have, run the command "java -version".


Scala Tools
-----------

- fsc         Scala offline compiler
- scalac      Scala compiler
- scaladoc    Scala API documentation generator
- scala       Scala interactive interpreter
- scalap      Scala classfile decoder 

Run the command "scalac -help" to display the list of available
compiler options.


Unix Installation
-----------------

Untar the archive. All Scala tools are located in the "bin" directory.
Adding that directory to the PATH variable will make the Scala commands
directly accessible.

You may test the distribution by running the following commands:

$ ./bin/sbaz install scala-devel-docs
$ ./bin/scalac doc/scala-devel-docs/examples/sort.scala
$ ./bin/scala examples.sort
[6,2,8,5,1]
[1,2,5,6,8]
$ ./bin/scala
scala> examples.sort.main(null)
[6,2,8,5,1]
[1,2,5,6,8]
scala>:quit
$

(omitted: Windows-notes)

Does this take you a step further?

By convention, /opt is used for manually installed programs with self contained directories.

Programs in self contained directories will not show up in your PATH by default, but generally this is solved by creating symlinks in /usr/local/bin to any binaries under /opt.

As implied above, /usr/local is the other location for manually installed files, but it's generally only used for programs that split their files (/usr/local/bin for executables, /usr/local/lib for libraries, etc.).

Using /opt and /usr/local avoids potential conflicts between manually installed files and files installed by a package management system (yum, apt, etc. generally install files in /usr/bin, /usr/lib, etc.). Historically, conflicts tended to result in files being silently overwritten, causing all sorts of unexpected behaviour. Modern package management systems are better about this, but it's still best not to rely on automated conflict resolution that may or may not always do what you expect.