[debhelper-devel] Bug#739249: dh_perl support for packages embedding perl

[Brendan O'Dea]

On 17 February 2014 13:20, Marco d'Itri <md at linux.it> wrote:
> Package: debhelper
> The inn and inn2 packages, which use an embedded perl interpreter,
> currently do this to express a proper dependency on perlapi-* (see
> #182089):
>
>         dh_gencontrol -u-VPERLAPI=$$(perl -MConfig -e 'print "perlapi-" . ($$Config{debian_abi} || $$Config{version})')
>
> dh_perl adds a perlapi dependency only to packages which contain XS
> modules, so it would be nice if it could either recognize packages which
> have an embedded perl interpreter or have a flag to force this
> behaviour.

It has been some time since I looked at this, but according to policy
you should not need a dependency on perlapi* at all:

  http://www.debian.org/doc/packaging-manuals/perl-policy/ch-embed.html#s-embedded_deps

The only required dependency is on libperl5.X, which should be added
automatically by dpkg-shlibdeps.  This will add, for the current
unstable version of perl, a dependency on libperl5.18 (>= 5.18.2),
which transitively depends on the current (exact) version of
perl-base.

> (I see that it also would add a versioned dependency on perl, is it
> actually needed in my case?)

If the inn packages require anything from /usr/{lib,share}/perl
however which is not part of perl-base, you need to declare an
explicit dependency on perl.  It need not be versioned, since the
implicit perl-base dependency will handle that.

Note that the perlapi* dependencies were added for XS modules (which
is why dh_perl adds them only in that case).  They were added to
reduce the necessity of rebuilding XS modules with every minor Perl
revision when the newer revision is ABI compatible and to manage an
unversioned /usr/lib/perl5 directory, ensuring that everything in
there is compatible with the current /usr/bin/perl (not something
which is typically an issue for embedding programs).

I can see an argument however for also adding a perlapi* dependency
for packages which embed Perl, given that a non-trivial implementation
will be using just as much of the Perl internals as a typical XS
module.  This would require both a policy change, and an update to
dh_perl.

Niko: have there been cases where a dependency on both libperl5.x and
perlapi-5.X.y would have been different that just having the first
dependency?  I can imagine cases where ABI compatibility was broken by
minor versions, but don't recall an instance myself.

--bod