Bug#848113: libcrypt-openssl-rsa-perl: binary incompatibility with libcrypt-openssl-pkcs10-perl (openssl versions)

Niko Tyni ntyni at debian.org
Sun Dec 18 22:11:14 UTC 2016


On Sat, Dec 17, 2016 at 02:22:16PM +0200, Niko Tyni wrote:

> One "proper" way to do this would be to introduce a perl-openssl-abi-1.1
> virtual package that the others would depend on to make sure they are
> compatible with each other. Not sure who should provide this; it could be
> one of the existing binary packages (is there a "main" one?) or possibly
> a new separate one (perl-openssl-defaults?)
> 
> (This is quite close to the perl-dbdabi-* thing we did for libdbi-perl
> et al., even though it turned out to be unnecessary after all as upstream
> backed out the ABI change that prompted it.)
> 
> The gain from all this would be that incompatible builds couldn't be
> installed together, and normal britney dependency checks would then
> ensure that testing gets updated in one go.

I've pushed an initial implementation of this at

  ssh://git.debian.org/git/pkg-perl/packages/perl-openssl-defaults.git

  https://anonscm.debian.org/cgit/pkg-perl/packages/perl-openssl-defaults.git

Given there's no "main" package that the others already depend on,
I went for a new source+binary package. Comments on the approach and
eyeballs would be very welcome.

I'm not sure if we can pull this out for stretch; the deadline for
new source packages is January 5th, which leaves about a week for NEW
processing and 10 days for testing migration even if we were to upload
right now.

I suppose it might be worth a try though. Modifying the affected packages
to adopt the scheme could still be done in January, as the full freeze
only starts on February 5th. And if we miss stretch, we can do this for
buster at the cost of a bunch of Breaks entries or another round of not
caring about partial upgrades.
-- 
Niko



More information about the pkg-perl-maintainers mailing list