Bug#562214: libdevel-cover-perl: Warnings about having been built against different Perl version

Niko Tyni ntyni at debian.org
Fri Dec 25 13:00:04 UTC 2009


(cc'ing perl at packages.d.o)

On Wed, Dec 23, 2009 at 03:34:29PM -0800, Ryan Niebur wrote:

> actually, this already happens. for example, libdevel-cover-perl
> depends on perlapi-5.10.0. the problem with this is that the new
> version of perl-base provides both perlapi-5.10.0 and perlapi-5.10.1.
> so we do have a way to deal with this when it really would matter, the
> perl maintainers just didn't use it this time (becuase it doesn't
> really matter). perhaps it really should have been used this time,
> and we should just binnmu everything that still depends on perlapi-5.10.0?
> I'm guessing a discussion with the perl maintainer who left it
> providing perlapi-5.10.0 would be insightful for us.

As 5.10.0 and 5.10.1 are supposed to be ABI compatible, perl-base
currently provides both perlapi-5.10.0 and perlapi-5.10.1. Cf. perl-base
in Etch, which provides everything from perlapi-5.8.0 through to
perlapi-5.8.8.

I think the perlapi-* scheme was devised before upstream settled on a
policy of binary compatibility across minor updates. We could possibly do
with just perlapi-5.10 nowadays (or maybe it should be named perlabi-5.10 ?).

Anyway, I'm not thrilled about dropping perlapi-5.10.0 and requiring 270
or so binNMUs just because Devel::Cover thinks it might have a problem
with a newer Perl upstream version.

I suppose extending dh_perl a bit could give a scalable way to require
binNMUs for selected packages when the Perl upstream version changes.
Just a new flag to substitute ${perl:Depends} with something like
 perl (>= 5.10.1-8), perl (<< 5.10.2~)
would do AFAICS.
-- 
Niko Tyni   ntyni at debian.org





More information about the pkg-perl-maintainers mailing list