Bug#83669: Shared libraries

[Brian May <bam@debian.org>]

>>>>> "Brian" == Brian May <bam@debian.org> writes:

I previously misunderstood Herbert's proposal, here it is again (I
hope it is accurate this time...).


foo2.0 (2.0) /usr/lib/libfoo.so.2.0 (actual library)
Provides: foo2 version 2.0

foo2.1 (2.1) /usr/lib/libfoo.so.2.1 (actual library)
Provides: foo2 version 2.1

foo-dev (2.1) /usr/include/foo.h
           /usr/lib/libfoo.so -> libfoo.so.2.1

the maintainer scripts for foo2.0 2.0 would create

           /usr/lib/libfoo.so.2 -> libfoo.so.2.0

while the maintainer scripts for foo2.1 2.1 would create

           /usr/lib/libfoo.so.2 -> libfoo.so.2.1

That IMHO is probably the best suggestion I have seen so far. Just as
long as foo2.1 doesn't conflict with foo2.0 (otherwise you get no
benefit)[1].


Data files (eg plugin modules, see libgii0 potato version), may be an
issue here.

If both foo2.0 and foo2.1 both contain the same data file, they
will conflict.

Fix (1): put data files in a separate package.

Fix (2): if the run-time library requires specific version of the
datafile, then the data file needs to be made unique in some way,
eg. put in a unique directory.  (so multiple versions of the data file
can be installed at once).

(a combination of these may be used).


However, neither of these solutions will help with *.la files that are
required at run-time. From the debian-policy, 11.2:

"Packages that use libtool to create shared libraries should include
the .la files in the -dev packages, with the exception that if the
package relies on libtool's libltdl library, in which case the .la
files must go in the run-time library package. This is a good idea in
general, and especially for static linking issues."

However, if foo.la file goes into the run-time foo2.0 and foo2.1, then
these packages will conflict. Solution: Fix (1), as above.

However, this exposes other issues, since the version of *.la required
depends on the version of the library required, however only one copy
of the *.la file can be installed, while a number of different
versions of the shared library can be installed at the same time.

Fix (2) could be used here, but this breaks the existing libtool
conventions.


Note:

[1] IMHO the policy suggests that it should be possible to install
multiple versions of the library at the same time, but does not
require it:

"If you have several shared libraries built from the same source tree
you may lump them all together into a single shared library package,
provided that you change all their sonames at once (so that you don't
get filename clashes if you try to install different versions of the
combined shared libraries package)."
-- 
Brian May <bam@debian.org>