Perl5 CPAN Module Metadata Best Practices

When I started working at SUSE, one of the first things I worked on is the maintenance of the perl modules repository in the openSUSE Build Service (OBS).

We are using a tool called cpanspec to create .spec files from CPAN modules. From the spec file, the OBS then builds rpm packages.

I noticed there are a lot of modules missing information, or having other problems that prevent us from automatically create a working .spec file.

Perl has a great testing infrastructure. This helps us to see if the failures we get in OBS are present on other setups and platforms.

CPAN/PAUSE is not very strict on how a distribution should look like, though. That makes creating OS specific packages automatically harder.

Whenever I see a mistake in a CPAN module, and I have time, I try to file a bug report.

But since I came across the same common mistakes over and over, I decided to put up a page with a list of Best Practices that make it possible for most modules to be turned into a OS package automatically:

Best Practices for creating Perl5 CPAN Modules

But I need your help.

I think it would be useful to create more concrete examples. For specific items it would make sense to link to a more detailed tutorial. For example, many issues can be solved by using Dist::Zilla and the correct entries in the dist.ini.

I would be glad if, for example, Debian people could add a similar paragraph like I did for openSUSE.

Looking forward to suggestions, bug reports and pull requests

1 Comment

How does this relate to the contents of perlmodstyle? I'd then check the kwalatee metrics and ensure that Test::Quality touches all elements in your list. As with most things in life, CPAN obeys the Pareto principle. IMHO a better effort would be to target modules that are part of Task::Kensho and then suplement with others that have a high enough kwalatee.

Just my my thoughts.

Leave a comment

About tinita

user-pic just another perl punk,