[Portland] /opt setup

[Karol Pietrzak]

On Friday 21 July 2006 13:55, Bastian, Waldo wrote:
> >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.

I'm sorry, I haven't kept up with the entire conversation.  Could you 
elaborate on "the same dilemma".  Thanks!

-- 
Karl Pietrzak
kap4020 at rit.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/portland/attachments/20060721/7912af07/attachment.pgp