Search

Tools

Perl/Tips

From FedoraProject

This page is intended to be a repository of "gotchas", and other little quick fixes, that aren't rare but are just uncommon enough that you forget how you did it last time:) This page is NOT part of the official packaging guidelines.

Module version dependencies too much specific

Rounding approach

When writing (Build)Requires, you can find the package requires or uses module
Foo in very specific version (e.g. use Foo 0.2001;). If you just
copy the version to spec file (Requires: perl(Foo) >= 0.2001) you
can get unresolved depencecies because packaged perl-Foo's provide shorter
version numbers (e.g. perl(Foo) = 0.16, perl(Foo)
= 0.20, perl(Foo) = 0.30).

This is caused by the fact that Perl processes version strings as fractional
numbers, but RPM as integers (e.g. RPM compares 0 to 0, and 2001 to 30).

There is no right solution. Current practice is to round dependency version up
onto the the same number of digits as package version. (e.g. Requires:
perl(Foo) >= 0.2001 becomes Requires: perl(Foo) >= 0.21).
Of course this approach is meaningful only if current perl-Foo package has at
least version 0.21.

If required package does not exist in requested version, the dependency
package must be upgraded before (if upstream provides newer (e.g. version
0.30)). If highest upstream provides 0.2001 only, dependency package can be
upgraded to provide perl(Foo) = 0.2001, however its maintainer must keep using
augmented precision in future versions (e.g. instead of Provides:
perl(Foo) = 0.30 she must write Provides: perl(Foo)
= 0.3000) not to break RPM version comparison (each newer packager must
have EVR string greater than previous one).

Dot approach

In the feature, one could consider different less error-prone approach: Instead of version
rounding, one could transform each fraction version digit to next level version
integer.

E.g. CPAN 12.34 became RPM 12.3.4. This method preserves ordering of fraction numbers, allows extending to more specific numbers and does not request package maintainer to remember number of augmented digits he needs to support in his SPEC file.

One must note that transition to this method can happen only at major version number change (the part before decimal dot) or at cost of new RPM epocha number.

Makefile.PL vs Build.PL

Perl modules typically utilize one of two different build systems:

ExtUtils::MakeMaker

Module::Build

The two different styles are easily recognizable: ExtUtils::MakeMaker employs the Makefile.PL file, and it's the 'classical' approach; Module::Build is the (relatively) new kid on the block, with support for things ExtUtils::MakeMaker cannot do. While Module::Build was designed as a long-term replacement for ExtUtils::MakeMaker, it turned out that Module::Build lacks proper upstream maintenance thus favoring Module::Build does not look like a good idea now.

There are more build systems:

ExtUtils::MakeMaker

make pure_install DESTDIR – Since 6.06_01 (all Fedoras), it's possible to use standard DESTDIR argument to make (pure_)install action instead of old PERL_INSTALL_ROOT. It points to root where files are installed to. It's recommended to apply this change to cpanspec output.

make pure_install – make install modifies global perllocal.pod log file to list all installed Perl distributions. This duplicates and clashes with RPM infrastructure. So one has to use pure_install instead of the install to disable the perllocal.pod feature. This is implemented in cpanspec already.

Module::Build::Tiny

Simplified reimplementation of Module::Build. Beware it does not support destdir=foo syntax like Module::Build, one has to use --destdir=foo (CPAN RT #85006).

inc::Module::Install

Bundled ExtUtils::MakeMaker guts. Upstream ships ExtUtils::MakeMaker modules in ./inc directory. While bundling configure-time dependencies is allowed in Fedora, one has to declare all used ./inc modules dependencies which is painful and error prone. Easier way is to prune ./inc and build-require relevant modules.

Tests

Tests / build steps requiring network access

This happens from time to time. Some package's tests (or other steps, e.g. signature validation) require network access to return success, but their actual execution isn't essential to the proper building of the package. In these cases, it's often nice to have a simple, transparent, clean way of enabling these steps on your local system (for, e.g., maximum testing), but to have them disabled when actually run through the buildsys/mock.

One easy way to do this is with the "--with" system of conditionals rpmbuild can handle. Running, e.g., "rpmbuild --with network_tests foo.src.rpm" is analagous to including a "--define '_with_network_tests 1'" on the command line. We can test for the existance of that conditional, and take (or not take!) certain actions based on it.

See, e.g., the perl-POE-Component-Client-HTTP spec file for an example.

One way to indicate this inside your spec is to prepend a notice along the lines of:

# some text
# about the change

Then, at the point of the operation, e.g. "make test", that needs to be disabled silently under mock to enable the package build to succeed:

Now to execute local builds with the network bits enabled, either call rpmbuild with "--with network_tests" or add the line "%_with_network_tests 1" to your ~/.rpmmacros file. Remember to test with _with_network_tests undefined before submitting to the buildsys, to check for syntax errors!

Tests require X11 server

Some Perl bindings to graphical toolkits deliver tests that require access to X11 server. rpmbuild was changing its opinion on DISPLAY environment variable. Currently the variable is unset when running locally or in Koji. If you want to run X11 tests, and you want it, you could do it using Xvfb X11 server implementation:

If you want to have unified spec file for all Fedoras, you can use both of them, but remember %__*_exclude style inhibits %filter_* style and %__*_exclude style is supported since rpm 4.9. If you use %perl_default_filter, you need to put it in between the two styles to take effect properly (see some early Fedora 16 packages for examples).

Since Fedora 16, %perl_default_filter uses %__*_exclude style, so if you use %perl_default_filter, you need to define filtering in the %__*_exclude style too.

Modules provided by private shared objects are not auto-provided by rpmbuild

According Paul Howarth, unversioned Provides satisfies versioned requires. E.g. if perl-Foo requires perl(Statistics::Basic::ComputedVector) >= 2.000 it will be satisfied by perl-Statistics-Basic-1.6602 because it provides perl(Statistics::Basic::ComputedVector).

IMHO, it sounds like a bug in RPM, you can patch it by following Provides filtering:

Problem

Solution

Convert the errant file to UTF-8. Assuming the codepage the file is currently under is ISO-8859-1, this will do the trick (often by reviewers wanted in %prep section, in %build for generated man pages):

cd blib/man3
for i in Docs::ReadMe.3pm Attribute.3pm ; do
iconv --from=ISO-8859-1 --to=UTF-8 Class::MakeMethods::$i > new
mv new Class::MakeMethods::$i
done

If you are using iconv, you should be BR'ing it, but it's in glibc-common, which is installed anyway...

private-shared-object-provides

Problem

The Map.so is a private shared library dynamically loaded by XS loader when a Perl binding to a C library is called. These files are not intended for public use and they must be filtered from Provides. In addition, the files have name similar to original C libraries which can clashes while resolving RPM dependencies while installing packages.

New Perl specific spec file macros

If you find out that some code snippets repeat in your spec files, you could say: Hey, there should be a macro for that! Then propose the macro for inclusion into /etc/rpm/macros.perl. The file is owned by perl package and is automatically included by rpmbuild tool. Ask perl package maintainer for adding the macro.