Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The "license" entry in META.yml has long stymied me. The spec [sourceforge.net] says: "See the Module::Build manpage for the list of valid options." Unfortunately the link to the manpage is busted.

    Module::Build::API [cpan.org] seems to provide this list, though. The wording of the specification is vague, but given that there is a list of valid options, isn't anything else invalid?
    --
    rjbs
    • ...furthermore! The list from Module::Build::API is unclear. "apache" isn't qualified, so it's not clear if it means 1.0, 1.1, or 2.0. GPL and LGPL are also not versioned, but Artistic is.

      Ugh.

      copyright:
        license:  Software::License::Artistic_2_0
        year: 2008
        holder: Ricardo Signes
      Or something, please.
      --
      rjbs
      • The spec does say look at that link for a list of valid options, but itself only implies that it is required and a string. However, M::B::API states "Valid options include:", thus I've taken that to mean that this is not an finite list, but a starting point. In the resources section there is the ability to list the licence URL, which could be updated from anything listed in M::B::API or my modules. I consider the ones I list internally to be an example rather than set in stone.

        Unfortunately the discussion regarding the META.yml spec still seems to be stuck on the M::B list, which I personally have no interest in joining. I would prefer to see the spec to be completely independent from any other distribution, thus making it much easier to submit patches, instead of them getting hidden in a RT queue for something else.