[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Including .so symlinks in non-dev package: policy violation?


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?

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").

Is it ok to include the unversioned symlinks for the plugin .so's in the
non-dev package (libsynfig0)?

[0] This is a planned future enhancement, but until someone steps up to
    implement it, the simple loader is all we have.

Fabian Fagerholm <fabbe@paniq.net>

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: