[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /opt (Re: Berlin & FSSTND/FHS)



On Tue, 6 Jul 1999, Russell Coker wrote:

> >I still wonder over that one... FHS 2.0 said /opt is being used on
> >Solaris (for example) but it doesn't go into specifics.
> >
> >Now what if Sun installs anything into /opt?  Do they?  If so, why
> >can't we?
> 
> I've got access to some Solaris 2.6 machines.  I've got a machine
> with 4 /opt/SUN* directories, one with 3, and a few with 7.  Each
> /opt/SUN* directory corresponds to one Solaris package.
> 
> In Sun machines you install significant applications in /opt because:
> 1A) The package manager isn't much good and you will often want to
> hack things around yourself.

My experience is the Solaris package manager is quite good.


> 2) Most applications aren't in a package format.  For example Ingres
> is in a single TAR archive which needs at least two passes to
> extract the files (you extract the install/ directory and let the
> install program extract the rest). Ingres should be shipping as a
> Solaris package for Sun architecture and Debian or RPM packages for
> Linux.  So the only way to remove Ingres is "rm -rf /opt/ingres".

Agreed.


> 3) /usr/local gets too crowded with GNU stuff to be useful to the
> administrator who would otherwise put things they compile themself
> in there.  GNU software binaries for Solaris comes in two forms.
> One form is in /opt/FSF* (which requires adding all of /opt/FSF*/bin
> to your path or lots of sym-links).  The other is having everything
> in /usr/local.

I don't understand this.


I've used the /opt approach to packaging quite successfully for both
Debian and Solaris.  I don't believe this thread has identified the
significant advantages which I believe to be:

   * Very simple to provide multiple versions of the same package.

     In software development, it is often important to have a number 
     of previous versions of libraries and utilities available for
     regression testing.  The "alternatives" approach simply doesn't 
     scale.

   * Finer control on file sharing of package.

     With all packages installed in /usr, no control is available as 
     to which packages you would want to make available through the
     network.  With the opt approach this again is trivial.

I realize there are tradeoffs with the /opt approach but I have
found it to be an effective approach for large packages.

-- 
Jean Pierre



Reply to: