[lsb-discuss] Re: PROPOSAL: /opt/<provider>/<package>/]

"Beerse, Corné" c.beerse at torex-hiscom.nl
Mon Jun 2 01:02:17 PDT 2003

> -----Original Message-----
> From: Daniel Bradley [mailto:daniel.bradley at securizance.com]
> Sent: zaterdag 31 mei 2003 3:34
> 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.

Why not?

> 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

How about /opt/sun/jdk-x.x.x-devel and /opt/sun/jdk-x.x.x-pure?

With the /opt/<provider>/<package> we can also have

/opt/hp/jdk-x.x.x-pure and /opt/gnu/jdk-x.x.x-devel

> 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.

That's covered by the 'being relocatable' requirement of the standard. Keep
in mind, the prime locaiton of a package is with the core-os distribution.
Then it should nicely shoe-horn into /usr/bin, /usr/lib and such.

> 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.

Well, come to think of it, I previously proposed to use /opt/lanana-name/...
or such and leaving the depth down there up to the supplyer as long as the
app ends in .../package/bin, .../package/lib and such. This can result in
/opt/sun/java/devel/jdk-x.x.x/bin and such.

Now it is monday morning, with a fresh cup of coffee, I think there is a
disadvantage, one cannot create a $PATH with `set path="/opt/*/bin
/opt/*/*/bin /opt/*/*/*/bin"` since the ultimate depth of the path is not

> 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. 

That is to say, default to /opt/..., not force to /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.

On what rule do you base this theory? You are right, there should be some
nice part in the installer. For most packages, this is done by the
installer. For tar distributions, they most times just extract to alocaiton
relative to the current directory.

> 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.

Well, /opt/<provider>/<package> does: it is up to the <provider> to generate
<package> names on its own behalf or to register a separate "<provider>"
name for its own <packave>. Kind of like on internet: The intention was to
have http://www.acrobat.adobe.com/ but adobe  has also registered
http://www.acrobat.com/ which is not a company but somehow gets you to

> 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.

No, for a package to comply to the standard, there is a subtree to use:
...<package>/bin, ...<package>/man and ...<package>/lib but not
...<package>/exec or ...<package>/help or ...<package>/dll

My 2cents, not my employers..

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/lsb-discuss/attachments/20030602/64869a26/attachment.htm 

More information about the lsb-discuss mailing list