Difference between revisions of "Perl Policy"

From ArchWiki
Jump to: navigation, search
m (Documents)
m (maybe a seperate directory for the core modules isn't such a good idea.)
Line 52: Line 52:
Modules included in the core Perl distribution.  Also modules included in the <tt>perl-modules</tt> package.  See core-perl-modules.
Modules included in the core Perl distribution.  Also modules included in the <tt>perl-modules</tt> package.  See core-perl-modules.
* <strong><em>obsolete</em></strong>
* <strong><em>obsolete</em></strong>

Revision as of 03:35, 10 June 2007

Tango-document-new.pngThis article is a stub.Tango-document-new.png

Notes: please use the first argument of the template to provide more detailed indications. (Discuss in Talk:Perl Policy#)


This document is currently a proposal for standards regarding to the perl package, related perl packages, creating perl module packages (both in binary form and in the form of PKGBUILDs). Portions are derived from the Debian Perl Policy document, and from various portions of the perl man pages.

Current Caveats

It does not reflect the current ArchLinux perl package(s) layout. Please do not use this document as a template for creating new perl module packages... yet... This policy, if implemented - represents a major change in way Arch handles perl.


Current (apparent) problems with perl packages include:

  1. The current ArchLinux default perl installation installs site and vendor packages into the same directory tree, which frequently causes conflicts if the end user installs and upgrades bot archlinux perl (vendor) packages on top of site packages.
  2. A symlink-farm is created in /usr/lib/perl5/ and /usr/lib/perl5/site_perl.
  3. A number of standard modules seem to be missing, or were neglected to be added as provides in the perl package itself, causing confusion and redundant entries in AUR for perl modules as users try and fix the problem themselves.
  4. Current perl-module PKGBUILD's could be simplifed and standardized quite a bit.

This policy would eliminate all these problems (features!).


Current (apparent) downsides to adopting a policy such as this one:

  1. An update of every perl module PKGBUILD so that it installs into the correct (vendor) directory tree. It remains somewhat backwards-compatible with the old structure, in that old PKGBUILD's would technically work.
  2. Introduces changes into the perl package, which lives in [current], and proposes a new perl-modules package, which would live in [extra].

Perl Versions

At any given time, the package perl should represent the current stable upstream version of Perl revision 5. (see Perl 6).

Only one package may contain the /usr/bin/perl binary and that package must either be perl or a dependency of that package. In order to provide a minimal installation of Perl for use by applications without requiring the whole of Perl to be installed, the perl package contains the binary and a basic set of modules.

Module Paths

Perl searches three different locations for modules, referred to in this document as core in which modules distributed with Perl are installed, vendor for packaged modules and site for modules installed by the local administrator.

The module search path (@INC) in the Archlinux packages has been ordered to include these locations in the following order:

  • site

Modules installed by the local administrator for the current version of Perl. Typically, these modules are installed using the cpan tool, or are downloaded in source form and installed via make.

  • vendor

Packaged modules, installed via the pacman tool from current/extra or community, or built into proper archlinux packages from ABS/AUR PKGBUILDS.

  • core

Modules included in the core Perl distribution. Also modules included in the perl-modules package. See core-perl-modules.

  • obsolete

Obsolete is the pathname to modules installed prior to the establishment of this document. This path will be removed from the perl package at some point in the future.


In each of the directory pairs above, the lib component is for binary, architecture dependant(XS) modules, and share for architecture-independent (pure-perl) modules. Under no circumstances should current be used as a replacement for version. Core and site modules really do depend on the perl version for which they were installed.


The POD files and manual pages which do not refer to programs may be split out into a separate perl-doc packages, which is normal for most archlinux packages in general. This is optional however.

Manual pages distributed with Perl packages must be installed into the standard directories:


Manual pages for programs and scripts are installed into /usr/man/man1 with the extension .1perl.


Manual pages for modules are installed into /usr/man/man3 with the extension .3perl.

Binaries and Scripts

Core and Vendor
Binaries and scripts for all core and vendor packages should be installed into /usr/bin.
Binaries and scripts for all site should default to be installed into /usr/local/bin to ensure that core and vendor packages are not touched or replaced by site packages.


Site Modules are perl modules installed by the local administrator for the current version of Perl. Typically, these modules are installed using the cpan tool, or are downloaded in source form and installed via make.

Site Directories

The Perl packages must provide a mechanism for the local administrator to install modules under /usr/lib/perl5/site_perl but must not create or remove those directories.

Modules should be installed to the directories described above in Module Path site, programs to /usr/local/bin and manual pages under /usr/local/man.

Site Installation

The following commands should be sufficient in the majority of cases for the local administrator to install modules and must create directories as required:

perl Makefile.PL
make install


cpan Foo::Bar


Vendor modules are packaged modules, installed via the pacman tool which grabs pre-compiled modules from a repository, or modules which have been built into proper archlinux packages from a PKGBUILD.

Vendor Directories

The installation directory for Archlinux modules must be different from that for site modules. Some guidelines include:

  • The current Perl packaging uses the vendor directories for this purpose, which are at present as described in above as vendor.
  • No version subdirectory exists on these directories as the dependencies for packaged modules should ensure that all work with the current perl package.
  • The Perl distribution includes many modules available separately from CPAN, which may have a newer version. The intent of the @INC ordering (described above) is to allow such modules to be packaged to vendor which take precedence over the version in core. A packaged module which shadows a core module in this way must be a newer version.
  • Module packages must install manual pages into the standard directories using the extensions .1p and .3pm to ensure that no conflict arises where a packaged module duplicates a core module.
  • .packlist (used for module uninstalls) and perllocal.pod (used to record local/site installations) files should not be installed, and should be removed from the package if found.
  • Empty directories should be pruned.

Module Package Names

Perl module packages should be named for the primary module provided. The naming convention for module Foo::Bar is perl-foo-bar. Packages which include multiple modules may additionally include provides for those modules using the same convention.

Vendor Installation

A module should use the following lines in the PKGBUILD build target.

perl Makefile.PL INSTALLDIRS=vendor MAN1EXT=1p MAN3EXT=3pm

and this one to install the results into the temporary tree...

make install DESTDIR=$startdir/pkg install || return 1

A makedepends on perl (>= 5.8.8-6) is required in order ensure that the module is correctly installed into the new @INC path.

Sample Vendor PKGBUILD

# Contributer: Barry User <barry@user.com>
# Maintainer: Harry Hacker <harry@hacker.com>
pkgdesc="Perl/CPAN Module HTML::Template : a simple HTML templating system"
arch=('i686' 'x86_64')
license=('GPL' 'Artistic')
build() {
  cd $startdir/src/HTML-Template-2.9
  /usr/bin/perl Makefile.PL INSTALLDIRS=vendor MAN1EXT=1p MAN3EXT=3pm || return 1
  make || return 1
  make DESTDIR=$startdir/pkg install || return 1
  /usr/bin/find $startdir/pkg -name '.packlist' -exec rm  '{}' \;
  /usr/bin/find $startdir/pkg -name 'perllocal.pod' -exec rm  '{}' \;
# $Id$


Architecture-Independent Modules

Architecture-independent modules which require core modules from the perl package must specify a dependency on that package.

Modules which contain explicit require version or use version statements must specify a dependency on perl with the minimum required version, or more simply the current version.

In the absence of an explicit requirement, architecture-independent modules must depend on a minimum perl version of 5.8.8-6 due to the changes in @INC introduced by that version.

Binary Modules

Binary modules must specify a dependency on either perl with a minimum version of the perl package used to build the module, and must additionally depend on the expansion of perlapi-$Config{version} using the Config module.


Core modules are perl modules "typically" included in the core Perl distribution. It also includes in the perl-modules package.

Core Directories

  • Modules included in the core Perl distribution should be installed into /usr/lib/perl5 and /usr/share/perl5.
  • Only modules contained in the perl or perl-modules package should be installed into this directory tree.
  • No version subdirectory exists in these paths as the dependencies for packaged modules should ensure that all work with the current perl package.

Core perl packages


The perl package should contain the /usr/bin/perl binary, and a minimal set of modules needed in order for simple perl scripts to run and for a base system to operate. It should be maintained in the [current] repository.

The following is a list of a few modules (for example), which are provided in the perl package. (See the PKGBUILD for the offical list).

'perl-checktree' 'perl-collate' 'perl-config' 'perl-cwd' 'perl-dynaloader' 'perl-english' 'perl-env' 'perl-exporter' 'perl-fnctl' 'perl-filehandle' 'perl-find' 'perl-finddepth' 'perl-getopt' 'perl-makemaker' 'perl-socket' 'perl-sys-syslog' 'perl-db-file' 'perl-storable' 'perl-data-dumper' 'perl-digest-md5'.

Every module supplied in the perl package shall be added into the provides array in the PKGBUILD. Modules in this array should NOT appear in the perl packages conflicts or replaces arrays. End users should be able to install newer versions of core modules, either in vendor or site directories without conflict.

Sample perl PKGBUILD



The perl-modules package should contain all the extra modules provided in the perl package, as well as all of the the pragmatic and standard modules listed by executing perldoc perlmodlib. This package should provide modules which are expected to be present on any standard perl installation; such as Data::Dumper, CGI, and Encode. In addition, this package must includes provides for the archlinux packagenames for each of the modules contained.

This package is complex, and it should be updated only when the perl package is.

Because perl-modules must not be required for the basic operation of a Archlinux computer, perl-modules should be located in the [extra] repository and not in the [current] repository.

Users requiring a newer modules than what is provided in perl-modules are advised to install a site package until the next version of the perl package is released.

The following modules should be included as a minimum into the perl-modules package.



The current stable upstream version at the time of this writing is 5.8.8. There is currently work in progress on the next major revision, although the specifications have yet to be finalised.

It is anticipated that when Perl 6 is released it will initially be packaged as perl6, install the binary as /usr/bin/perl6 and use different directories for packaged modules to perl:


This will allow Perl 5 and 6 packages and modules (which should be packaged as perl6-foo-bar), to co-exist for as long as required.

At some stage in the future when Perl 6 is sufficiently mature, the package naming may be reversed such that the perl package contains Perl 6 and the current package becomes perl5.