Difference between revisions of "Perl package guidelines"

From ArchWiki
Jump to: navigation, search
m (codeline -> ic)
Line 7: Line 7:
  
 
==File Placement==
 
==File Placement==
Perl modules should install module files in {{Filename|/usr/lib/perl5/vendor_perl/}} (this is done by setting the {{Ic|INSTALLDIRS}} variable as shown below). No files should be stored in {{Filename|/usr/lib/perl5/site_perl/}} as that directory is reserved for use by the system administrator to install Perl packages outside the package management system. The files {{Filename|perllocal.pod}} and {{Filename|.packlist}} also should not be present; this is taken care of by the example [[PKGBUILD]] given below.
+
Perl modules should install module files in {{ic|/usr/lib/perl5/vendor_perl/}} (this is done by setting the {{Ic|INSTALLDIRS}} variable as shown below). No files should be stored in {{ic|/usr/lib/perl5/site_perl/}} as that directory is reserved for use by the system administrator to install Perl packages outside the package management system. The files {{ic|perllocal.pod}} and {{ic|.packlist}} also should not be present; this is taken care of by the example [[PKGBUILD]] given below.
  
 
==Example==
 
==Example==
An example PKGBUILD can be found at {{Filename|/usr/share/pacman/PKGBUILD-perl.proto}}, which is in the {{Package Official|abs}} package. It is also reproduced below:
+
An example PKGBUILD can be found at {{ic|/usr/share/pacman/PKGBUILD-perl.proto}}, which is in the {{Package Official|abs}} package. It is also reproduced below:
 
<pre>
 
<pre>
 
# Maintainer: Your Name <youremail@domain.com>
 
# Maintainer: Your Name <youremail@domain.com>
Line 78: Line 78:
  
 
====Module====
 
====Module====
Modules are declared with the {{Ic|package}} keyword in perl.  Modules are contained inside a {{Filename|.pm}} ("dot-pee-em") file.  Though it's possible more than one module ({{Ic|package}}) is in the file.  Modules have namespaces separated with {{Ic|::}} (double colons), like: {{Ic|Archlinux::Module}}.  When loading a module, the {{Ic|::}}s are replaced with directory separators.  For example: {{Filename|Archlinux/Module.pm}} will be loaded for the module {{Ic|Archlinux::Module}}.
+
Modules are declared with the {{Ic|package}} keyword in perl.  Modules are contained inside a {{ic|.pm}} ("dot-pee-em") file.  Though it's possible more than one module ({{Ic|package}}) is in the file.  Modules have namespaces separated with {{Ic|::}} (double colons), like: {{Ic|Archlinux::Module}}.  When loading a module, the {{Ic|::}}s are replaced with directory separators.  For example: {{ic|Archlinux/Module.pm}} will be loaded for the module {{Ic|Archlinux::Module}}.
  
 
====Core Module====
 
====Core Module====
Line 84: Line 84:
  
 
====Distributions====
 
====Distributions====
(aka dist, package)  This is the equivalent of an Archlinux package in CPAN-lingo.  Distributions are {{Filename|.tar.gz}} archives full of files.  These archives contain primarily .pm module files, tests for the included modules, documentation for the modules, and whatever else is deemed necessary.
+
(aka dist, package)  This is the equivalent of an Archlinux package in CPAN-lingo.  Distributions are {{ic|.tar.gz}} archives full of files.  These archives contain primarily .pm module files, tests for the included modules, documentation for the modules, and whatever else is deemed necessary.
  
