Summary: | dev-perl/Config-Tiny-2.160.0 lacks dependency on >=virtual/perl-Module-Build-0.380.0 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andrew Savchenko <bircoph> |
Component: | [OLD] Development | Assignee: | Gentoo Perl team <perl> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bircoph |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=495044 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | emerge --info |
Description
Andrew Savchenko
![]() Created attachment 367250 [details]
emerge --info
The upstream module in question has dual-build, so its not a show-stopper, however, our eclass situation is such that gentoo will: 1. In the presence of a Build.PL file, always used Module::Build style invocation, regardless of truth. ( Potentially exploding if Module::Build is not installed ) 2. In the scenario where Build.PL is _Not_ Module::Build, erroneously complain about a dependency on Module::Build, which is not neccessary 3. Also entirely fail to QA check on the appropriate dependency when Build.PL requires some other things. Essentially, the QA check we have in place is a bit wonky, and the mechanism that triggers it is wonky and unreliable too. I've a few ideas on how we should solve this, but its lengthy and I've thrown them here: https://gist.github.com/kentfredric/8299018 A short term redux for @others, because I keep hitting the QA warning: 1. perl-module.eclass currently uses Build.PL if one exists, regardless of Module::Build being installed. 2. Thus, if there is a Build.PL and Module::Build is not installed, breakage will happen. 3. Therefore this module must depend on virtual/perl-Module-Build 4. Additionally, upstream declares a mandatory minimum of 0.380.0 https://metacpan.org/source/RSAVAGE/Config-Tiny-2.16/META.json#L24 5. Therefore this must >=virtual/perl-Module-Build-0.380.0 This is especially relevant now that Build.PL can sometimes imply Module::Build::Tiny instead of Module::Build, or because older Module::Builds could theoretically be installed still. The rest of my comments are more metadiscussion about longer term strategies. But solving this bug directly is much more straight forward. Fixed. |