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 then
+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 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 Debhelper compatibility levels
+=head1 COMPATABILITY 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
=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 -
+
+B<dh_strip> compresses debugging symbol files to reduce the installed
+size of -dbg packages.
=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. They support DEB_BUILD_OPTIONS=noopt too.
+
+=item -
+
+B<dh_auto_configure> passes CFLAGS 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
=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 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,
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 Other notes
-
-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.
+=head2 Build depends
Once your package uses debhelper to build, be sure to add
debhelper to your Build-Depends line in F<debian/control>. You should
=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