Chapter 4. Packaged Modules

Table of Contents

4.1. Vendor Directories
4.2. Module Package Names
4.3. Vendor Installation
4.4. Module Dependencies
4.4.1. Architecture-Independent Modules
4.4.2. Binary and Other Architecture Dependent Modules
4.4.3. Automating Perl Dependencies

4.1. Vendor Directories

The installation directory for Debian modules must be different from that for core and site modules.

The current Perl packaging uses the vendor directories for this purpose, which are at present as described in Section 2.3, “Module Path” as vendor.

The Perl distribution includes many modules available separately from CPAN which may have a newer version. The intent of the @INC ordering (described in Section 2.3, “Module Path”) 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 (see Section 2.4, “Documentation”) using the extensions .1p and .3pm to ensure that no conflict arises where a packaged module duplicates a core module.

.packlist files should not be installed.

4.2. Module Package Names

Perl module packages should be named for the primary module provided. The naming convention is to lowercase the Perl module name, prepend, lib, change all occurrences of :: to -, and append -perl. For example:

Table 4.1. Module to package mappings

Module Package
Foo::Bar libfoo-bar-perl
Foo::Bar::Baz libfoo-bar-baz-perl
Foo::BarBaz libfoo-barbaz-perl

Packages which include multiple modules may additionally include provides for the additional modules using the same convention.

4.3. Vendor Installation

A module should use the following lines in the debian/rules build target: [7]

perl Makefile.PL INSTALLDIRS=vendor
$(MAKE) OPTIMIZE="-O2 -g -Wall"

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

$(MAKE) install DESTDIR=$(CURDIR)/debian/<tmp>

[8]

4.4. Module Dependencies

4.4.1. 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 or perl-base with the minimum required version, or more simply the current version.

4.4.2. Binary and Other Architecture Dependent Modules

Binary modules must specify a dependency on either perl or perl-base with a minimum version of the perl package used to build the module. Additionally, all binary modules (regardless of their installation directory) and any other modules installed into $Config{vendorarch} must depend on the expansion of perlapi-$Config{debian_abi} using the Config module. If $Config{debian_abi} is empty or not set, $Config{version} must be used.

4.4.3. Automating Perl Dependencies

Rather than hard-coding the dependencies into the control file, using a substitution such as ${perl:Depends} is suggested. This allows the dependencies to be determined at build time and written to the substvars file in the form perl:Depends=deps.[9]

Packages built with debhelper may use dh_perl(1) to generate this substitution automatically. This additionally requires a versioned Build-Depends (or Build-Depends-Indep) on debhelper (>= 3.0.18).



[7] The environment variable PERL_MM_OPT may be used to pass the INSTALLDIRS=vendor option in cases where Makefile.PL is not invoked directly from debian/rules

[8] Replace <tmp> with the appropriate directory (nominally just tmp)

[9] Please note that dependencies caused by versioned uses and on separately packaged modules are not included in this variable and must be explicitly included.