<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.45">
<TITLE>RE: [lsb-discuss] Re: PROPOSAL: /opt/<provider>/<package>/]</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>> -----Original Message-----</FONT>
<BR><FONT SIZE=2>> From: Daniel Bradley [<A HREF="mailto:daniel.bradley@securizance.com">mailto:daniel.bradley@securizance.com</A>]</FONT>
<BR><FONT SIZE=2>> Sent: zaterdag 31 mei 2003 3:34</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Hi all,</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> My concern here is that to adopt a strict /opt/<provider>/<package> </FONT>
<BR><FONT SIZE=2>> would not allow the installation of two different instances </FONT>
<BR><FONT SIZE=2>> of a release of software.</FONT>
</P>
<P><FONT SIZE=2>Why not?</FONT>
</P>
<P><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> A specific example would be installing two installations of the same </FONT>
<BR><FONT SIZE=2>> version of the Java SDK.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Currently you can install these something like:</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> /opt/jdk-x.x.x-devel</FONT>
<BR><FONT SIZE=2>> /opt/jdk-x.x.x-pure</FONT>
</P>
<P><FONT SIZE=2>How about /opt/sun/jdk-x.x.x-devel and /opt/sun/jdk-x.x.x-pure?</FONT>
</P>
<P><FONT SIZE=2>With the /opt/<provider>/<package> we can also have</FONT>
</P>
<P><FONT SIZE=2>/opt/hp/jdk-x.x.x-pure and /opt/gnu/jdk-x.x.x-devel</FONT>
</P>
<P><FONT SIZE=2>> Where devel would include development providers/config etc.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> By adopting a standard /opt/<provider>/<package>, many developers might </FONT>
<BR><FONT SIZE=2>> start to rely on that as the standard static path to their package, </FONT>
<BR><FONT SIZE=2>> leading to inflexible practices such as hardcoding library locations </FONT>
<BR><FONT SIZE=2>> instead of using the $ORIGIN linker variable so that libraries are </FONT>
<BR><FONT SIZE=2>> located relative to the binary.</FONT>
</P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> I believe that when software is installed it should ask where it should </FONT>
<BR><FONT SIZE=2>> be put (could default to /opt/<provider>/<package>), and if it has any </FONT>
<BR><FONT SIZE=2>> dependencies it should ask the person installing where those are, if it </FONT>
<BR><FONT SIZE=2>> can't find them itself.</FONT>
</P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>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 known.</FONT></P>
<P><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> However, for the LSB, applications being installed MUST NOT have </FONT>
<BR><FONT SIZE=2>> dependencies other than those provided by an LSB complient system, so </FONT>
<BR><FONT SIZE=2>> this shouldn't be a problem.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Another issue, that needs to be address NOW if /opt/<provider>/<package> </FONT>
<BR><FONT SIZE=2>> is to be standardized, is what rights distro installers have. Currently </FONT>
<BR><FONT SIZE=2>> distros have assumed the right to start installing things into /opt. </FONT>
</P>
<P><FONT SIZE=2>That is to say, default to /opt/..., not force to /opt/...</FONT>
</P>
<P><FONT SIZE=2>> Theoretically they are only allowed to do this if the thing they want to </FONT>
<BR><FONT SIZE=2>> install isn't already there, or maybe ask to upgrade.</FONT>
</P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> In this situation would a distro be allowed to install in </FONT>
<BR><FONT SIZE=2>> /opt/<provider>/ without asking if it already existed, but </FONT>
<BR><FONT SIZE=2>> the package /opt/<provider>/<package> doesn't.</FONT>
</P>
<P><FONT SIZE=2>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 <A HREF="http://www.acrobat.adobe.com/" TARGET="_blank">http://www.acrobat.adobe.com/</A> but adobe has also registered <A HREF="http://www.acrobat.com/" TARGET="_blank">http://www.acrobat.com/</A> which is not a company but somehow gets you to <A HREF="http://www.adobe.com/" TARGET="_blank">http://www.adobe.com/</A>.</FONT></P>
<BR>
<BR>
<P><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Somebody said something about the provider can decide what to do under </FONT>
<BR><FONT SIZE=2>> /opt/<provider>. I don't think this would work as once you get out of </FONT>
<BR><FONT SIZE=2>> one product group in any company, chances are that things are going to </FONT>
<BR><FONT SIZE=2>> start being done differently. But that is just a personal opinion.</FONT>
</P>
<P><FONT SIZE=2>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</FONT></P>
<BR>
<P><FONT SIZE=2>My 2cents, not my employers..</FONT>
</P>
<BR>
<P><FONT SIZE=2>CBee</FONT>
</P>
</BODY>
</HTML>