[Portland] Re: defending /opt/
waldo.bastian at intel.com
Thu Jul 20 14:06:41 PDT 2006
>> George Kraft wrote:
>> > James Richard Tyrer <tyrerj at acm.org>/* wrote:
>> > */James Richard Tyrer <tyrerj at acm.org>/* wrote:
>> > With all these links, is there really any point in installing
>> > application in: "/opt/"? I suppose so, but I can't help but
>> > Here is the original FHS rationale.
>> > http://www.pathname.com/fhs/2.2/fhs-3.12.html
>> > What do you do if three different vendors want to install Java?
>> > /opt/vendor/product/ resolves that. What do you do if you want to
>> > install multiple versions of the same product? What do you do if
>> > want to install both ppc32 and ppc64? The /opt/ isolates the
>> > they only polute their namespace subdirectory. :-)
>> > http://lsbbook.gforge.freestandards.org/pack-adv.html
>> > In short, /opt/ is to protect /usr/ from insane 3rd party packages.
>> Yes, this is the rational. It is also why apps installed in: "/opt/"
>> not make links for their executables.
>> IIUC, your method would defeat this rational since everything would
>> linked to: "/opt/bin/", "/opt/lib/", "/opt/man/", "/opt/<etc>/" and
>> are back to having collisions. This is what I said that all the
>> will defeat the purpose of installing in: "/opt/".
>I think it would better if the links made for the executables in /opt
>for /opt/bin, /opt/lib etc were made under the optional control of the
>administrator installing the package. Analagous to how Debian handles
>packages providing similar functionality and making the selection
>through the /etc/alternatives mechanism.
>This way you could have multiple packages installed, the /opt/bin
>would merely be the default version used for the system, but with the
>others still accessible.
The alternatives mechanism is interesting. Are there any tutorials or
examples of how to use that in RPM? I think we should make sure that
xdg-utils can hook into that when installing menu files and such.
More information about the Portland