Contents
Rules
Dependencies
No explicit dependency should be needed. rpm automatically adds a versioned dependency on perl-base, and scans files for additional perl module dependencies (both required and provided).
Using upstream dependencies
Most perl modules are shipping a META.json or META.yml file to provide meta-information. If you ship this file in %doc (in %file section), then it will be used to extract the perl dependencies. This way, almost all prereq errors can be reported upstream.
This is the preferred way of working.
Manual tweaking
If no META.{json|yml} is present or the scan fails to find some dependencies, you have to provide them explicitly:
Requires: perl(Foo) Provides: perl(Bar)
If this scan produces incorrect dependencies, you have to filter them:
%global __provides_exclude perl\\(Foo\\) %global __requires_exclude perl\\(Bar\\)
Note that one should use the strings “\\|” for alternation as well as “\\(” and “\\)” for actual parentheses and "(" and ")" for grouping.
Build Dependencies
The minimum build dependencies are:
- perl(Module::Build) if using Module::Build
- perl-devel unconditionally for native packages
In order to be independent of exact module location (either in its own package or part of a standard perl library), build dependencies on additional perl modules should be expressed on perl modules, with automatic dependency syntax:
BuildRequires: perl(Foo::Bar)
And not on the perl package itself:
BuildRequires: perl-Foo-Bar
Naming
All modules should be called perl-Foo-Bar, with Foo-Bar standing for the name of the CPAN distribution used. (These names are often, but not always, related to the main Perl module of the distribution, e.g. Foo::Bar.)
rpmlint check: perl prefix checking done, namespace checking to do.
Versioning
Perl modules use numerical version numbers, whereas rpm uses alphanumerical version numbers, causing repeated ordering troubles. For instance DateTime 0.2901 is supposed to be an earlier release than 0.31...
For this reason, we normalize all perl modules version through %perl_convert_version macro:
%define upstream_name Config-Model
%define upstream_version 0.636
Name: perl-%{upstream_name}
Version: %perl_convert_version %{upstream_version}
Release: %mkrel 1
Sources URL
Maintainer-based sources URL, such as http://search.cpan.org/CPAN/authors/id/F/FO/FOO/%{module}-%{version}.tar.bz2, are not stable enough, as distribution maintainer may change without notice. Better use distribution-based URL: http://www.cpan.org/modules/by-module/FOO/%{module}-%{version}.tar.bz2.
Also, FTP download behind a firewall is a pain, hence the preference for HTTP URLs.
URL
All modules coming from CPAN should have the proper unversioned URL tag defined to http://search.cpan.org/dist/%{module} (except a few special cases where they have their own project site, see for example perl-DBI).
rpmlint check: to do
Man pages
Man pages should be generated from POD. Some modules define INSTALLMAN3DIR => 'none' in Makefile.PL, just delete this entry to revert to default behaviour.
rpmlint check: to do
Installation directory
Perl modules should be installed under vendor_perl hierarchy, not under default site_perl hierarchy. Just add the option INSTALLDIRSvendor= when generating the Makefile:
%{__perl} Makefile.PL INSTALLDIRS=vendor
or, if the module uses the Module::Build or Module::Build::Tiny frameworsk instead of ExtUtils::MakeMaker,
%{__perl} Build.PL --installdirs=vendor
(The double-dash - "--" before the installdirs is for Module::Build::Tiny compatibility).
rpmlint check: done
Note: for Module::Build, you later need to use these commands:
# In %build ./Build
# In %check ./Build test
# In %install
./Build install --destdir=%{buildroot}
(The "--destdir" instead of "destdir" is needed for Module::Build::Tiny compatibility.).
Directory ownership
Perl packages should own all directories containing files that are located under the vendor_perl hierarchy top-directory. This is required by the fact that perl namespace organisation is not related to inheritance, meaning there is no warranty that package perl-Foo-Bar will depend on package perl-Foo. As a consequence, perl-Foo-Bar needs to own the Foo directory, otherwise it's installation and removal is likely to leave an unowned directory Foo on the system.
The usual way to achieve this in %file section is:
%{perl_vendorlib}/Foo
or, for native packages:
%{perl_vendorarch}/Foo
%{perl_vendorarch}/auto/Foo
rpmlint check: to do
Executables
One can fix the sha-bang in executables under /usr/bin/ to point to /usr/bin/perl (instead of /usr/bin/perl5.18.1 or whatever which is what the Perl installation tool use) using the following snippet in the %install stage:
perl -i -lpe 's{^(#\!/usr/bin/perl).*}{$1} if $. == 1' %{buildroot}/%{_bindir}/*
Tools
The official tool to generate an rpm directly from CPAN modules is cpan2dist, with the Mageia backend CPANPLUS-Dist-Mageia.
# urpmi perl-CPANPLUS-Dist-Mageia [... later on ...] $ cpan2dist --format CPANPLUS::Dist::Mageia Module::To::Transform::In::Rpm
In order not have to specify the format parameter each time, you can update the dist_type line in ~/.cpanplus/lib/CPANPLUS/Config/User.pm to read:
$conf->set_conf( dist_type => 'CPANPLUS::Dist::Mageia' );
The tool cpan2pkg is a wrapper around CPANPLUS::Dist::Mageia and takes care of calling cpan2dist, importing the package in svn and submitting it to the build-system. It also takes care of the dependencies, building the rpms in order and waiting for them to be available on build-system before continuing.
# urpmi cpan2pkg [... later on ...] $ cpan2pkg Module::To::Transform::In::Rpm
magpie
magpie is a tool for updating packages from CPAN using a local minicpan mirror. For more information see this page on perl-begin and the links there.
Authors
- Vincent Danen
- Jérôme Quelin
- Guillaume Rousse
- Thierry Vignaud
- Rémy Clouard
- Shlomi Fish
