Hi Fabian,
Fabian Fagerholm wrote:
> Is it forbidden by policy (or otherwise) to include .so symlinks without
> the version number (for example, <libraryname>.so ->
> <libraryname>.so.0.0.0) in a non-dev package?
In general, yes. Let's say your library package is libfoo0 and it
includes the files
libfoo.so.0.0.0
libfoo.so.0 -> libfoo.so.0.0.0
libfoo.so -> libfoo.so.0.0.0
Later the soname is changed, so you ship a new package libfoo1 containing
libfoo.so.1.0.0
libfoo.so.1 -> libfoo.so.1.0.0
libfoo.so -> libfoo.so.1.0.0
The libfoo.so symlink that exists in both packages will prevent you from
having libfoo0 and libfoo1 installed simultaneously, and this is a
Policy violation (runtime libs must be co-installable for ease of upgrades).
> I guess the general answer is that it shouldn't be done, but how about
> this particular case:
>
> synfig, a 2D vector animation package, uses a (libtool) dlopen()-style
> way of loading plugins at runtime. The plugins are shipped as .so's. The
> plugin loader is not sophisticated enough to ask the ltdl routines for a
> versioned library [0]. If we don't ship the unversioned .so symlinks
> together with the actual .so's, the program will not work unless the
> -dev package is installed with the unversioned symlinks (some plugins
> implement essential functionality).
>
> The plugin .so's are not designed to be accessed directly. The purpose
> is to access them through libsynfig, which is properly versioned. In a
> sense, they differ from shared libraries ("libraries that are to be
> shared between applications").
As long as they aren't in /usr/lib or some other place where the linker
can find them -- that is, they are private files of synfig -- you
actually don't need to follow Policy for shared libraries. I'm not
really even clear on why you need library versioning. If synfig and its
plugins are in the same binary Debian package, there is no problem at
all. If they are in different binary packages, say "synfig" and
"synfig-plugins", but generated by the same source package, then you can
always have synfig Depend on synfig-plugins (= ${Source-Version}) so
they are guaranteed to be in sync.
> Is it ok to include the unversioned symlinks for the plugin .so's in the
> non-dev package (libsynfig0)?
If the only things in libsynfig0 are plugins, then I would rename it to
synfig-plugins, put the plugins into /usr/lib/synfig/modules, and
proceed as above.
If there is also an honest-to-goodness shared library that goes in
/usr/lib and itself uses the plugins, things get a bit more complicated.
The important thing is to make sure that libsynfig0 and the eventual
libsynfig1 are co-installable. One solution is to use versioned
directories. In the case of synfig, maybe you could have something like
this in the libsynfig0 package:
/usr/lib/synfig/0/modules/libplugin.so.0.0.0
/usr/lib/synfig/0/modules/libplugin.so -> libplugin.so.0.0.0
/usr/lib/libsynfig.so.0.0.0
/usr/lib/libsynfig.so.0 -> libsynfig.so.0.0.0
and in libsynfig-dev:
/usr/lib/libsynfig.so -> libsynfig.so.0.0.0
/usr/lib/libsynfig.a
/usr/include/whatever.h
This supposes that libsynfig can be configured to look for its plugins
only in the directory "/usr/lib/synfig/0/modules". When you bump the
soname, the lib becomes libsynfig.so.1.0.0 and the plugins go into
"/usr/lib/synfig/1/modules", where the new lib is configured to look.
(For simplicity I'm assuming the main library and the plugins have
soversions that stay in sync. If this is the case, again I see no
reason for the plugins to need soversions.)
Hope this helps,
--
Kevin B. McCarty <kmccarty@princeton.edu> Physics Department
WWW: http://www.princeton.edu/~kmccarty/ Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
Attachment:
signature.asc
Description: OpenPGP digital signature