On 11/29/2010 12:02 AM, Simon McVittie wrote:
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?
OpenSC is a PKCS#11 library and exposes its public interface in
opensc-pkcs11.so and onepin-opensc-pkcs11.so files. In addition to the
public interface, the libraries and utilities internally use the
libopensc2/libopensc3 libraries (libopensc.so.2, libopensc.so.2,
libpkcs15init.so.2, and libscconf.so.2).
The exposed PKCS#11 interface [1] is usually backwards-compatible
between different opensc releases. For example, even though the soname
of libopensc.so.2 changes to libopensc.so.3 in opensc-0.12 release, the
exposed public PKCS#11 interface stays roughly the same and is
compatible with older opensc versions.
[1] http://en.wikipedia.org/wiki/PKCS11
I would suggest a split with the following scheme:
opensc-tools:
/usr/bin/*
libopensc2:
/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.)
That approach would work well if the only user of the pkcs11 plugins
were the programs distributed with opensc itself -- but that's not the
case here. A lot of other programs can make use of the pkcs11 interface
and it would be counterintuitive to have opensc-pkcs11.so in
/usr/lib/opensc-2/. In particular, there's movement to consolidate
(symlinks of) all PKCS#11 libraries under /usr/lib/pkcs11/.
I think a better approach would be to split the *pkcs11*.so files in
opensc-pkcs11 subpackage which doesn't change name if the internal
libopensc.so.X library changes. This way applications which need
opensc-pkcs11.so functionality can Depend: on opensc-pkcs11 package and
need not concern with implementation details like the internal
libopensc.so.X library soname.
Right now applications which need opensc-pkcs11.so have to Depend: on
either libopensc2 or libopensc3, even though they don't really care what
is the soname of the internal library and really just want _any_
opensc-pkcs11.so library.
"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).
I am not sure if it's release-critical either, but in any case it would
be nice to get it solved for Squeeze release to avoid potential upgrade
path issues between Squeeze and next future release.
Would it be OK to propose a patch here to reorganize the subpackages in
the way outlined above or should I wait for the maintainer's response first?
Thanks for taking your time to review the bug, Simon!
--
Kalev
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
