Building the Debian Perl package
================================

Build Options
-------------

In addition to the ``nostrip'' and ``noopt'' DEB_BUILD_OPTIONS
required by policy (10.1) the build process also recognises the
following perl-specific options:

  x-perl-shared
  x-perl-static
    Select whether /usr/bin/perl is linked to the shared or static
    perl library.  By default the link type is shared on all
    architectures other than i386 (where the relocations incur a
    measurable performance penalty).

  x-perl-notest (or nocheck)
    The regression test suite is normally run after each of the static
    and shared build phases.  It is occaisionally useful to supress
    these tests (when debugging the build process for example, or to
    allow porters to work around known build chain or kernel bugs).

Patches Applied
----------------

A copy of all patches which have been applied to the source are in the
debian/patches directory of the Debian source package.

There are two classes of patches in the directory: debian/patches/fixes/* are
generally applicable to any Perl installation (and usually back-ported
from upstream, or posted to p5p when applied).

Patches in debian/patches/debian implement changes which are specific to
the Debian packaging, such as our @INC ordering or specific to policy
such as not including standard directories in LD_RUN_PATH.

Packaging Details
-----------------

The Debian build process consists of the following components:

  debian/rules
    makefile which drives the build process as usual with Debian
    packages.  This process is slightly more complex than normal to
    simplify bootstrapping a new port--using only basic shell utils, and
    perl (once built, as perl.static).  To bootstrap a new architecture,
    use:

      DEB_HOST_GNU_TYPE=<arch> debian/rules binary-arch

  debian/config.debian 
    a helper script, invoked by debian/rules to run Configure with
    various options.

  debian/config.over
    used to fiddle some config.sh variables (copied to the source
    directory by the build process where it is picked up by Configure).

  debian/patches
    directory containg the patches applied (see above).  These are maintained
    with git-dpm, but if a standalone way to add a new patch is needed 
    (for instance when NMUing), the recommended way is to use quilt(1).
    Using DEP-3 compatible headers for the patch will improve its description
    in `perl -V' output.

      quilt new debian/myfix
      quilt add <file>
      [ hack <file> ]
      echo 'patch description (Closes: #xxxxxx)' | quilt header -a
      # (or even better provide a full DEP-3 compatible header)
      quilt refresh

  debian/released-versions
    contains a list of released Debian versions, used by the
    debian/mkprovides script to generate a list of perlapi-<ver>
    provides for perl-base indicating the released versions the package
    is compatible with.

  debian/headers
    list of C headers to process with h2ph, which is run with "-a" to
    pick up any required includes--keep this base list as short as
    possible.

  debian/*.{files{,.static,.shared},docs}
    used to split packages; see the comments/code in the install-stamp
    target of debian/rules.

Managing debian/patches with git-dpm 
------------------------------------

This section is targeted at the Debian package maintainers, working with
the Git repository pointed by the Vcs-Git field in debian/control.  NMUers
and the like can use the old way of standalone patch handling described
above, or just hack the source and ignore debian/patches altogether.

First, you need to be running wheezy or later, and have the 'git-dpm'
package installed.

Any upstream modifications need to be done on a special 'patched' branch
that is created with 'git-dpm checkout-patched'. Every commit on this branch
corresponds to one patch in debian/patches. The commits can be handled
with normal git tools like 'git rebase -i'.

When everything is ready, 'git-dpm update-patches' will merge the work into
the master branch with the debian/ directory and remove the 'patched' branch,
which is not supposed to be pushed to the shared repository.

See the git-dpm(1) manual page for more information.

Package maintainer tests
------------------------

There are package maintainer tests in the debian/t/ directory that
are supposed to pass at all times. It is recommended that you add
a git pre-commit hook (.git/hooks/pre-commit) that runs the tests
before releasing, for instance:

#!/bin/sh

if [ -e debian/changelog ] && \
   git diff --cached debian/changelog | grep -q '^-.*UNRELEASED' && \
   git diff --cached debian/changelog | grep -q '^\+.*unstable'
then
    prove debian/t/*.t
fi

A special note on patching Configure
------------------------------------

The Configure file is a special case of a file which is autogenerated
upstream by specialised tools, but which upstream explicitly declares
it as being (a) preferred form of modification. As far as Debian goes,
this means that we should generally not try to regenerate it, but patch
it directly (forwarding patches upstream when needed).

Please see <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762638>
for a discussion about this issue.

Credits
-------

Previous maintainers of Debian Perl packages:

  Ray Dassen <jdassen@WI.LeidenUniv.NL>,
  Carl Streeter <streeter@cae.wisc.edu>,
  Robert Sanders <Robert.Sanders@linux.org> and
  Darren Stalder <torin@daft.com>.

 -- Brendan O'Dea <bod@debian.org>  Tue,  8 Mar 2005 19:30:38 +1100

 -- Niko Tyni <ntyni@debian.org> Wed, 03 Feb 2010 14:47:51 +0200

