Gentoo Perl Herd Guide
This document assumes a base understanding of general ebuild structure and
techniques. For more information, please see the following link.
This document is intended to highlight those places where the perl-module
ebuild differs from the average ebuild, what special variables are available,
and what the preferred structure/style should be.
If you are reading this guide because you want to submit ebuilds on bugzilla, please read this first:
Perl in the POLICY
The average perl module ebuild follows a stock structure, relying heavily on
its parent eclass, perl-module.eclass. The first active line of a
perl-module ebuild, then is:
Code Listing 1.1:
The perl-module eclass should be used for the building of any perl modules
(code that installs to /usr/$(get_libdir)/perl5 ). There is a
separate eclass for applications that need use of the perl eclass functions,
but that may not need the whole plethora. At the time of this writing the
differences between the two eclasses are minimal.
This inclusion of the perl-* eclass takes care of many of the actions
handled in an ebuild, such as whether to use Makemaker.PL or
Build.PL, pre-compile steps, documentation, etc. Some ebuilds
in the portage tree do little more than inherit this eclass and define a few
necessary items, such as HOMEPAGE, LICENSE, KEYWORDS, and SRC_URI.
Note: By default, the perl-module eclass will now default to using Makefile.PL's
and only resorting to using the Build.PL if necessary. This follows an active
discussion the p5p mailing list in which it was highlighted that this is the
preferred course by the authors of Module::Build
In regards to SRC_URI, there is one note to keep in mind. If the source of the
module/code is located on the Comprehensive Perl Archive Network (CPAN),
please use the source of mirror://cpan/, which is actually
translated as http://some.cpan.mirror/CPAN. The reason for this
is that although CPAN's multiplexer is good at locating a mirror closest to you,
it isn't perfect. By using the thirdparty mirror
($PORTDIR/profiles/thirdpartymirrors), we allow Gentoo users to
substitute their preferred mirror location.
There is one variable unique to those ebuilds that inherit the perl-module
eclass, SRC_TEST. More detail will begin further in this document in regards
to perl testing, but it is this variable that will determine whether or not a
'make test' will be performed. If SRC_TEST is set to do,
the test block within the perl-module eclass will be considered. A user must
still have test enabled in their features (/etc/make.conf) for
these tests to be performed, however.
This discussion of the SRC_TEST variable brings us to the topic of testing in
perl modules. The activation of this feature is dependant on many factors. The
short of it is, not all perl module tests are created equally. Some factors to
consider when deciding to activate tests are:
Does the test even work? Write efficient perl module tests isn't always
an task, even for the author of the module. As anyone with multiple architectures
can attest to, what works on what computer doesn't necessarily work on
another. Non-working test suites do exist, and when encountered other steps
should be taken to test the functionality of the module. Examples from pods,
while still subject to typos, are generally good ways to test that a module is
What are the tests attempting to accomplish? Even if the tests work, it
may not be wise to enable them. If it's a database module, is it relying on a
running, local database to talk to in order to determine test success? If it's
a network related module, is it attempting to do anything on the network that
might raise a sysadmin's (or firewall's) hackles? Last year (2004), a CPAN
author had to retract the tests he included in a module because of security
concerns - his test suite would download remote code and attempt to execute.
In the context of the module, that made sense, but from a security
perspective, it was less than advisable.
Do the tests depend on something more than a headless console? Many of
the graphical widget and X related modules have detailed test suites to make sure
their created items will interact appropriately. Unfortunately, they rely on
an active X display and the interaction of the user. In the non-interactive
world of Gentoo testing and installation, however, this is a problem. Again,
these are good tests to use during initial testing of the ebuild, but are not
appropriate for the masses.
Do the tests introduce their own set of dependencies? Currently,
Gentoo does not support dependencies specifically for testing purposes.
Unfortunately, module authors don't have the same perspective. A fair number
of modules utilize specialized testing module suites for their own tests, but
don't need those modules either for building or for use on the live system.
Over time, some of these extraneous modules have made their way into the tree,
and there is the potential one day for a perl test suite of modules to be
bundled into portage. At this time however, including these testing modules
as dependencies can be costly to user disk and cycle times.
Tracking dependencies, both on new and existing module ebuilds, is perhaps the
most time consuming aspect of adding a new module. There are three initial
files to check for expressed dependencies. One should not rely on the warning
output of a perl Makefile.PL to determine dependencies - this
output only displays missing dependencies in your own installation and is not
comprehensive of what dependencies are needed.
First, reading through the Makefile.PL in your favorite editor
should give a fair amount of information on what, if any, dependencies are
declared. Both the PREREQUISITE block, as well as any leading logic that
determines what is placed in the PREREQ block, will give an indication of
If present, the META.YML file can contain a break down of build
and run time dependencies. Additionaly, if present, the Build.PL
file will also indicate any dependencies for the module's building.
Unfortunately, this isn't always enough, though generally speaking it is a
fair indication. You may also need to recursively grep for use and
require statements to make sure that the author hasn't forgotten to
list anything. Generally, this last step isn't necessary, but it is important
to keep in mind, especially when dealing with new packages. This last step
will also help if there is any question on DEPEND versus RDEPEND information.
Warning: BEWARE THE TANGLED PATH OF A NEW MODULE AND IT'S DEPENDENCIES.
Adding a single new module to the tree (either to fill a dependency or for its
own sake) can lead to adding a dozen supporting modules before you are done.
Though adding to the bulk of dev-perl isn't a goal, this is an understood
risk. One should also take note of updating an existing ebuild module, though
- sometimes dependencies for a module change over time, and they need to be
checked rather than merely relying on the existing ebuild.
Be sure to keep an eye out for module dependencies that are already fulfilled
by having perl simply installed - and which perl they might have come with. If
a Makefile.PL lists Test::More => 0 as a dependency,
then there is no point in putting this into DEPEND since this was satisfied by
having a working perl. But if they depend on Test::More => 0.62,
you will need to check the virtuals directory.
perl-core/ExtUtils-MakeMaker should never be added as a dependancy to an ebuild
unless you are working on a package that requires a version greater than
the one provided by the currently stable dev-lang/perl package. It's existance in the
tree at this point is solely to provide a bridge for those users that haven't upgraded
their perl's in quite some time, but continue to use the dev-perl/perl-core portions
Version numbers in Gentoo perl ebuilds
Versioning on CPAN and versioning in the portage tree do not always align. Because a CPAN module's versioning scheme changes from author to author (and module's change hands over time), there are no consistant rules for how module's receive their version numbers. Portage, however, requires versions to follow a consistent format. Because of this, the perl team has had to employ version number minging on certain packages to compensate for the disparity, so that Gentoo's users always receive the latest version for their KEYWORDs. For example, dev-perl/module-build released version 0.28. Shortly afterwards, 0.2801-6 were released. If we had maintained these version numbers, portage would never recognize 0.29 as the successor, because in portage math (where each decimal is a number seperator, not an indication of decimal math), 29 is less than 2801. As such, the minor released of Module::Build were renamed as 0.28.05, 0.28.06, etc.
"inherit versionator" and "delete_version_serarator" are your best ally in these situations.
The contents of this document, unless otherwise expressly stated, are licensed under the CC-BY-SA-2.5 license. The Gentoo Name and Logo Usage Guidelines apply.
Page updated April 11, 2006
In which Gentoo devs attempt to explain the mechanics of the perl herd...
Donate to support our development efforts.