Bug#946655: dh_perl: why is ${perl:Depends} substituted as perl:any for programs only?
Package: debhelper
Version: 12.7.2
Severity: wishlist
Control: affects -1 + apache2-dev
Hi debhelper people (e.g. Niels), perl people (e.g. Niko) and cross
people (hello?),
I was looking into cross building src:openjpeg2 and that turned out to
be a rabbit hole. It Build-Depends on apache2-dev. apache2-dev happens
to not be installable for foreign architectures at all, because it
Depends on perl. For it to be installable on foreign architectures, the
dependency would have to be perl:any. The dependency is not added by the
apache2 source package directly, but substituted by dh_perl as
${perl:Depends}. dh_perl in turn looks for perl stuff inside the binary
package and discovers both scripts (in /usr/sbin) and the debhelper
sequence addon and concludes that apache2 contains both a module and a
program. Then we reach this debhelper commit:
https://salsa.debian.org/debian/debhelper/commit/9bfbef9e66409cf29221f9fdc811c2b796e70d0a
| dh_perl: Emit perl:any dependencies for program-only pkgs
That's the commit that adds :any only if the package contains
exclusively programs. The commit fixes #824696, which was originally
filed by Javier Serrano Polo and later commented by Niko Tyni:
| AFAICS wine*-tools depend on perl for running #!/usr/bin/perl scripts. In
| that use case perl:any probably makes sense. However, ${perl:Depends} is
| also used (and, as I suspect, much more widely) for Perl module package
| (lib*-perl) dependencies, where things quickly get much more complicated.
|
| It seems to me that it might be safe for dh_perl to add the :any modifier
| if the package only has #!/usr/bin/perl scripts?
Niko didn't give further reasons here, so Niels implemented it that way
in debhelper.
Now let me question this. Why is it unsafe to add :any to perl modules?
I outlined above that it is useful to ask this question, because it
affects the installability of apache2-dev. Let me argue in favour of
using perl:any for modules as well.
Let us call the module package libexample-perl. libexample-perl Depends
on ${perl:Depends} and thereby gets its perl dependency. libexample-perl
contains perl modules and possibly perl programs as well.
The case where libexample-perl depends on an extension is boring,
because the extension will have a perl dependency without :any. In this
case, annotating the perl dependency of libexample-perl is harmless and
useless. Therefore we can assume that libexample-perl does not depend on
any extension (directly).
libexample-perl could have an indirect dependency on an extension. In
that case, it would depend on a chain of perl modules leading to the
extension. A perl module that depends on an extension (even indirectly)
must not be marked Multi-Arch: foreign. Therefore each edge in this
dependency chain preserves the architecture constraint. Therefore,
indirect dependencies on extensions are boring in the same way as direct
dependencies.
We can therefore assume (for simplicity) our libexample-perl only
depends on further perl modules and no extensions beyond those included
in a basic perl installation.
So what we get is a libexample-perl whose architecture value (possibly
after mapping "all" to the native architecture) does not have to
correspond to the architecture of the perl installation. Let us
introduce a package called "consumer" that depends on our
libexample-perl. If our consumer (transitively) depends on a perl
extension, then by the above argument it'll have an
architecture-preserving dependency chain to perl. So we can again assume
that it only depends on modules. Again, it doesn't matter to the
consumer which architecture perl actually has, so all should be fine.
This latter case is hit precisely by apache2-dev. We want a foreign
apache2-dev to contain a perl module and have the dependency annotated
:any.
So why don't we allow using perl:any for perl modules?
I guess that this might subtly fail if perl has something like python's
ctypes that allows opening any shared library. Such failure also applies
to programs though. So if using perl:any for programs is safe, then the
same should apply to modules.
If we end up using perl:any for modules, rebuilding apache2 will make
apache2-dev usable for cross compilation. If there is a flaw in my
reasoning, there still is a way around: We can split apache2-dev into a
new arch:all package that I'd call "dh-sequence-apache2". We'll move the
dh sequence to that new package and mark it Multi-Arch: foreign. I can
try writing a patch, but it comes at the cost of introducing a new,
small binary package.
Yes, this is all a little complicated. Please bear with me.
Helmut
Reply to: