=head1 SYNOPSIS
- dh_* [-v] [-a] [-i] [-s] [--no-act] [-ppackage] [-Npackage] [-Ptmpdir]
+B<dh_>I<*> [B<-v>] [B<-a>] [B<-i>] [B<-s>] [B<--no-act>] [B<-ppackage>] [B<-Npackage] [-Ptmpdir>]
=head1 DESCRIPTION
=back
+If a program's name starts with "dh_", and the program is not on the above
+list, then it is not part of the debhelper package, but it should still
+work like the other programs described on this page.
+
=head1 DEBHELPER CONFIG FILES
Many debhelper commands make use of files in F<debian/> to control what they
files are typically named debian/package.foo (where "package" of course,
is replaced with the package that is being acted on).
-For example,
-dh_installdocs uses files named debian/package.docs to list the documentation
-files it will install. See the man pages of individual commands for details
-about the names and formats of the files they use.
+For example, dh_installdocs uses files named debian/package.docs to list
+the documentation files it will install. See the man pages of individual
+commands for details about the names and formats of the files they use.
+Generally, these files will list files to act on, one file per line. Some
+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
debian/control, debhelper will use debian/foo if no debian/package.foo
In some rare cases, you may want to have different versions of these files
for different architectures. If files named debian/package.foo.arch
-exist, where "arch" is the same as the output of "dpkg --print-architecture",
+exist, where "arch" is the same as the output of
+"dpkg-architecture -qDEB_HOST_ARCH",
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
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 ('?' and '*') in the files.
+characters ('?' and '*' and '[..]' character classes) in the files.
+
+You can also put comments in these files; lines beginning with "#" are
+ignored.
=head1 SHARED DEBHELPER OPTIONS
=item B<->I<ppackage>, B<--package=>I<package>
-Act on the package named "package".
+Act on the package named "package". This option may be specified multiple
+times to make debhelper operate on a given set of packages.
=item B<-s>, B<--same-arch>
this flag makes the command act on all "Architecture: any" packages, as well
as on any packages that have the current architecture explicitly specified.
Contrast to the -a flag, which makes the command work on all packages that
-are not architecture independant.
+are not architecture independent.
=item B<-N>I<package>, B<--no-package=>I<package>
Use "tmpdir" for package build directory. The default is debian/<package>
+=item B<--mainpackage=>I<package>
+
+This little-used option changes the package which debhelper considers the
+"main package", that is, the first one listed in debian/control, and the
+one for which debian/foo files can be used instead of the usual
+debian/package.foo files.
+
=back
=head1 COMMON DEBHELPER OPTIONS
Exclude an item from processing. This option may be used multiple times,
to exclude more than one thing.
-=item B<-A>, B<-all>
+=item B<-A>, B<--all>
Makes files or other items that are specified on the command line take effect
in ALL packages acted on, not just the first.
=head2 Automatic generation of debian install scripts
-Some debhelper commands will automatically generate parts of debian install
-scripts. If you want these automatically generated things included in your
-debian install scripts, then you need to add "#DEBHELPER#" to your scripts,
-in the place the code should be added. "#DEBHELPER#" will be replaced by
-any auto-generated code when you run dh_installdeb.
+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
+"#DEBHELPER#" to your scripts, in the place the code should be added.
+"#DEBHELPER#" will be replaced by any auto-generated code when you run
+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 scripts that automatically generate code in this way let it be disabled
-by the -n parameter (see above).
+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';
+ 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
+${misc:Depends}. If you put that token into your debian/control file, it
+will be expanded to the dependencies debhelper figures you need.
+
+This is entirely independent of the standard ${shlibs:Depends} generated by
+L<dh_makeshlibs(1)>, and the ${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
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
author gains more experience. To prevent such major changes from breaking
-existing packages, the DH_COMPAT environment variable was introduced.
-DH_COMPAT may be set to a number, to determine which major revision of
-debhelper should be used. There are currently 3:
+existing packages, the concept of debhelper compatibility levels was
+introduced. You tell debhelper which compatibility level it should use, and
+it modifies its behavior in various ways.
+
+Tell debhelper what compatibility level to use by writing a number to
+debian/compat. For example, to turn on V5 mode:
+
+ % echo 5 > debian/compat
+
+Unless otherwise indicated, all debhelper documentation assumes that you
+are using the most recent compatibility level, and in most cases does not
+indicate if the behavior is different in an earlier compatibility level, so
+if you are not using the most recent compatibility level, you're advised to
+read below for notes about what is different in earlier compatibility
+levels.
+
+These are the available compatibility levels:
=over 4
=item V1
-Setting DH_COMPAT=1 (or leaving it unset) causes debhelper to act in
-compatibility mode. It will use debian/tmp as the package tree
+This is the original debhelper compatibility level, and so it is the default
+one. In this mode, debhelper will use debian/tmp as the package tree
directory for the first binary package listed in the control file, while using
debian/<package> for all other packages listed in the control file.
+
This mode is deprecated.
=item V2
-
Setting DH_COMPAT=2 causes debhelper to consistently use debian/<package>
+
In this mode, debhelper will consistently use debian/<package>
as the package tree directory for every package that is built.
+This mode is deprecated.
+
=item V3
-This is the reccommended mode of operation.
-Setting DH_COMPAT=3 does everything V2 does, plus:
+This mode works like V2, with the following additions:
=over 8
=back
+This mode is deprecated.
+
+=item V4
+
+Changes from V3 are:
+
+=over 8
+
+=item -
+
+dh_makeshlibs -V will not include the debian part of the version number in
+the generated dependency line in the shlibs file.
+
+=item -
+
+You are encouraged to put the new ${misc:Depends} into debian/control to
+supplement the ${shlibs:Depends} field.
+
+=item -
+
+dh_fixperms will make all files in bin/ directories and in etc/init.d
+executable.
+
+=item -
+
+dh_link will correct existing links to conform with policy.
+
+=back
+
+=item V5
+
+This is the recommended mode of operation. It does everything V4 does,
+plus:
+
+=over 8
+
+=item -
+
+Comments are ignored in debhelper config files.
+
+=item -
+
+dh_strip --dbg-package now specifies the name of a package to put debugging
+symbols in, not the packages to take the symbols from.
+
+=item -
+
+dh_installdocs skips installing empty files.
+
+=item -
+
+dh_install errors out if wildcards expand to nothing.
+
+=back
+
+=item V6
+
+This mode is still under development. Currently it has these differences
+compared to V5:
+
+=over 8
+
+=item -
+
+dh_installwm will install a slave manpage link for x-window-manager.1.gz.
+
+=item -
+
+dh_builddeb did not previously delete everything matching
+DH_ALWAYS_EXCLUDE, if it was set to a list of things to exclude, such as
+"CVS:.svn". Now it does.
+
+=item -
+
+dh_installman allows overwriting existing man pages in the package build
+directory. In previous compatability levels it silently refuses to do this.
+
=back
=head2 Doc directory symlinks
hand), and debhelper should do the right thing: notice it is a dangling
symlink and not try to install a copyright file or changelog.
+=head2 udebs
+
+Debhelper includes support for udebs. To create a udeb with debhelper,
+add "XC-Package-Type: udeb" to the package's stanza in 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 ".udeb", not installing any documentation into a udeb, skipping over
+preinst, postrm, prerm, and config scripts, etc.
+
=head2 Other notes
In general, if any debhelper program needs a directory to exist under
debian/, it will create it. I haven't bothered to document this in all the
man pages, but for example, dh_installdeb knows to make debian/<package>/DEBIAN/
before trying to put files there, dh_installmenu knows you need a
-debian/<package>/usr/lib/menu/ before installing the menu files, etc.
-
-If you are generating a debian package that has arch-indep and
-arch-dependent portions, and you are using dh_movefiles to move the
-arch-indep files out of debian/tmp, you need to make sure that dh_movefiles
-does this even if only the arch-dependent package is being built (for
-ports to other architectures). I handle this in the example rules file
-"rules.multi" by calling dh_movefiles in the install target.
+debian/<package>/usr/share/menu/ before installing the menu files, etc.
Once your package uses debhelper to build, be sure to add
-debhelper to your Build-Depends line in debian/control.
+debhelper to your Build-Depends line in 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 5:
+
+ Build-Depends: debhelper (>= 5)
=head1 ENVIRONMENT
=item DH_COMPAT
-Specifies what compatibility level debhelper should run at. See above.
+Temporarily specifies what compatibility level debhelper should run at,
+overriding any value in debian/compat.
=item DH_NO_ACT
=item DH_OPTIONS
-Anything in this variable will be prepended to the command line
-arguments of all debhelper commands. This is useful in some situations,
-for example, if you need to pass -p to all debhelper commands that will be
-run. If you use DH_OPTIONS, be sure to build depend on "debhelper >= 1.1.17" --
-older debhelpers will ignore it and do things you don't want them to. One very
-good way to set DH_OPTIONS is by using "Target-specific Variable Values" in
-your debian/rules file. See the make documentation for details on doing this.
+Anything in this variable will be prepended to the command line arguments
+of all debhelper commands. This is useful in some situations, for example,
+if you need to pass -p to all debhelper commands that will be run. One good
+way to set DH_OPTIONS is by using "Target-specific Variable Values" in your
+debian/rules file. See the make documentation for details on doing this.
+
+=item DH_ALWAYS_EXCLUDE
+
+If set, this adds the value the variable is set to to the -X options of all
+commands that support the -X option. Moreover, dh_builddeb will rm -rf
+anything that matches the value in your package build tree.
+
+This can be useful if you are doing a build from a CVS source tree, in
+which case setting DH_ALWAYS_EXCLUDE=CVS will prevent any CVS directories
+from sneaking into the package you build. Or, if a package has a source
+tarball that (unwisely) includes CVS directories, you might want to export
+DH_ALWAYS_EXCLUDE=CVS in debian/rules, to make it take effect wherever
+your package is built.
+
+Multiple things to exclude can be separated with colons, as in
+DH_ALWAYS_EXCLUDE=CVS:.svn
=back
A set of example debian/rules files that use debhelper.
-=item http://kitenet.net/programs/debhelper/
+=item L<http://kitenet.net/programs/debhelper/>
Debhelper web site.
projects / debhelper.git / blobdiff