Re: Re: PROPOSAL: /opt/<provider>/<package>/]

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