[Portland] /opt setup

Bastian, Waldo waldo.bastian at intel.com
Fri Jul 21 10:55:10 PDT 2006

>On Tuesday 18 July 2006 03:57, James Richard Tyrer wrote:
>> With all these links, is there really any point in installing an
>> application in: "/opt/"?  I suppose so, but I can't help but wonder.
>> IIUC, the main advantage of installing an application in: "/opt/" is
>> that all of the applications files are in one place and can be easily
>> removed.  If that advantage is not needed because we use a package
>> management system that can remove all files, I really think that it
>> would best to simply drop the: "/opt/" directory.  That is, are there
>> real advantages in installing in: "/opt/<app_name>/" rather than just
>> installing in: "/usr/local/"?
>Well, package managers are great, but many applications do not use them and
>they have their limitations.
>RPM, for example, doesn't allow two packages with the same name and
>different versions to co-exist.
>> A reasonable solution would be possible if it were possible to merge
>> directories in *NIX as I understand that it is with Plan9.
>> Can Linux address this issue with a virtual file system?
>George Kraft has given a great response to this.
>I am just writing to give an example of Unreal Tournament 2004.  Where
>should I install this?  The default is in /usr/local, but I would argue 
>that /opt is a much better place for it since UT2004 just wanted to install 
>at one root (IIRC, /usr/local/ut2004).
>/usr/local has a predefined structure as the FHS describes.  /opt doesn't,
>it's great for 3rd party apps that don't need or use such a directory
>structure. More examples are Eclipse, NetBeans, and Adobe Acrobat Reader.
>Another advantage of /opt for all software is that multiple versions can be
>installed simultaneously.  Two version of Unreal Tournament, two versions
>of GIMP (release and beta), two versions of OpenOffice, etc.
>As Mats D. Wichmann points out, there is no need to
>"pollute" /usr/local/bin, /usr/bin, etc. for most desktop applications.
>menu system handles all of this, like in another popular desktop OS.  This
>has the advantage of being scalable and clean.

Sure, that solves the problem for /usr/bin and friends but now you rely on the menu system which faces the same dilemma.


More information about the Portland mailing list