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. 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. 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. Ultimately, if the library is well behaved then I do think its best to place it in a common directory (/opt/csw/lib). Jon _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
