On 11/29/2010 03:41 PM, Simon McVittie wrote:
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
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
