Bug 665144 – perl-module.eclass/perl-functions.eclass: idea for san checking module compileability

• Product: Gentoo Linux
• Status: RESOLVED CANTFIX

[Description Kent Fredric (IRC: kent\n) (RETIRED) 2018-09-03 07:44:54 UTC]

This is a proposal for a future feature to be added when EAPI=7, which aims to make debugging perl packages, and additionally, adding extra layers of failure detection to mitigate the problem where, a Perl package may not have tests, but syntactical integrity of the code may still be subject to breakage on various perl versions.

The only sane way to check perl modules compile is to actually load them, but as loading modules has side effects, its not performed by any sort of default.

Subsequently, I'd propose the ability to have a bash array declared in an ebuild in the form:

SOMENAMEGOESHERE=(
    "ModuleName"
    "ModuleName minversionhere"
)

where each entry is the assertion that:

   use ModuleName ();

or

    use ModuleName minversionhere ();

For each entry should be expected not to fail in order for the package to be deemed "working"

Entries in this list should be predominantly a list of the packages own modules, with versions where possible, but should be augmented via various USE flags.

Some logic should be performed at some phase that validates this list, either warning of dying if there are problems ( ideally, validating the entire list, and reporting a list of failures )

Some ENV control variable should regulate activation of this feature, as it may presently be too ambitious to have it as a default behaviour exposed to end users.

Said ENV control variable may also determine which phases this check is performed in, either/all of:

  1. After src_compile
  2. During src_test
  3. In some phase that occurs after the package is installed to /
  4. During emerge --info

Stages 1/2 require fiddling to ensure the testing logic loads blib/lib into @INC

Stage 3 entails being on a non-cross-dev target.

Step 4 implies the package may not be installed yet

Additionally, it may be pertinent to enumerate a variable that lists *dependency* modules ( again, in the format above, and again, regulated by USE ) that are expected present for the package to be deemed "working" ( or indeed, deemed installable )

This may help cases where a packages dependencies appear installed according to portage, but the package itself refuses to install, and somebody needs to diagnose the problem and/or report a bug.

In the case of package dependencies, it may also be 'nice' to have logic to determine "installed version of" the dependencies stated. ( After all, using portage tools only gives half the picture in a contaminated system, because you can very much have alternative versions of things installed without telling portage about this )

Due to loading side-effects, there are security and sandboxing concerns to consider here also, more reason not to have this on by default ( but very much the sort of feature that could be enabled in a smoke test rig )

I've prototyped something *like* this in a handful of dev-perl/ packages already where executing their packaged tests proved too problematic, but determining package functionality was still important (read: needs network IO or a preconfigured database)

So I file this bug for ideas about implementation, and ideas about variable names so a draft implementation can be made.

[Comment 1 Kent Fredric (IRC: kent\n) (RETIRED) 2018-09-08 05:35:51 UTC]

Current thoughts:

PERL_PM_PROVIDES=(
   "Foo 1.0"
   "Foo::Bar"
)
PERL_PM_REQUIRES=(
   *stuff that is ubiquitously mandatory for a working install*
)
PERL_PM_BUILD=(
   *stuff that is mandatory for compile/install*
)
PERL_PM_OPTIONAL=(
   *stuff that might be pulled in by USE flags or tests*
)


The idea being PERL_PM_PROVIDES is the one most used, and the others are deployed on an "as deemed useful" basis.

DIST_PM_CHECKS_OVERRIDE="" checks none of these
DIST_PM_CHECKS_OVERRIDE="provides" checks only provides
DIST_PM_CHECKS_OVERRIDE="provides deps" checks _REQUIRES, _BUILD, and _OPTIONAL

DIST_PM_CHECKS_PHASE_OVERRIDE="" 
runs these tests in no phases

DIST_PM_CHECKS_PHASE_OVERRIDE="test" runs these tests during src_test only

DIST_PM_CHECKS_PHASE_OVERRIDE="compile" runs these tests at the end of src_compile

DIST_PM_CHECKS_PHASE_OVERRIDE="info" runs these checks during emerge --info

_REQUIRES/_BUILD should be fatal depending on which phase they're run in.

_OPTIONAL should only be informative

Still some thinking to be done here though.

The function that runs these checks should also break down the output by the dependency class to make it obvious how important they are.

REQUIRES and BUILD deps should be checked *before* PROVIDES as failures in these departments are usually indicative of broken systems, and will *lead* to failures to load entries in PROVIDES

The idea being that "problem modules" are added to _REQUIRES/_BUILD/_OPTIONAL as they're discovered to help consumers identify faults.

The names are of course still subject to debate and the mechanisms still need deciding.

Its also worth noting that current mentality intentionally avoids use flag interpolation, mostly because I haven't got a good idea how to handle these.

I *do* know that you can augment these variables at runtime and have their state preserved such that their values can be re-seen during emerge --info, and its potentially useful that emerge --info can emit different output based on the USE flags the package was built with in the event emerge --info is running for a package that is already installed.

But emerge --info doesn't *always* trigger on packages that are installed, and is sometimes run on packages that are *to be* installed, so more research is needed here on my part ( lots of assumptions and bad memory are working together here ;) )