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

Re: Plugin API/ABI versions



Le vendredi 01 juin 2007 à 18:03 +0200, Magnus Holmgren a écrit :
> Many applications allow their functionality to be extended by means of 
> plugins, often in the form of libraries that the application dlopen()s. 
> Usually the application provides an API, and like other APIs these APIs (and 
> ABIs) can evolve, calling for versioned dependencies. But executables aren't 
> shared libraries, so there are no SONAME/NEEDED tags (typically, AFAIK, the 
> API headers define some version constants that the application queries the 
> plugin for to detect incompatibilities) and using dpkg-shlibdeps doesn't 
> work. So how should the -dev package provide correct dependency information 
> in these cases?

The virtual ABI package Ben proposed is also in use by perl, pango and
GTK, it is a good way to fix that but it must be handled manually; these
packages have a large number of modules, so writing debhelper scripts
for them (dh_perl, dh_pangomodules, dh_gtkmodules) was justified.

> - Should the application put necessary parts in a shared library, which 
> plugins can link against, thereby making full use of symbol versions 
> possible?

In all cases this looks like a good idea, it allows for example for
easier detection of broken plugins. Please note that this is not
sufficient to be sure of ABI compatibility, as this only handles symbols
provided by the application to the plugin, not what the application
expects from symbols provided by the plugin.

> - Can the plugins usually simply declare the API version it's actually using 
> (which it should know), overriding the version constants in the headers? More 
> generally, what can cause a binary, compiled with (say) version 1.1 of 
> libfoo.h instead of previously version 1.0 (i.e. it doesn't use any new parts 
> of the API) to fail to work with version 1.0 of the library? Changed macros 
> that cause a different symbol to be referenced comes to mind. What else, if 
> symbols aren't versioned?

A simple way to avoid such problems is to version the plugin directory,
e.g. /usr/lib/foo/1.0/plugins/ or /usr/lib/foo/1.1/plugins/.

Cheers,
-- 
 .''`.
: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.

Attachment: signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=


Reply to: