Re: Plugin versioning?

[Peter Valchev <pvalchev@openbsd.org>]

Christian Weisgerber <naddy@mips.inka.de> wrote:

> It seems we're growing an increasing number of ports that put part
> of their functionality into "plugins", modules that one way or the
> other eventually get loaded by dlopen().
> 
> Invariably these plugins are named ".so".
> 
> Basically, these modules are very similar to shared libraries.
> Now, shared libraries are versioned, e.g. .so.1.0.  There was a
> developer discussion some time ago where it was decided that such
> modules should be versioned as well.  I did this for audio/libao.
> 
> Most of our ports with plugins currently don't version their modules.
> We need to do something there and handle this consistently, either
> way.

Just minutes ago I updated the jpilot port to support plugin loading,
and the last days I was dealing with the opposite - jpilot wants the
plugins in the format of 'plugin.so', and if it's plugin.so.1.0, it
doesn't pick it up unless a symlink is created.  So if versioning is
preferred (in fact I made the port _not to_ install these with version),
symlinks will still have to be created?  Or maybe the source will be
patched individually - I don't know what approach would have to be
taken.

> Not versioning modules means that we can't install two different
> versions in parallel.  It also means that if there's been an
> interface change and an old module still hangs around and is loaded
> by a new app, things will break.  Just how likely is this scenario?

I think this strongly depends on the situation.  In the above example I
pointed out, the modules are developed parallelly with the program
itself, so these concerns about interface changes and old/multiple
versions are not in charge.

> Versioning modules is a pain in the sphincter.  Apart from patching
> the Makefiles, the code that does the loading needs to be fixed.
> And since version schemes vary among unices, and I don't know of
> a way to interface this with libtool, the resulting patches aren't
> portable and can't be submitted back.

libtool can be made to create symlinks, I guess, which will still make
the programs use their 'plugin.so' style while having the real plugin as
'plugin.so.1.0' - seems like a painless solution?