SUMMARY: Companion Disk and install location

From: Matthias Kurz <>
Date: Sat Dec 08 2001 - 13:09:38 EST
On Wed, Dec 05, 2001 at 06:12:25PM +0100, Matthias Kurz wrote:
> Hi.
> As many know there comes a so called Companion Disk (CCD) with the
> latest Solaris releases. It is a growing set of freeware.
> I'm curious:
> - How many people are installing the packages from the CCD.
> - The packages install under /opt/sfw. What, if they would install
>   under /usr/local. Would that be better ? Worse ? Would anybody
>   care ?

Ok, my questions were a little bit vague, but i did not want to push
anyone in any direction. I think the answers i received helped me.
Also i fear the thing with the "g" may be another source of discussion.

My thanks go to
"Evans, Tim" <>
"Heilke, Rainer" <>
"Henrik Huhtinen" <>
Hichael Morton <>
John Leadeham <>
"Kevin Buterbaugh" <>
ltiu <>
"Stephen Waelder" <>
Steve Elliott <>

Hope, i did not miss anyone/anything.

Now the result.

To the first part: I was interested, whether there are people that
strictly bake there own bread or whether "all" complement there
private collections with the freeware that is supplied by Sun (btw
it's called the Companion CD, not the Companion Disk). As far as i
can see, most are using at least part of the CCD.

To the second part: I was involved in a discussion about the install
location of freeware. One part said: /usr/local is "the" *STANDARD*
location for any type of freeware. Whoever supplies such software
should let it install in /usr/local.
Another part said: /usr/local belongs to the *LOCAL* sysadmin or user.
No external software supplier (let alone the OS vendor) should install
software in /usr/local. This causes conflicts and grieve. Also, packaging
makes the CCD a complete new product that should reside in it's own

A "custom" install does not work with most software, because most
things are fixed after the compilation. Though, in case of space
constraints, one can move the whole hierarchy to another location and
use a symlink (e.g. /opt/sfw -> /add_space/opt/sfw).

Well, in some sense, every further discussion is futile (actually, i
think some people will just take a new direction :) ). Through another
channel i got this statement from someone from Sun:

 Absolutely no software delivered from Sun should install
 in /usr/local.  This is a space reserved for System Admins
 and Developers to install their own copies of software.
 There will never be consensous to from any interal department
 within Sun to deliver software that installs in /usr/local.


Full answers (not ordered):


     I've installed them on my Ultra 5 under /opt/sfw.  Since our
"standard" is to have only the / and /var filesystems plus swap space on
the root disk, installing in /usr/local would make no difference to me.

     The main thing I love on the companion CD is Gnome (I'm currently
running 1.4).  I've never been a CDE basher, but after using Gnome, I'll
never go back...


I tend to install the versions off of They are often more
current, and install in the usual /usr/local directory structure. My
personal feeling, and that of a couple of people I've discussed it with, is
that for it to be installed in yet another tree is silly. Yes, it is
third-party, so it should not be in the standard Solaris areas, but it is
unsupported (certainly not supported by Sun), so for it to go into /opt
seems a bit bizarre. /usr/local has always been the standard for this type
of software, so why change it? There is no compelling reasons I have yet

Sorry, bit of a rant, there. ;-)


I routinely install it.
It is trivial to add /opt/sfw/bin (and sbin) to PATH, and
/opt/sfw/man to MANPATH.

Note that Gnu software with Solaris equivalents is named
with an initial 'g', for example gfind and gxargs.


Did you try the "custom" install to see if you could tell it to go  

FYI, this takes the better part of a GB of space; if you don't have that in
the filesystem where /opt is, you'd need to make a separate filesystem and
mount it there.


I install all the Companion Disk software that I can on my machines
(user, development, that is, non-production) and install them in the
/opt partition.  I leave /usr for only the regular /usr and /usr/openwin
files.  If a software package wants to install to /usr/local, I created
the appropriate link to /opt/usr/local.  My /opt is usually a large
partition and accommodates these programs (like Star Office, Netscape,
Adobe Arcobat Reader, etc., etc.). 

With the gigantic hard drive drives these days (I started with 424MB
hard drives), I plan 5GB to 8GB for /opt on my machines.


I have deployed many of the packages that are contained on the companion CD, but
 I go to and download only the packages that I need.
 The default location for everything on Sun Freeware is /usr/local. If you do ne
ed to change things, the source is available too.


Let it install in /opt
/opt is for prepackaged software.

/usr/local is for software you compiled from source then installed.


> - How many people are installing the packages from the CCD.

we install it whenever we do a fresh install, mostly
to use gcc

> - The packages install under /opt/sfw. What, if they would install
>   under /usr/local. Would that be better ? Worse ? Would anybody
>   care ?
don't really care. adding /opt/sfw/bin to my path isn't all that arduous!


We use many useful packages from that cd. (wget, top, gnu, etc..).
I prefer anything non-sun-provided software to reside in /opt rather
than /usr something, but that's just a matter of opinion, I guess. If
you make all your self-made packages reside in /opt/<softwarename> it is
also easy to check what is installed and easy to transfer from one
machine to another by tarring the entire directory. Also, this way I do
not have to estimate extra space for /usr growth, since almost nothing
is written there after the initial install (perhaps some Sun drivers or
software, but nothing else). 

Matthias Kurz; Fuldastr. 3; D-28199 Bremen; VOICE +49 421 53 600 47
   >> Im prdmotorischen Cortex kann jeder ein Held sein. (bdw) <<
Received on Sat Dec 8 18:09:38 2001

This archive was generated by hypermail 2.1.8 : Wed Mar 23 2016 - 16:32:37 EDT