On Fri, 05 Nov 2010 at 21:13:14 +0200, Kalev Lember wrote:
> The unversioned files in libopensc2 package will eventually conflict with
> libopensc3 package when upstream releases a new version of opensc. According
> to
> upstream's release schedule this should happen very soon: There is already a
> -rc1 out which bumped soname.
It looks as though the dlopen()able plugins themselves depend on libopensc2
and friends, so anything that dlopen()s one of those potentially wouldn't be
compatible with libopensc3 anyway (different ABI). Do processes that load
those plugins automatically have to use some of libopensc2's ABI in order
to be useful, or are libopensc2/libopensc3 just an implementation detail?
(Sorry if I'm asking questions whose answers are obvious to an opensc user -
I'm doing drive-by QA trying to get squeeze released, and I don't know
anything specific about opensc.)
> I would suggest a split with the following scheme:
> opensc-tools:
> /usr/bin/*
> libopensc:
> /usr/lib/*.2*
> opensc-pkcs11:
> /usr/lib/*pkcs11*.so,
One good alternative would be to put the plugins in a directory whose name
reflects the SONAME - perhaps /usr/lib/opensc-2/opensc-pkcs11.so or something.
They could either go in their own binary package or alongside the libraries,
whichever's more appropriate from the point of view of dependencies.
(An example in one of my packages: telepathy-mission-control's plugin loader
is in a library libmission-control-plugins.so.0, on which every plugin depends.
The plugins go in /usr/lib/mission-control-plugins.0/mcp-whatever.so.)
> "If your package contains files whose names do not change with each change in
> the library shared object version, you must not put them in the shared library
> package. Otherwise, several versions of the shared library cannot be installed
> at the same time without filename clashes, making upgrades and transitions
> unnecessarily difficult."
If their names haven't changed in the release candidate you mention, now would
be the time to fix that upstream before the final release - it's best if
things like this are done correctly upstream, rather than being patched by
distributions (with the potential for, say, Debian's and Fedora's patched
versions being incompatible).
This is certainly an important bug, but I'm not sure that it's release-critical
for squeeze, as long as everything's done correctly in the version that follows
the ABI break (i.e. no unversioned files in the library package).
Regards,
Simon
Debian QA
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