Usually a distribution contains a primary module with the same name.  Sometimes this is not true, like with the Template-Toolkit distribution.  The latest package, {{Filename|Template-Toolkit-2.22.tar.gz}}, for the {{Ic|Template-Toolkit}} dist, contains no {{Ic|Template::Toolkit}} module!
+
Usually a distribution contains a primary module with the same name.  Sometimes this is not true, like with the Template-Toolkit distribution.  The latest package, {{ic|Template-Toolkit-2.22.tar.gz}}, for the {{Ic|Template-Toolkit}} dist, contains no {{Ic|Template::Toolkit}} module!
  
 
Sometimes because distributions are named after a main module, their names are used interchangeably and they get muddled together.  However it is sometimes useful to consider them a separate entity (like in Template-Toolkit's case).
 
Sometimes because distributions are named after a main module, their names are used interchangeably and they get muddled together.  However it is sometimes useful to consider them a separate entity (like in Template-Toolkit's case).
Line 93: Line 93:
 
A subtle problem is that advanced perl programmers may like to have multiple versions of perl installed. This is useful for testing backwards-compatibility in created programs. There are also speed benefits to compiling your own custom perl interpreter (i.e. without threads). Another reason for a custom ''perl'' is simply because the official perl ArchLinux package sometimes lags behind perl releases. The user may be trying out the latest perl... who knows?
 
A subtle problem is that advanced perl programmers may like to have multiple versions of perl installed. This is useful for testing backwards-compatibility in created programs. There are also speed benefits to compiling your own custom perl interpreter (i.e. without threads). Another reason for a custom ''perl'' is simply because the official perl ArchLinux package sometimes lags behind perl releases. The user may be trying out the latest perl... who knows?
  
If the user has the custom perl executable in their {{Ic|$PATH}}, the custom perl will be run when the user types the ''perl'' command on the shell. In fact the custom perl will run inside the {{Filename|PKGBUILD}} as well! This can lead to insidious problems that are difficult to understand.
+
If the user has the custom perl executable in their {{Ic|$PATH}}, the custom perl will be run when the user types the ''perl'' command on the shell. In fact the custom perl will run inside the {{ic|PKGBUILD}} as well! This can lead to insidious problems that are difficult to understand.
  
The problem lies in compiled XS modules. These modules bridge perl and C. As such they must use perl's internal C API to accomplish this bridge. Perl's C API changes slightly with different versions of perl. If the user has a different version of perl than the system perl ({{Filename|/usr/bin/perl}}) then any XS module compiled with the user's perl will be incompatible with the system-wide perl. When trying to use the compiled XS module with the system perl, the module will fail to load with a link error.
+
The problem lies in compiled XS modules. These modules bridge perl and C. As such they must use perl's internal C API to accomplish this bridge. Perl's C API changes slightly with different versions of perl. If the user has a different version of perl than the system perl ({{ic|/usr/bin/perl}}) then any XS module compiled with the user's perl will be incompatible with the system-wide perl. When trying to use the compiled XS module with the system perl, the module will fail to load with a link error.
  
A simple solution is to always use the absolute path of the system-wide perl interpreter ({{Filename|/usr/bin/perl}}) when running perl in the {{Filename|PKGBUILD}}.
+
A simple solution is to always use the absolute path of the system-wide perl interpreter ({{ic|/usr/bin/perl}}) when running perl in the {{ic|PKGBUILD}}.
  
 
===Installation Modules===
 
===Installation Modules===
Line 106: Line 106:
 
====ExtUtils::MakeMaker====
 
====ExtUtils::MakeMaker====
  
;Build script: {{Filename|Makefile.PL}}
+
;Build script: {{ic|Makefile.PL}}
 
;CPAN link: http://search.cpan.org/dist/ExtUtils-MakeMaker
 
;CPAN link: http://search.cpan.org/dist/ExtUtils-MakeMaker
  
The original, oldest module for installing modules is {{Ic|ExtUtils::MakeMaker}}.  The major downside to this module is that it requires the {{Filename|make}} program to build and install everything.  This may not seem like a big deal to linux users but is a real hassle for Windows people!  In the name of progress the perl community is trying to encourage people to use the newer modules instead.
+
The original, oldest module for installing modules is {{Ic|ExtUtils::MakeMaker}}.  The major downside to this module is that it requires the {{ic|make}} program to build and install everything.  This may not seem like a big deal to linux users but is a real hassle for Windows people!  In the name of progress the perl community is trying to encourage people to use the newer modules instead.
  
 
====Module::Build====
 
====Module::Build====
  
;Build script: {{Filename|Build.PL}}
+
;Build script: {{ic|Build.PL}}
 
;CPAN link: http://search.cpan.org/dist/Module-Build
 
;CPAN link: http://search.cpan.org/dist/Module-Build
  
The main advantage of Module::Build is that it is pure-perl.  This means it does not require a {{Filename|make}} program to be installed for you to build/install modules.  Its adoption was rocky because if {{Ic|Module::Build}} was not already installed, you could not run the bundled {{Filename|Build.PL}} script!  This is not a problem with recent versions of perl because {{Ic|Module::Build}} is a core module.
+
The main advantage of Module::Build is that it is pure-perl.  This means it does not require a {{ic|make}} program to be installed for you to build/install modules.  Its adoption was rocky because if {{Ic|Module::Build}} was not already installed, you could not run the bundled {{ic|Build.PL}} script!  This is not a problem with recent versions of perl because {{Ic|Module::Build}} is a core module.
  
 
====Module::Install====
 
====Module::Install====
  
;Build script: {{Filename|Makefile.PL}}
+
;Build script: {{ic|Makefile.PL}}
 
;CPAN link: http://search.cpan.org/dist/Module-Install
 
;CPAN link: http://search.cpan.org/dist/Module-Install
  
Another modern build/installation module, {{Ic|Module::Install}} still requires the {{Filename|make}} program be installed to function.  It was designed as a drop-in replacement for {{Ic|ExtUtils::MakeMaker}}, to address some of {{Ic|MakeMaker}}'s shortcomings.   
+
Another modern build/installation module, {{Ic|Module::Install}} still requires the {{ic|make}} program be installed to function.  It was designed as a drop-in replacement for {{Ic|ExtUtils::MakeMaker}}, to address some of {{Ic|MakeMaker}}'s shortcomings.   
  
 
One very interesting feature is that {{Ic|Module::Install}} bundles a ''complete'' ''copy'' of itself into the distribution file.  Because of this, unlike {{Ic|MakeMaker}} or {{Ic|M::B}}, you do not need {{Ic|Module::Install}} to be installed on your system.
 
One very interesting feature is that {{Ic|Module::Install}} bundles a ''complete'' ''copy'' of itself into the distribution file.  Because of this, unlike {{Ic|MakeMaker}} or {{Ic|M::B}}, you do not need {{Ic|Module::Install}} to be installed on your system.
  
Another very unique feature is auto-install.  ''This appears to be not recommended, but seems used quite often.''  When the module author enables auto-install for his distribution, {{Ic|Module::Install}} will search for and install any pre-requisite modules that are not installed when {{Filename|Makefile.PL}} is executed.  This feature is skipped when {{Ic|Module::Install}} detects it is being run by {{Ic|CPAN}} or {{Ic|CPANPLUS}}.  However, this feature is not skipped when run inside... oh I don't know... a '''PKGBUILD'''!  I hope you can see how a rogue perl program downloading and installing modules willy-nilly ''inside a PKGBUILD'' can be a problem.  See the [[#PERL_AUTOINSTALL]] environment variable to see how to fix this.
+
Another very unique feature is auto-install.  ''This appears to be not recommended, but seems used quite often.''  When the module author enables auto-install for his distribution, {{Ic|Module::Install}} will search for and install any pre-requisite modules that are not installed when {{ic|Makefile.PL}} is executed.  This feature is skipped when {{Ic|Module::Install}} detects it is being run by {{Ic|CPAN}} or {{Ic|CPANPLUS}}.  However, this feature is not skipped when run inside... oh I don't know... a '''PKGBUILD'''!  I hope you can see how a rogue perl program downloading and installing modules willy-nilly ''inside a PKGBUILD'' can be a problem.  See the [[#PERL_AUTOINSTALL]] environment variable to see how to fix this.
  
 
===Environment Variables===
 
===Environment Variables===
A number of environment variables can affect the way the modules are built or installed.  Some have a very dramatic effect and can cause problems if misunderstood.  An advanced user could be using these environment variables.  Some of these will break an unsuspecting {{Filename|PKGBUILD}}; or cause unexpected behavior.
+
A number of environment variables can affect the way the modules are built or installed.  Some have a very dramatic effect and can cause problems if misunderstood.  An advanced user could be using these environment variables.  Some of these will break an unsuspecting {{ic|PKGBUILD}}; or cause unexpected behavior.
  
 
====PERL_MM_USE_DEFAULT====
 
====PERL_MM_USE_DEFAULT====
Line 136: Line 136:
  
 
====PERL_AUTOINSTALL====
 
====PERL_AUTOINSTALL====
You can pass additional command-line arguments to {{Ic|Module::Install}}'s {{Filename|Makefile.PL}} with this variable.  In order to turn off auto-install (''highly recommended''), assign {{Ic|--skipdeps}} to this.
+
You can pass additional command-line arguments to {{Ic|Module::Install}}'s {{ic|Makefile.PL}} with this variable.  In order to turn off auto-install (''highly recommended''), assign {{Ic|--skipdeps}} to this.
  
 
<pre>export PERL_AUTOINSTALL='--skipdeps'</pre>
 
<pre>export PERL_AUTOINSTALL='--skipdeps'</pre>
  
 
====PERL_MM_OPT====
 
====PERL_MM_OPT====
You can pass additional command-line arguments to {{Filename|Makefile.PL}} and/or {{Filename|Build.PL}} with this variable.  For example, you can install modules into your home-dir by using:
+
You can pass additional command-line arguments to {{ic|Makefile.PL}} and/or {{ic|Build.PL}} with this variable.  For example, you can install modules into your home-dir by using:
  
 
<pre>export PERL_MM_OPT=INSTALLBASE=~/perl5</pre>
 
<pre>export PERL_MM_OPT=INSTALLBASE=~/perl5</pre>
Line 151: Line 151:
  
 
====MODULEBUILDRC====
 
====MODULEBUILDRC====
{{Ic|Module::Build}} allows you to override its command-line-arguments with an rcfile.  This defaults to {{Filename|~/.modulebuildrc}}.  You can override which file it uses by setting the path to the rcfile in {{Ic|MODULEBUILDRC}}.  The paranoid might set {{Ic|MODULEBUILDRC}} to {{Filename|/dev/null}}... just in case.
+
{{Ic|Module::Build}} allows you to override its command-line-arguments with an rcfile.  This defaults to {{ic|~/.modulebuildrc}}.  You can override which file it uses by setting the path to the rcfile in {{Ic|MODULEBUILDRC}}.  The paranoid might set {{Ic|MODULEBUILDRC}} to {{ic|/dev/null}}... just in case.
  
 
===Hardened Example===
 
===Hardened Example===

Revision as of 11:08, 13 February 2012


This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.


Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어


External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی

Package Naming

For modules the package name should begin with perl- and the rest of the name should be constructed from the module name by converting it to lowercase and then replacing colons with hyphens. For example the package name corresponding to HTML::Parser will be perl-html-parser. Perl applications should have the same name as that of the application but in lowercase.

File Placement

Perl modules should install module files in /usr/lib/perl5/vendor_perl/ (this is done by setting the INSTALLDIRS variable as shown below). No files should be stored in /usr/lib/perl5/site_perl/ as that directory is reserved for use by the system administrator to install Perl packages outside the package management system. The files perllocal.pod and .packlist also should not be present; this is taken care of by the example PKGBUILD given below.

Example

An example PKGBUILD can be found at /usr/share/pacman/PKGBUILD-perl.proto, which is in the Template:Package Official package. It is also reproduced below:

# Maintainer: Your Name <youremail@domain.com>
_author=AUTHOR_NAME
_perlmod=MODNAME
pkgname=perl-$_perlmod
pkgver=VERSION
pkgrel=1
pkgdesc=""
arch=()
url="http://search.cpan.org/~$_author/$_perlmod-$pkgver/"
license=('GPL' 'PerlArtistic')
groups=()
depends=('perl>=5.10.0')
makedepends=()
provides=()
conflicts=()
replaces=()
backup=()
options=(!emptydirs)
install=
source=(http://cpan.perl.org/modules/by-authors/id/$_author/$_perlmod-$pkgver.tar.gz)
md5sums=()

build() {
  cd "$srcdir/$_perlmod-$pkgver"

  # Install module in vendor directories.
  PERL_MM_USE_DEFAULT=1 perl Makefile.PL INSTALLDIRS=vendor
  make

  ## For packages with Build.PL, do this instead:
  # perl Build.PL installdirs=vendor destdir="$pkgdir/"
  # perl Build
}

package() {
  cd "$srcdir/$_perlmod-$pkgver"
  make install DESTDIR="$pkgdir/"

  ## For packages with Build.PL, do this instead:
  # perl Build install
}

# vim:set ts=2 sw=2 et:

In most cases, you should put any in the arch array since most Perl packages are architecture independent.

Automation

As Perl is centered around the CPAN, there are a few scripts to make the most of this, and save you writing PKGBUILDs by hand.

The more perlish method is to use a CPANPLUS::Dist plugin for installing CPAN modules as dynamically generated pacman packages, available at http://aur.archlinux.org/packages.php?ID=24971

Warning: Pacpan development has been officially discontinued: its latest version does not work with pacman>=3.5. See [1].

There is also a script called pacpan, which can recursively generate PKGBUILDs for a module: http://xyne.archlinux.ca/old_projects/pacpan/

It is worth mentioning that Bauerbill has similar support for generating PKGBUILDs to pacpan. As well as adding the ability to upgrade all installed CPAN modules directly from CPAN via a pacman interface. Make sure to read the Bauerbill man file for usage instructions.

Warning: Bauerbill development has been officially discontinued: its latest version does not work with pacman>=3.5. See [2].

Advanced Topics

If the packager has become comfortable enough with creating perl packages, the below sections may offer some new ideas to consider. This information might also help troubleshooting packaging problems.

Glossary

You should be familiar with the following terms.

Module

Modules are declared with the package keyword in perl. Modules are contained inside a .pm ("dot-pee-em") file. Though it's possible more than one module (package) is in the file. Modules have namespaces separated with :: (double colons), like: Archlinux::Module. When loading a module, the ::s are replaced with directory separators. For example: Archlinux/Module.pm will be loaded for the module Archlinux::Module.

Core Module

Core modules are included with an installation of perl. Some core modules are only available bundled with perl. Other modules can still be downloaded and installed separately from CPAN.

Distributions

(aka dist, package) This is the equivalent of an Archlinux package in CPAN-lingo. Distributions are .tar.gz archives full of files. These archives contain primarily .pm module files, tests for the included modules, documentation for the modules, and whatever else is deemed necessary.

Usually a distribution contains a primary module with the same name. Sometimes this is not true, like with the Template-Toolkit distribution. The latest package, Template-Toolkit-2.22.tar.gz, for the Template-Toolkit dist, contains no Template::Toolkit module!

Sometimes because distributions are named after a main module, their names are used interchangeably and they get muddled together. However it is sometimes useful to consider them a separate entity (like in Template-Toolkit's case).

User-Installed perl

A subtle problem is that advanced perl programmers may like to have multiple versions of perl installed. This is useful for testing backwards-compatibility in created programs. There are also speed benefits to compiling your own custom perl interpreter (i.e. without threads). Another reason for a custom perl is simply because the official perl ArchLinux package sometimes lags behind perl releases. The user may be trying out the latest perl... who knows?

If the user has the custom perl executable in their $PATH, the custom perl will be run when the user types the perl command on the shell. In fact the custom perl will run inside the PKGBUILD as well! This can lead to insidious problems that are difficult to understand.

The problem lies in compiled XS modules. These modules bridge perl and C. As such they must use perl's internal C API to accomplish this bridge. Perl's C API changes slightly with different versions of perl. If the user has a different version of perl than the system perl (/usr/bin/perl) then any XS module compiled with the user's perl will be incompatible with the system-wide perl. When trying to use the compiled XS module with the system perl, the module will fail to load with a link error.

A simple solution is to always use the absolute path of the system-wide perl interpreter (/usr/bin/perl) when running perl in the PKGBUILD.

Installation Modules

One of perl's greatest advantages is the sheer number of modules[/dists] available on CPAN. Not too surprisingly, there are also several different modules used for installing... well... modules! TMTOWTDI! I am not aware of a standard name for these types of modules, so I just called them "Installation Modules".

All these modules are concerned with is building the package and installing wherever the user wants. This seems straightforward, but considering the number of different systems perl runs on, this can get complex. These modules all place a perl code file inside the dist tarball. Running this perl script will initiate the build/installation process. I have called this the "Build script" in the below list.

ExtUtils::MakeMaker

Build script
Makefile.PL
CPAN link
http://search.cpan.org/dist/ExtUtils-MakeMaker

The original, oldest module for installing modules is ExtUtils::MakeMaker. The major downside to this module is that it requires the make program to build and install everything. This may not seem like a big deal to linux users but is a real hassle for Windows people! In the name of progress the perl community is trying to encourage people to use the newer modules instead.

Module::Build

Build script
Build.PL
CPAN link
http://search.cpan.org/dist/Module-Build

The main advantage of Module::Build is that it is pure-perl. This means it does not require a make program to be installed for you to build/install modules. Its adoption was rocky because if Module::Build was not already installed, you could not run the bundled Build.PL script! This is not a problem with recent versions of perl because Module::Build is a core module.

Module::Install

Build script
Makefile.PL
CPAN link
http://search.cpan.org/dist/Module-Install

Another modern build/installation module, Module::Install still requires the make program be installed to function. It was designed as a drop-in replacement for ExtUtils::MakeMaker, to address some of MakeMaker's shortcomings.

One very interesting feature is that Module::Install bundles a complete copy of itself into the distribution file. Because of this, unlike MakeMaker or M::B, you do not need Module::Install to be installed on your system.

Another very unique feature is auto-install. This appears to be not recommended, but seems used quite often. When the module author enables auto-install for his distribution, Module::Install will search for and install any pre-requisite modules that are not installed when Makefile.PL is executed. This feature is skipped when Module::Install detects it is being run by CPAN or CPANPLUS. However, this feature is not skipped when run inside... oh I don't know... a PKGBUILD! I hope you can see how a rogue perl program downloading and installing modules willy-nilly inside a PKGBUILD can be a problem. See the #PERL_AUTOINSTALL environment variable to see how to fix this.

Environment Variables

A number of environment variables can affect the way the modules are built or installed. Some have a very dramatic effect and can cause problems if misunderstood. An advanced user could be using these environment variables. Some of these will break an unsuspecting PKGBUILD; or cause unexpected behavior.

PERL_MM_USE_DEFAULT

When this variable is set to a true value, the installation module will pretend the default answer was given to any question it would normally ask. This does not always work, but all of the installation modules honour it. That doesn't mean the module author will!

PERL_AUTOINSTALL

You can pass additional command-line arguments to Module::Install's Makefile.PL with this variable. In order to turn off auto-install (highly recommended), assign --skipdeps to this.

export PERL_AUTOINSTALL='--skipdeps'

PERL_MM_OPT

You can pass additional command-line arguments to Makefile.PL and/or Build.PL with this variable. For example, you can install modules into your home-dir by using:

export PERL_MM_OPT=INSTALLBASE=~/perl5

PERL_MB_OPT

This is the same thing as PERL_MM_OPT except it is only for Module::Build. For example, you could install modules into your home-dir by using:

export PERL_MB_OPT=--install_base=~/perl5

MODULEBUILDRC

Module::Build allows you to override its command-line-arguments with an rcfile. This defaults to ~/.modulebuildrc. You can override which file it uses by setting the path to the rcfile in MODULEBUILDRC. The paranoid might set MODULEBUILDRC to /dev/null... just in case.

Hardened Example

Using all of our new accumulated knowledge, we can create a more hardened PKGBUILD that will resist any environment variables' attempts to sabotage it:

# Contributor: Your Name <youremail@domain.com>
pkgname=perl-foo-bar
pkgver=VERSION
pkgrel=1
pkgdesc='This is the awesome Foo::Bar module!'
arch=('any')
url='http://search.cpan.org/dist/Foo-Bar'
license=('GPL' 'PerlArtistic')
depends=('perl>=5.10.0')
makedepends=()
provides=()
conflicts=()
replaces=()
backup=()
options=(!emptydirs)
install=
source=("http://search.cpan.org/CPAN/authors/id/***/***-$pkgver.tar.gz")
md5sums=()

build() {
  cd "$srcdir/***-$pkgver"
  
  # Setting these env variables overwrites any command-line-options we don't want...
  export PERL_MM_USE_DEFAULT=1 PERL_AUTOINSTALL=--skipdeps \
    PERL_MM_OPT="INSTALLDIRS=vendor DESTDIR='$pkgdir'" \
    PERL_MB_OPT="--installdirs vendor --destdir '$pkgdir'" \
    MODULEBUILDRC=/dev/null

  # If using Makefile.PL
  { /usr/bin/perl Makefile.PL &&
    make &&
    make test &&
    make install; } || return 1

  # If using Build.PL
  { /usr/bin/perl Build.PL &&
    ./Build &&
    ./Build test &&
    ./Build install; } || return 1

  # remove perllocal.pod and .packlist
  find "$pkgdir" -name .packlist -o -name perllocal.pod -delete