[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,
>so
>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.
>The
>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.
Cheers,
Waldo
More information about the Portland
mailing list