On 17 February 2014 13:20, Marco d'Itri <m...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org