Bug 1152319

Summary:	perl-Module-Starter produces invalid license identifiers
Product:	[Fedora] Fedora	Reporter:	Richard Poole <rp>
Component:	perl-Module-Starter	Assignee:	Petr Pisar <ppisar>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	20	CC:	mmaslano, paul, perl-devel, ppisar, psabata, rp
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	All
URL:	https://github.com/xsawyerx/module-starter/pull/21
Whiteboard:
Fixed In Version:	perl-Module-Starter-1.62-4.fc21	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-10-28 06:45:03 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Richard Poole 2014-10-13 20:41:01 UTC

Description of problem:

When used with some fairly simple settings, derived from the examples given in the documentation, the module-starter tool from perl-Module-Starter produces code which doesn't work correctly without the Software::License module as found in perl-Software-License. Worse, it gives misleading error messages and it's not clear which package the problem is in without tracing through code. So I think it would be sensible to have perl-Module-Starter require perl-Software-License, even though it isn't strictly necessary for it to function.

Version-Release number of selected component (if applicable):

perl-Module-Starter-1.62-1.fc20.noarch

Steps to Reproduce:

With perl-Software-License not installed (and the Software::License module not available on the system through any other means):

1. module-starter --module=My::Module --builder=Module::Build --email=example
2. cd My-Module
3. perl Build.PL

Actual results:

Could not get valid metadata. Error is: Invalid metadata structure. Errors: License 'Artistic_2_0' is invalid (license) [Validation: 1.4]
at /usr/share/perl5/vendor_perl/Module/Build/Base.pm line 4589

Expected results:

No error message, clean build.

Additional info:

http://www.perlmonks.org/?node_id=1006882 shows a user encountering this problem and not being able to trace it - the suggested fix there is to install Software::License.

The configuration included in perl-Module-Starter-PBP makes this problem even easier to encounter, because it makes --builder=Module::Build the default.

Comment 1 Petr Pisar 2014-10-14 11:13:20 UTC

Indeed, the default license identifier is not recognized by the Module::Build. That's because the identifier is not valid per CPAN::Meta::Spec specification. I will apply a fix accepted by Module::Starter upstream <https://github.com/xsawyerx/module-starter/pull/21>.

Comment 2 Fedora Update System 2014-10-14 12:00:32 UTC

perl-Module-Starter-1.62-3.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/perl-Module-Starter-1.62-3.fc21

Comment 3 Fedora Update System 2014-10-14 12:03:45 UTC

perl-Module-Starter-1.62-2.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/perl-Module-Starter-1.62-2.fc20

Comment 4 Fedora Update System 2014-10-14 12:04:11 UTC

perl-Module-Starter-1.62-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/perl-Module-Starter-1.62-2.fc19

Comment 5 Richard Poole 2014-10-14 20:49:58 UTC

The patch you've applied fixes the case where Software::License is not installed at the expense of breaking the case where Software::License *is* installed - it changes the values of the field called "slname", which is used in Module::Build, later in the build process, as the name of the license as Software::License thinks of it. (This is why the field is called "slname".)

The patched version works for the artistic license version 2 but breaks several other licenses, including the Perl license and the GPL. As most module authors will have Software::License installed and the most commonly used license is the Perl license, this will in practice break the majority of installations.

I think the best fix of all would be for Module::Starter to require Software::License and use it for its license-related logic; Software::License is capable of checking strings for compliance with CPAN::Meta , among other things. But that involves rather more work. I stand by my original suggestion, that Module::Starter should be distributed in Fedora without this patch but with a dependency on Software::License. That won't break anything that currently works and will make a significant class of confusing errors impossible.

Comment 6 Petr Pisar 2014-10-15 11:05:35 UTC

You are right that the patch is wrong. The only slnames that need a correction are the LGPL's. I think more appropriate place for a dependency on Software::License is Module::Build rather then Module::Starter.

Comment 7 Paul Howarth 2014-10-15 11:13:15 UTC

