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