<p>Em 20/07/2011 20:08, "Jonathan Craig" <<a href="mailto:jcraig@opencsw.org">jcraig@opencsw.org</a>> escreveu:<br>
><br>
> On Wed, Jul 20, 2011 at 2:06 PM, Peter FELECAN <<a href="mailto:pfelecan@opencsw.org">pfelecan@opencsw.org</a>> wrote:<br>
> > need to use different versions on their own systems. As always, look how<br>
> > Debian solved the issue.<br>
><br>
> There are two use cases for this problem:<br>
><br>
> Unique SONAMEs ) This is the better behaved use case.  In this<br>
> situation multiple versions of the shared libraries can co-exist in<br>
> the same directory.  So lets assume we have the app "foo" that<br>
> provides "libfoo" and has a version 1 & 2.<br>
><br>
> package        contents   dependency<br>
> foo1             bin           depends on libfoo1<br>
> foo2             bin           depends on libfoo2<br>
> libfoo1          so<br>
> libfoo2          so<br>
> libfoo1-dev    header     depends on libfoo1, conflicts libfoo2-dev<br>
> libfoo2-dev    header     depends on libfoo2, conflicts libfoo1-dev<br>
><br>
> If debug versions of so's then:<br>
> libfoo1-dbg   debug-so   conficts with libfoo1 (and libfoo1 conflicts with it)<br>
><br>
> This allows multiple bin/so versions to be installed and one version<br>
> of the headers.</p>
<p>What if two maintainers are building packages at the same time and each one needs a different version of a library? </p>
<p>> We could extend this with CSWalternatives to allow<br>
> switching between header versions but could be confusing if you assume<br>
> the version you want is the current version.<br>
><br>
> Non-Unique SONAMEs) Bad developer, bad.  Oh well, the packager must<br>
> still deal with it.</p>
<p>In the general case, it is possible to inject an additional soname number to make the sonames unique.</p>
<p>> I'm not sure of an example package like this to<br>
> check against my ubuntu catalog.  This situation calls for either<br>
> making the versions exclusive (using conflicts with) or configuring<br>
> them for there own tree.  Using alternatives is a risky undertaking<br>
> because it will almost always eventually cause grief. If alternatives<br>
> puts the .so in a common lib directory and a user builds against it<br>
> then changes the alternative choice, whatever they've built will<br>
> break.</p>
<p>Yes, alternatives do not look like a good choice, neither for .so symlinks, nor for libraries. </p>
<p>> Ultimately, if the library is well behaved then I do think its best to<br>
> place it in a common directory (/opt/csw/lib).</p>
<p>Cool. There is one case which needs consideration: gcc C++ libs vs Solaris Studio C++ libs. If we compile the same sources with both compilers, we will get a soname conflict. What should we do: put gcc libs into e.g. /opt/csw/lib/gcc/ or append "gcc" to the soname and keep the lib in /opt/csw/lib? (Or is there another solution?)</p>

<p>Maciej</p>