Package: libperl-dev
Version: 5.22.2-1
Since 5.22.1-7 [1], libperl-dev doesn't depend on perl anymore. This was
done to make it possible to install a foreign arch libperl-dev and
libperl5.22 for cross building applications that link against libperl.
Unfortunately, this has a side effect that libperl-dev and perl versions
don't need to match anymore. So it's possible to have perl 5.24 with
libperl-dev 5.22. This means the application will be built with 5.24
headers (using the include path from ExtUtils::Embed) but linked with
a 5.22 library (because that's what -lperl gives.) Naturally this
doesn't work.
I actually ran into this when building libapache2-mod-perl2 with the 5.24
packages in experimental, as the build chroot preferred the libperl-dev
5.22 package from unstable. The compile and link phases went OK, but
the test suite failed with
Cannot load /<<PKGBUILDDIR>>/src/modules/perl/mod_perl.so into server:
/<<PKGBUILDDIR>>/src/modules/perl/mod_perl.so: undefined symbol: Perl_savetmps
as Perl_savetmps is a new symbol in libperl5.24 and therefore missing
from libperl5.22.
I'm inclined to fix this by restoring the tightly versioned
perl dependency, but qualifying it with :any (since perl is
Multi-Arch:allowed). This should be enough to keep cross builds working
AFAICS.
Package: libperl-dev
Depends: perl:any (= ${binary:Version}), libperl5.22 (= ${binary:Version})
BinNMU skew (where one arch has +b1 and another one has +b2 so
${binary:Version} differs) might cause problems there, but that's already
a sore point with multiarch in general, and will hopefully be solved
properly at some point.
We might also want to have the 5.24 perl Break libperl-dev (<< 5.24.0~)
or something like that, to make sure partial upgrades from earlier
versions without the above fix pull in a newer libperl-dev too.
[1]
https://anonscm.debian.org/cgit/perl/perl.git/commit/?id=501ef753a6ea38fdcc473bf919e138fee20a3adb
--
Niko Tyni nt...@debian.org
