programs in debhelper use pairs of files and destinations or slightly more
complicated formats.
-Note that if a package is the first (or only) binary package listed in
-F<debian/control>, debhelper will use F<debian/foo> if no F<debian/package.foo>
-file can be found.
+Note for the first (or only) binary package listed in
+F<debian/control>, debhelper will use F<debian/foo> when there's no
+F<debian/package.foo> file.
In some rare cases, you may want to have different versions of these files
for different architectures or OSes. If files named debian/I<package>.foo.I<ARCH>
"B<dpkg-architecture -qDEB_HOST_ARCH_OS>",
then they will be used in preference to other, more general files.
-In many cases, these config files are used to specify various types of
+Mostly, these config files are used to specify lists of various types of
files. Documentation or example files to install, files to move, and so on.
When appropriate, in cases like these, you can use standard shell wildcard
characters (B<?> and B<*> and B<[>I<..>B<]> character classes) in the files.
-
You can also put comments in these files; lines beginning with B<#> are
ignored.
+The syntax of these files is intentionally kept very simple to make them
+easy to read, understand, and modify. If you prefer power and complexity,
+you can make the file executable, and write a program that outputs
+whatever content is appropriate for a given situation. When you do so,
+the output is not further processed to expand wildcards or strip comments.
+
=head1 SHARED DEBHELPER OPTIONS
The following command line options are supported by all debhelper programs.
=head1 BUILD SYSTEM OPTIONS
-All of the B<dh_auto_>I<*> debhelper programs sets environment variables
-listed by B<dpkg-buildflags>, unless they are already set. They
-support DEB_BUILD_OPTIONS=noopt too.
-
The following command line options are supported by all of the B<dh_auto_>I<*>
debhelper programs. These programs support a variety of build systems,
and normally heuristically determine which to use, and how to use them.
You can use these command line options to override the default behavior.
+Typically these are passed to L<dh(1)>, which then passes them to all the
+B<dh_auto_>I<*> programs.
=over 4
=back
-=head1 NOTES
-
-=head2 Multiple binary package support
-
-If your source package generates more than one binary package, debhelper
-programs will default to acting on all binary packages when run. If your
-source package happens to generate one architecture dependent package, and
-another architecture independent package, this is not the correct behavior,
-because you need to generate the architecture dependent packages in the
-binary-arch F<debian/rules> target, and the architecture independent packages
-in the binary-indep F<debian/rules> target.
-
-To facilitate this, as well as give you more control over which packages
-are acted on by debhelper programs, all debhelper programs accept the
-B<-a>, B<-i>, B<-p>, and B<-s> parameters. These parameters are cumulative.
-If none are given, debhelper programs default to acting on all packages listed
-in the control file.
-
-=head2 Automatic generation of Debian install scripts
-
-Some debhelper commands will automatically generate parts of Debian
-maintainer scripts. If you want these automatically generated things
-included in your existing Debian maintainer scripts, then you need to add
-B<#DEBHELPER#> to your scripts, in the place the code should be added.
-B<#DEBHELPER#> will be replaced by any auto-generated code when you run
-B<dh_installdeb>.
-
-If a script does not exist at all and debhelper needs to add something to
-it, then debhelper will create the complete script.
-
-All debhelper commands that automatically generate code in this way let it
-be disabled by the -n parameter (see above).
-
-Note that the inserted code will be shell code, so you cannot directly use
-it in a Perl script. If you would like to embed it into a Perl script, here
-is one way to do that (note that I made sure that $1, $2, etc are set with
-the set command):
-
- my $temp="set -e\nset -- @ARGV\n" . << 'EOF';
- #DEBHELPER#
- EOF
- system ($temp) / 256 == 0
- or die "Problem with debhelper scripts: $!";
-
-=head2 Automatic generation of miscellaneous dependencies.
-
-Some debhelper commands may make the generated package need to depend on
-some other packages. For example, if you use L<dh_installdebconf(1)>, your
-package will generally need to depend on debconf. Or if you use
-L<dh_installxfonts(1)>, your package will generally need to depend on a
-particular version of xutils. Keeping track of these miscellaneous
-dependencies can be annoying since they are dependant on how debhelper does
-things, so debhelper offers a way to automate it.
-
-All commands of this type, besides documenting what dependencies may be
-needed on their man pages, will automatically generate a substvar called
-B<${misc:Depends}>. If you put that token into your F<debian/control> file, it
-will be expanded to the dependencies debhelper figures you need.
-
-This is entirely independent of the standard B<${shlibs:Depends}> generated by
-L<dh_makeshlibs(1)>, and the B<${perl:Depends}> generated by L<dh_perl(1)>.
-You can choose not to use any of these, if debhelper's guesses don't match
-reality.
-
-=head2 Package build directories
-
-By default, all debhelper programs assume that the temporary directory used
-for assembling the tree of files in a package is debian/I<package>.
-
-Sometimes, you might want to use some other temporary directory. This is
-supported by the B<-P> flag. For example, "B<dh_installdocs -Pdebian/tmp>", will
-use B<debian/tmp> as the temporary directory. Note that if you use B<-P>, the
-debhelper programs can only be acting on a single package at a time. So if
-you have a package that builds many binary packages, you will need to also
-use the B<-p> flag to specify which binary package the debhelper program will
-act on.
-
-=head2 Debhelper compatibility levels
+=head1 COMPATIBILITY LEVELS
From time to time, major non-backwards-compatible changes need to be made
to debhelper, to keep it clean and well-designed as needs change and its
it modifies its behavior in various ways.
Tell debhelper what compatibility level to use by writing a number to
-F<debian/compat>. For example, to turn on v8 mode:
+F<debian/compat>. For example, to turn on v9 mode:
+
+ % echo 9 > debian/compat
+
+Your package will also need a versioned build dependency on a version of
+debhelper equal to (or greater than) the compatibility level your package
+uses. So for compatibility level 9, ensure debian/control has:
- % echo 8 > debian/compat
+ Build-Depends: debhelper (>= 9)
Unless otherwise indicated, all debhelper documentation assumes that you
are using the most recent compatibility level, and in most cases does not
=item v8
-This is the recommended mode of operation.
-
Changes from v7 are:
=over 8
=item v9
-This compatability level is still open for development; use with caution.
+This is the recommended mode of operation.
Changes from v8 are:
=item -
Multiarch support. In particular, B<dh_auto_configure> passes
-multiarch directories to autoconf in --libdir and --libexecdir,
-while B<dh_makeshlibs> detects packages containing multiarch
-directories and sets a Pre-Dependency on multiarch-support in
-${misc:Pre-Depends}
+multiarch directories to autoconf in --libdir and --libexecdir.
=item -
-dh supports use of standard targets in debian/rules without needing
-to manually define the dependencies between targets there.
+dh is aware of the usual dependencies between targets in debian/rules.
+So, "dh binary" will run any build, build-arch, build-indep, install,
+etc targets that exist in the rules file. There's no need to define an
+explicit binary target with explicit dependencies on the other targets.
=item -
-<dh_auto_configure> does not include the source package name
+B<dh_strip> compresses debugging symbol files to reduce the installed
+size of -dbg packages.
+
+=item -
+
+B<dh_auto_configure> does not include the source package name
in --libexecdir when using autoconf.
+=item -
+
+B<dh> does not default to enabling --with=python-support
+
+=item -
+
+All of the B<dh_auto_>I<*> debhelper programs and B<dh> set
+environment variables listed by B<dpkg-buildflags>, unless
+they are already set.
+
+=item -
+
+B<dh_auto_configure> passes B<dpkg-buildflags> CFLAGS, CPPFLAGS, and
+LDFLAGS to perl F<Makefile.PL> and F<Build.PL>
+
+=item -
+
+B<dh_strip> puts separated debug symbols in a location based on their
+build-id.
+
+=item -
+
+Executable debhelper config files are run and their output used as the
+configuration.
+
+=back
+
+=item v10
+
+This compatibility level is still open for development; use with caution.
+
+Changes from v9 are:
+
+=over 8
+
+=item -
+
+None yet..
+
=back
=back
-=head2 udebs
+=head1 NOTES
-Debhelper includes support for udebs. To create a udeb with debhelper,
-add "B<Package-Type: udeb>" to the package's stanza in F<debian/control>, and
-build-depend on debhelper (>= 4.2). Debhelper will try to create udebs that
-comply with debian-installer policy, by making the generated package files
-end in F<.udeb>, not installing any documentation into a udeb, skipping over
-F<preinst>, F<postrm>, F<prerm>, and F<config> scripts, etc.
+=head2 Multiple binary package support
+
+If your source package generates more than one binary package, debhelper
+programs will default to acting on all binary packages when run. If your
+source package happens to generate one architecture dependent package, and
+another architecture independent package, this is not the correct behavior,
+because you need to generate the architecture dependent packages in the
+binary-arch F<debian/rules> target, and the architecture independent packages
+in the binary-indep F<debian/rules> target.
+
+To facilitate this, as well as give you more control over which packages
+are acted on by debhelper programs, all debhelper programs accept the
+B<-a>, B<-i>, B<-p>, and B<-s> parameters. These parameters are cumulative.
+If none are given, debhelper programs default to acting on all packages listed
+in the control file.
-=head2 Other notes
+=head2 Automatic generation of Debian install scripts
+
+Some debhelper commands will automatically generate parts of Debian
+maintainer scripts. If you want these automatically generated things
+included in your existing Debian maintainer scripts, then you need to add
+B<#DEBHELPER#> to your scripts, in the place the code should be added.
+B<#DEBHELPER#> will be replaced by any auto-generated code when you run
+B<dh_installdeb>.
-In general, if any debhelper program needs a directory to exist under
-B<debian/>, it will create it. I haven't bothered to document this in all the
-man pages, but for example, B<dh_installdeb> knows to make debian/I<package>/DEBIAN/
-before trying to put files there, B<dh_installmenu> knows you need a
-debian/I<package>/usr/share/menu/ before installing the menu files, etc.
+If a script does not exist at all and debhelper needs to add something to
+it, then debhelper will create the complete script.
-Once your package uses debhelper to build, be sure to add
-debhelper to your Build-Depends line in F<debian/control>. You should
-build-depend on a version of debhelper equal to (or greater than) the
-debhelper compatibility level your package uses. So if your package used
-compatibility level 7:
+All debhelper commands that automatically generate code in this way let it
+be disabled by the -n parameter (see above).
- Build-Depends: debhelper (>= 7)
+Note that the inserted code will be shell code, so you cannot directly use
+it in a Perl script. If you would like to embed it into a Perl script, here
+is one way to do that (note that I made sure that $1, $2, etc are set with
+the set command):
+
+ my $temp="set -e\nset -- @ARGV\n" . << 'EOF';
+ #DEBHELPER#
+ EOF
+ system ($temp) / 256 == 0
+ or die "Problem with debhelper scripts: $!";
+
+=head2 Automatic generation of miscellaneous dependencies.
+
+Some debhelper commands may make the generated package need to depend on
+some other packages. For example, if you use L<dh_installdebconf(1)>, your
+package will generally need to depend on debconf. Or if you use
+L<dh_installxfonts(1)>, your package will generally need to depend on a
+particular version of xutils. Keeping track of these miscellaneous
+dependencies can be annoying since they are dependent on how debhelper does
+things, so debhelper offers a way to automate it.
+
+All commands of this type, besides documenting what dependencies may be
+needed on their man pages, will automatically generate a substvar called
+B<${misc:Depends}>. If you put that token into your F<debian/control> file, it
+will be expanded to the dependencies debhelper figures you need.
+
+This is entirely independent of the standard B<${shlibs:Depends}> generated by
+L<dh_makeshlibs(1)>, and the B<${perl:Depends}> generated by L<dh_perl(1)>.
+You can choose not to use any of these, if debhelper's guesses don't match
+reality.
+
+=head2 Package build directories
+
+By default, all debhelper programs assume that the temporary directory used
+for assembling the tree of files in a package is debian/I<package>.
+
+Sometimes, you might want to use some other temporary directory. This is
+supported by the B<-P> flag. For example, "B<dh_installdocs -Pdebian/tmp>", will
+use B<debian/tmp> as the temporary directory. Note that if you use B<-P>, the
+debhelper programs can only be acting on a single package at a time. So if
+you have a package that builds many binary packages, you will need to also
+use the B<-p> flag to specify which binary package the debhelper program will
+act on.
+
+=head2 udebs
+
+Debhelper includes support for udebs. To create a udeb with debhelper,
+add "B<Package-Type: udeb>" to the package's stanza in F<debian/control>.
+Debhelper will try to create udebs that comply with debian-installer
+policy, by making the generated package files end in F<.udeb>, not
+installing any documentation into a udeb, skipping over
+F<preinst>, F<postrm>, F<prerm>, and F<config> scripts, etc.
=head1 ENVIRONMENT
=item B<DH_OPTIONS>
Anything in this variable will be prepended to the command line arguments
-of all debhelper commands. Command-specific options will be ignored by
-commands that do not support them.
+of all debhelper commands.
-This is useful in some situations, for example, if you need to pass B<-p> to
-all debhelper commands that will be run. One good way to set B<DH_OPTIONS> is
-by using "Target-specific Variable Values" in your F<debian/rules> file. See
-the make documentation for details on doing this.
+When using L<dh(1)>, it can be passed options that will be passed on to each
+debhelper command, which is generally better than using DH_OPTIONS.
=item B<DH_ALWAYS_EXCLUDE>
projects / debhelper.git / blobdiff