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