Re: dh_perl and ABI dependencies
On Fri, Jul 28, 2006 at 05:51:23PM -0500, Peter Samuelson wrote:
>
>Can someone please clarify this to me? From dh_perl:
>
> if ($deps & XS_MODULE or $dh{V_FLAG_SET}) {
> ($version) = `dpkg -s $perl` =~ /^Version:\s*(\S+)/m
> unless $version;
> $version = ">= $version";
> }
>
>...
>
> addsubstvar($package, "perl:Depends", "perlapi-$Config{version}")
> if $deps & XS_MODULE;
>
>Now, both of these seem to be workarounds for the fact that the shlibs
>mechanism doesn't work because most perl modules aren't linked with
>-lperl. But are they really _both_ needed? Why not just have one or
>the other?
There are two ABIs involved: one for programs embedding perl and
another for XS modules interfacing with perl.
The first is managed using the normal shlib dependencies. While
upstream doesn't actually provide any support for dropping the patch
revision (5.8.8 -> 5.8), in most cases the shlib ABI doesn't change
between patch versions (see however debian/patches/00_fix_dynaloader).
The second ABI, for binary (XS) modules is a completely sperate issue.
Unlike shared library ABIs which are restricted to the interface given
by a public header file, XS modules can use *any* of perl's internals.
Again, upstream doesn't support running XS modules built with one
version of perl with a different version, and due to the wider scope of
that API the dependencies specified in perl-policy are intentionally
conservative.
>As a secondary point: I think that, assuming dh_perl needs to emulate
>dh_shlibdeps, it ought to do it _correctly_, by reading
>/var/lib/dpkg/info/libperl5.8.shlibs rather than just generating a
>conservative (perl >= 5.8.8-current-debian-release). This sounds like
>an academic point, but it's not: there is a real problem right now with
>etch migration of a lot of packages, which would have been prevented by
>_proper_ shlibs emulation.
Please disabuse yourself of this notion that the XS dependencies have
anything to do with the libperl shared library. They don't.
For some years now (since 2001) this dependency model has worked rather
well.
Unfortunately the minor update from perl 5.8.8-5 to -6 caused some of
the autobuilders to choke because of the change in the gcc default of
gcc from 4.0 to 4.1 .
Margarita has uploaded an NMU to work around the problems with 4.1 .
This fixes the symptom rather than the cause IMHO, but if it causes the
whinging about the [non-existent] "perl transition" to go away then I'll
be happy.
--bod
Reply to: