1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
|
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_BUILD_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,moduledocs}
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
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
|
