Chapter 4. Packaged Modules
Prev |  | Next

# Chapter 4. Packaged Modules

## 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.

Prev |  | Next
Chapter 3. Locally Installed Modules | Home | Chapter 5. Perl Programs