[lsb-discuss] Re: PROPOSAL: /opt/<provider>/<package>/]
Daniel Bradley
daniel.bradley at securizance.com
Fri May 30 18:34:28 PDT 2003
Hi all,
My concern here is that to adopt a strict /opt/<provider>/<package>
would not allow the installation of two different instances of a release
of software.
A specific example would be installing two installations of the same
version of the Java SDK.
Currently you can install these something like:
/opt/jdk-x.x.x-devel
/opt/jdk-x.x.x-pure
Where devel would include development providers/config etc.
By adopting a standard /opt/<provider>/<package>, many developers might
start to rely on that as the standard static path to their package,
leading to inflexible practices such as hardcoding library locations
instead of using the $ORIGIN linker variable so that libraries are
located relative to the binary.
I believe that when software is installed it should ask where it should
be put (could default to /opt/<provider>/<package>), and if it has any
dependencies it should ask the person installing where those are, if it
can't find them itself.
However, for the LSB, applications being installed MUST NOT have
dependencies other than those provided by an LSB complient system, so
this shouldn't be a problem.
Another issue, that needs to be address NOW if /opt/<provider>/<package>
is to be standardized, is what rights distro installers have. Currently
distros have assumed the right to start installing things into /opt.
Theoretically they are only allowed to do this if the thing they want to
install isn't already there, or maybe ask to upgrade.
In this situation would a distro be allowed to install in
/opt/<provider>/ without asking if it already existed, but the package
/opt/<provider>/<package> doesn't.
Somebody said something about the provider can decide what to do under
/opt/<provider>. I don't think this would work as once you get out of
one product group in any company, chances are that things are going to
start being done differently. But that is just a personal opinion.
Cheers,
Daniel Bradley
More information about the lsb-discuss
mailing list