Project:Perl/EAPI7 DEPEND

With EAPI=7, rudimentary support for cross-compilation build host vs. target host dependencies was introduced. This changes the structure of Perl-related ebuilds somewhat, even though the details are not really ideal.

RDEPEND

• Must be available on the final target at runtime
• May not be necessarily usable on the build environment (CBUILD) if cross-compilation is occurring

These are the modules and libraries used by a dev-perl/* package at runtime.

DEPEND

• Must be available for the target architecture at build time
• In the context of Perl, essentially only libraries that are linked with

BDEPEND

tests

Currently, tests are run directly on the CBUILD host, and there's no way not to. Subsequently, if the tests can't be run under cross-compile, the right approach is not to run tests at all. (eg: with some RESTRICT magic or a gate in src_test)

This means that as a result, the test dependencies must be available in BDEPEND.

For perl, this means that the "standard" value of BDEPEND should be:

   BDEPEND="
       $CONFIGURE_REQUIRES
       $BUILD_REQUIRES
       $RDEPEND
       test? ( $TEST_REQUIRES )
   "

As upstream declares that all runtime requirements must be satisfied prior to invoking make/Build, and all runtime/configure/build requirements listed in META.* must be satisfied prior to invoking perl Makefile.PL or perl Build.PL ( And various failures can occur if you don't satisfy this, and (potentially copious) warnings are expected to occur if you don't satisfy this, and their formatting is prone to users thinking things are broken and filing bugs, even if no real problem exists )

In theory we could do:

   BDEPEND="
       $CONFIGURE_REQUIRES
       $BUILD_REQUIRES
       test? ( $RDEPEND $TEST_REQUIRES )
   "

Which would pull in RDEPEND on the build host only when running tests, which would give portage more opportunities to potentially elide installing RDEPEND values unless strictly necessary (ie: conceptually, most perl packages can be built and installed without any dependencies at all, but configure is where things can get funky because upstream likes do do thing special on a regular basis, including changing behaviour based on what is presently installed ), but there's lots of risks with increased fragility, and to the best of my knowledge, portage can't presently make use of these opportunities anyway.