(cc'ing p...@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 nt...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
