Re: Bug#602546: libopensc2 package contains unversioned .so files
Kalev Lember
> 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
Simon McVittie
> 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
Kalev Lember
> 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.
Yes, all very true.
The only reason I can think of why it might be a good idea to get it
into Squeeze is to make the version of libopensc2 *distributed with
Squeeze* parallel installable with the version of libopensc that is
going to be in Wheezy.
Certainly not the end of the world if it's too late in the release cycle
to do that.
For what it's worth, according to 'apt-cache rdepends libopensc2', the
only package which would need updating to accommodate for binary package
split is 'esteidutil'; 'kvpnc' and 'krb5-pkinit' appear to currently
depend on 'opensc' package instead to avoid depending on the
soname-specific libopensc2 subpackage which they really need. In any
case, as you said, it's still probably not worth doing it that late in
the release cycle.
Thanks for your time!
--
Regards,
Kalev