(In reply to Petr Pisar from comment #6)
> You are right that the patch is wrong. The only slnames that need a
> correction are the LGPL's. I think more appropriate place for a dependency
> on Software::License is Module::Build rather then Module::Starter.

That's what I thought too but it might introduce bootstrapping issues, with the bootstrap Module::Build not having the dependency and the dual-lived one subsequently introducing it.

Comment 8 Richard Poole 2014-10-15 11:30:42 UTC

Module::Build is used at module install time, so a dependency on Software::License would effectively bring Software::License into any working perl development setup, whereas a dependency on Module::Starter only brings it in for people writing their own modules. Of course it makes no difference to me but in general it may be considered a bloat issue: there are probably many many more installations of Module::Build than of Module::Starter .

Comment 9 Petr Pisar 2014-10-15 11:31:38 UTC

(In reply to Paul Howarth from comment #7)
> (In reply to Petr Pisar from comment #6)
> > You are right that the patch is wrong. The only slnames that need a
> > correction are the LGPL's. I think more appropriate place for a dependency
> > on Software::License is Module::Build rather then Module::Starter.
> 
> That's what I thought too but it might introduce bootstrapping issues, with
> the bootstrap Module::Build not having the dependency and the dual-lived one
> subsequently introducing it.

I'm aware of it. I will put the dependency into "not bootstrapping" condition.

Comment 10 Petr Pisar 2014-10-15 11:33:05 UTC

(In reply to Richard Poole from comment #8)
> Module::Build is used at module install time, so a dependency on
> Software::License would effectively bring Software::License into any working
> perl development setup, whereas a dependency on Module::Starter only brings
> it in for people writing their own modules. Of course it makes no difference
> to me but in general it may be considered a bloat issue: there are probably
> many many more installations of Module::Build than of Module::Starter .

The issue is Module::Build::API explicitly allows Software::License identifiers, so one can run into not working Build.PL event without Module::Starter.

Comment 11 Petr Pisar 2014-10-15 12:36:56 UTC

Module::Build does not die on Software::License identifier if the
Software::License is not available since 0.4208-2-gf75aa88:

commit f75aa882772d6ebe3b18e27076b1bb124f91cec1
Author: Leon Timmermans <fawaka>
Date:   Wed Aug 27 22:11:45 2014 +0200

    Use CPAN::Meta::Merge for meta_merge


It puts 'unknown' license into the MYMETA. However I still think having Software::License is better than loosing the license name.

Comment 12 Paul Howarth 2014-10-15 14:45:56 UTC

(In reply to Petr Pisar from comment #9)
> (In reply to Paul Howarth from comment #7)
> > (In reply to Petr Pisar from comment #6)
> > > You are right that the patch is wrong. The only slnames that need a
> > > correction are the LGPL's. I think more appropriate place for a dependency
> > > on Software::License is Module::Build rather then Module::Starter.
> > 
> > That's what I thought too but it might introduce bootstrapping issues, with
> > the bootstrap Module::Build not having the dependency and the dual-lived one
> > subsequently introducing it.
> 
> I'm aware of it. I will put the dependency into "not bootstrapping"
> condition.

If you do that, are you then going to post-bootstrap rebuild every package that pulled in Module::Build during the bootstrap process, to make sure it still builds OK with Software::License in the buildroot?

Adding bootstrap-dependent Requires (as opposed to bootstrap-dependent RuildRequires) has a much bigger impact in terms of post-bootstrap rebuilds I think.

Comment 13 Petr Pisar 2014-10-16 08:02:32 UTC

(In reply to Paul Howarth from comment #12)
> If you do that, are you then going to post-bootstrap rebuild every package
> that pulled in Module::Build during the bootstrap process, to make sure it
> still builds OK with Software::License in the buildroot?
> 
I'm not going. I could, but I think that rel-engs would kill us. We already have a non-bootstrap rebuild check in Koschei <http://koschei.cloud.fedoraproject.org/groups/perl-sig?order_by=-state%2Cname>.

> Adding bootstrap-dependent Requires (as opposed to bootstrap-dependent
> RuildRequires) has a much bigger impact in terms of post-bootstrap rebuilds
> I think.
I understand.

Comment 14 Fedora Update System 2014-10-16 17:19:35 UTC

Package perl-Module-Starter-1.62-4.fc21, perl-Module-Build-0.42.06-2.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing perl-Module-Starter-1.62-4.fc21 perl-Module-Build-0.42.06-2.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-12959/perl-Module-Starter-1.62-4.fc21,perl-Module-Build-0.42.06-2.fc21
then log in and leave karma (feedback).

Comment 15 Fedora Update System 2014-10-28 06:45:03 UTC

perl-Module-Starter-1.62-3.fc19, perl-Module-Build-0.40.04-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 16 Fedora Update System 2014-10-28 06:45:30 UTC

perl-Module-Starter-1.62-3.fc20, perl-Module-Build-0.40.07-4.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 17 Fedora Update System 2014-11-01 16:32:17 UTC

perl-Module-Starter-1.62-4.fc21, perl-Module-Build-0.42.06-2.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.