On Mon, 29 Nov 2010 at 15:01:23 +0200, Kalev Lember wrote:
> 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).
Ah, right. Thanks for explaining this.
> 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
"Roughly the same" worries me - is it a drop-in replacement or not? - but I
can see the general principle 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'd be in favour of that on general principles: dlopen()able modules should
usually be in a subdirectory of ${libdir}, leaving ${libdir} reserved for
normally-linkable libraries with a proper SONAME (libopensc.so.2, libz.so.1,
and so on).
> 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.
This suggests a transition path: your suggested package split could occur
during the migration from libopensc2 to libopensc3, and coincide with moving
the dlopenable modules from /usr/lib to /usr/lib/pkcs11.
Depending packages would need source changes to look in the new location and
depend on the new library, but they'd need those changes *anyway* for a package
split, so you might as well combine them and only do one transition.
> 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.
We're pretty late in the freeze, and I don't think the release team are likely
to accept a transition that touches multiple packages (libopensc2 and
everything that depends on it) unless it's really critical to do so.
Splitting binary packages also involves a trip through the NEW queue.
> 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?
You're welcome to propose a patch, but I don't think anyone should NMU it
without input from the maintainer, and I personally think this bug should
be downgraded and fixed post-Squeeze.
Regards,
S
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
