debhelper

package: debhelper

title: debhelper(7)

summary: the debhelper tool suite

text:
# debhelper(7)

## NAME
debhelper - the debhelper tool suite

## SYNOPSIS
dh_* [-v] [-a] [-i] [-s] [--no-act] [-ppackage] [-Npackage] [-Ptmpdir]

## DESCRIPTION
Debhelper is used to help you build a Debian package. The philosophy behind debhelper is to provide a collection of small, simple, and easily understood tools that are used in debian/rules to automate various common aspects of building a package. This means less work for you, the packager. It also, to some degree means that these tools can be changed if Debian policy changes, and packages that use them will require only a rebuild to comply with the new policy.

A typical debian/rules file that uses debhelper will call several debhelper commands in sequence, or use dh(1) to automate this process. Examples of rules files that use debhelper are in /usr/share/doc/debhelper/examples/

To create a new Debian package using debhelper, you can just copy one of the sample rules files and edit it by hand. Or you can try the dh-make package, which contains a dh_make command that partially automates the process. For a more gentle introduction, the maint-guide Debian package contains a tutorial about making your first package using debhelper.

## DEBHELPER COMMANDS
Here is the list of debhelper commands you can use. See their man pages for additional documentation.

dh_auto_build(1)

automatically builds a package

dh_auto_clean(1)

automatically cleans up after a build

dh_auto_configure(1)

automatically configure a package prior to building

dh_auto_install(1)

automatically runs make install or similar

dh_auto_test(1)

automatically runs a package's test suites

dh_bugfiles(1)

install bug reporting customization files into package build directories

dh_builddeb(1)

build Debian binary packages

dh_clean(1)

clean up package build directories

dh_compress(1)

compress files and fix symlinks in package build directories

dh_fixperms(1)

fix permissions of files in package build directories

dh_gconf(1)

install GConf defaults files and register schemas

dh_gencontrol(1)

generate and install control file

dh_icons(1)

Update caches of Freedesktop icons

dh_install(1)

install files into package build directories

dh_installcatalogs(1)

install and register SGML Catalogs

dh_installchangelogs(1)

install changelogs into package build directories

dh_installcron(1)

install cron scripts into etc/cron.*

dh_installdeb(1)

install files into the DEBIAN directory

dh_installdebconf(1)

install files used by debconf in package build directories

dh_installdirs(1)

create subdirectories in package build directories

dh_installdocs(1)

install documentation into package build directories

dh_installemacsen(1)

register an Emacs add on package

dh_installexamples(1)

install example files into package build directories

dh_installgsettings(1)

install GSettings overrides and set dependencies

dh_installifupdown(1)

install if-up and if-down hooks

dh_installinfo(1)

install info files

dh_installinit(1)

install service init files into package build directories

dh_installlogcheck(1)

install logcheck rulefiles into etc/logcheck/

dh_installlogrotate(1)

install logrotate config files

dh_installman(1)

install man pages into package build directories

dh_installmenu(1)

install Debian menu files into package build directories

dh_installmime(1)

install mime files into package build directories

dh_installmodules(1)

register kernel modules

dh_installpam(1)

install pam support files

dh_installppp(1)

install ppp ip-up and ip-down files

dh_installudev(1)

install udev rules files

dh_installwm(1)

register a window manager

dh_installxfonts(1)

register X fonts

dh_link(1)

create symlinks in package build directories

dh_lintian(1)

install lintian override files into package build directories

dh_listpackages(1)

list binary packages debhelper will act on

dh_makeshlibs(1)

automatically create shlibs file and call dpkg-gensymbols

dh_md5sums(1)

generate DEBIAN/md5sums file

dh_movefiles(1)

move files out of debian/tmp into subpackages

dh_perl(1)

calculates Perl dependencies and cleans up after MakeMaker

dh_prep(1)

perform cleanups in preparation for building a binary package

dh_shlibdeps(1)

calculate shared library dependencies

dh_strip(1)

strip executables, shared libraries, and some static libraries

dh_testdir(1)

test directory before building Debian package

dh_testroot(1)

ensure that a package is built as root

dh_ucf(1)

register configuration files with ucf

dh_usrlocal(1)

migrate usr/local directories to maintainer scripts

### Deprecated Commands
A few debhelper commands are deprecated and should not be used.

dh_desktop(1)

deprecated no-op

dh_installmanpages(1)

old-style man page installer (deprecated)

dh_scrollkeeper(1)

deprecated no-op

dh_suidregister(1)

suid registration program (deprecated)

dh_undocumented(1)

undocumented.7 symlink program (deprecated no-op)

### Other Commands
If a program's name starts with dh_, and the program is not on the above lists, then it is not part of the debhelper package, but it should still work like the other programs described on this page.

## DEBHELPER CONFIG FILES
Many debhelper commands make use of files in debian/ to control what they do. Besides the common debian/changelog and debian/control, which are in all packages, not just those using debhelper, some additional files can be used to configure the behavior of specific debhelper commands. These 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. 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 for the first (or only) binary package listed in debian/control, debhelper will use debian/foo when there's no 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/package.foo.ARCH or debian/package.foo.OS exist, where ARCH and OS are the same as the output of "dpkg-architecture -qDEB_HOST_ARCH" / "dpkg-architecture -qDEB_HOST_ARCH_OS", then they will be used in preference to other, more general files.

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 (? and * and [..] character classes) in the files. You can also put comments in these files; lines beginning with # 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.

## SHARED DEBHELPER OPTIONS
The following command line options are supported by all debhelper programs.

-v, --verbose

Verbose mode: show all commands that modify the package build directory.

--no-act

Do not really do anything. If used with -v, the result is that the command will output what it would have done.

-a, --arch

Act on architecture dependent packages that should be built for the build architecture.

-i, --indep

Act on all architecture independent packages.

-ppackage, --package=package

Act on the package named package. This option may be specified multiple times to make debhelper operate on a given set of packages.

-s, --same-arch

This used to be a smarter version of the -a flag, but the -a flag is now equally smart.

-Npackage, --no-package=package

Do not act on the specified package even if an -a, -i, or -p option lists the package as one that should be acted on.

--remaining-packages

Do not act on the packages which have already been acted on by this debhelper command earlier (i.e. if the command is present in the package debhelper log). For example, if you need to call the command with special options only for a couple of binary packages, pass this option to the last call of the command to process the rest of packages with default settings.

--ignore=file

Ignore the specified file. This can be used if debian/ contains a debhelper config file that a debhelper command should not act on. Note that debian/compat, debian/control, and debian/changelog can't be ignored, but then, there should never be a reason to ignore those files. For example, if upstream ships a debian/init that you don't want dh_installinit to install, use --ignore=debian/init

-Ptmpdir, --tmpdir=tmpdir

Use tmpdir for package build directory. The default is debian/package

--mainpackage=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.

-O=option|bundle

This is used by dh(1) when passing user-specified options to all the commands it runs. If the command supports the specified option or option bundle, it will take effect. If the command does not support the option (or any part of an option bundle), it will be ignored.

## COMMON DEBHELPER OPTIONS
The following command line options are supported by some debhelper programs. See the man page of each program for a complete explanation of what each option does.

-n

Do not modify postinst, postrm, etc. scripts.

-Xitem, --exclude=item

Exclude an item from processing. This option may be used multiple times, to exclude more than one thing. The \fIitem\fR is typically part of a filename, and any file containing the specified text will be excluded.

-A, --all

Makes files or other items that are specified on the command line take effect in ALL packages acted on, not just the first.

## BUILD SYSTEM OPTIONS
The following command line options are supported by all of the dh_auto_* 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 dh(1), which then passes them to all the dh_auto_* programs.

-Sbuildsystem, --buildsystem=buildsystem

Force use of the specified buildsystem, instead of trying to auto-select one which might be applicable for the package.

-Ddirectory, --sourcedirectory=directory

Assume that the original package source tree is at the specified directory rather than the top level directory of the Debian source package tree.

-B[directory], --builddirectory=[directory]

Enable out of source building and use the specified directory as the build directory. If directory parameter is omitted, a default build directory will be chosen. If this option is not specified, building will be done in source by default unless the build system requires or prefers out of source tree building. In such a case, the default build directory will be used even if --builddirectory is not specified.

If the build system prefers out of source tree building but still allows in source building, the latter can be re-enabled by passing a build directory path that is the same as the source directory path.

--parallel, --no-parallel

Control whether parallel builds should be used if underlying build system supports them. The number of parallel jobs is controlled by the DEB_BUILD_OPTIONS environment variable ("Debian Policy, section 4.9.1") at build time. It might also be subject to a build system specific limit. If neither option are not specified, debhelper currently defaults to --parallel in compat 10 (or later) and --no-parallel otherwise.

As an optimization, dh will try to avoid passing these options to subprocesses, if they are unncessary and the only options passed. Notably this happens when DEB_BUILD_OPTIONS does not have a parallel parameter (or its value is 1).

--max-parallel=maximum

This option implies --parallel and allows further limiting the number of jobs that can be used in a parallel build. If the package build is known to only work with certain levels of concurrency, you can set this to the maximum level that is known to work, or that you wish to support. Notably, setting the maximum to 1 is effectively the same as using --no-parallel.

--list, -l

List all build systems supported by debhelper on this system. The list includes both default and third party build systems (marked as such). Also shows which build system would be automatically selected, or which one is manually specified with the --buildsystem option.

## 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 author gains more experience. To prevent such major changes from breaking 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 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:

```
  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 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:

v1

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.

v2

In this mode, debhelper will consistently use debian/package as the package tree directory for every package that is built. This mode is deprecated.

v3

This mode works like v2, with the following additions:

- Debhelper config files support globbing via * and ?, when appropriate. To turn this off and use those characters raw, just prefix with a backslash.

- dh_makeshlibs makes the postinst and postrm scripts call ldconfig.

- Every file in etc/ is automatically flagged as a conffile by dh_installdeb.

This mode is deprecated.

v4

Changes from v3 are:

- dh_makeshlibs -V will not include the Debian part of the version number in the generated dependency line in the shlibs file.

- You are encouraged to put the new ${misc:Depends} into debian/control to supplement the ${shlibs:Depends} field.

- dh_fixperms will make all files in bin/ directories and in etc/init.d executable.

- dh_link will correct existing links to conform with policy.

This mode is deprecated.

v5

Changes from v4 are:

- Comments are ignored in debhelper config files.

- dh_strip --dbg-package now specifies the name of a package to put debugging symbols in, not the packages to take the symbols from.

- dh_installdocs skips installing empty files.

- dh_install errors out if wildcards expand to nothing.

v6

Changes from v5 are:

- Commands that generate maintainer script fragments will order the fragments in reverse order for the prerm and postrm scripts.

- dh_installwm will install a slave manpage link for x-window-manager.1.gz, if it sees the man page in usr/share/man/man1 in the package build directory.

- 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:.git. Now it does.

- dh_installman allows overwriting existing man pages in the package build directory. In previous compatibility levels it silently refuses to do this.

v7

Changes from v6 are:

- dh_install, will fall back to looking for files in debian/tmp if it doesn't find them in the current directory (or wherever you tell it look using --sourcedir). This allows dh_install to interoperate with dh_auto_install, which installs to debian/tmp, without needing any special parameters.

- dh_clean will read debian/clean and delete files listed there.

- dh_clean will delete toplevel *-stamp files.

- dh_installchangelogs will guess at what file is the upstream changelog if none is specified.

v8

Changes from v7 are:

- Commands will fail rather than warning when they are passed unknown options.

- dh_makeshlibs will run dpkg-gensymbols on all shared libraries that it generates shlibs files for. So -X can be used to exclude libraries. Also, libraries in unusual locations that dpkg-gensymbols would not have processed before will be passed to it, a behavior change that can cause some packages to fail to build.

- dh requires the sequence to run be specified as the first parameter, and any switches come after it. Ie, use "dh $@ --foo", not "dh --foo $@".

- dh_auto_* prefer to use Perl's Module::Build in preference to Makefile.PL.

v9

This is the recommended mode of operation. Changes from v8 are:

- Multiarch support. In particular, dh_auto_configure passes multiarch directories to autoconf in --libdir and --libexecdir.

- 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.

- dh_strip compresses debugging symbol files to reduce the installed size of -dbg packages.

- dh_auto_configure does not include the source package name in --libexecdir when using autoconf.

- dh does not default to enabling --with=python-support

- All of the dh_auto_* debhelper programs and dh set environment variables listed by dpkg-buildflags, unless they are already set.

- dh_auto_configure passes dpkg-buildflags CFLAGS, CPPFLAGS, and LDFLAGS to perl Makefile.PL and Build.PL

- dh_strip puts separated debug symbols in a location based on their build-id.

- Executable debhelper config files are run and their output used as the configuration.

v10

This compatibility level is still open for development; use with caution. Changes from v9 are:

- dh_installinit will no longer install a file named debian/package as an init script.

- dh_installdocs will error out if it detects links created with --link-doc between packages of architecture "all" and non-"all" as it breaks binNMUs.

- dh no longer creates the package build directory when skipping running debhelper commands. This will not affect packages that only build with debhelper commands, but it may expose bugs in commands not included in debhelper.

- dh_installdeb no longer installs a maintainer-provided debian/package.shlibs file. This is now done by dh_makeshlibs instead.

- dh_installwm refuses to create a broken package if no man page can be found (required to register for the x-window-manager alternative).

- Debhelper will default to --parallel for all buildsystems that support parallel building. This can be disabled by using either --no-parallel or passing --max-parallel with a value of 1.

## NOTES

### 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 debian/rules target, and the architecture independent packages in the binary-indep 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 -a, -i, -p, and -s parameters. These parameters are cumulative. If none are given, debhelper programs default to acting on all packages listed in the control file, with the exceptions below.

First, any package whose Architecture field in debian/control does not match the build architecture will be excluded ("Debian Policy, section 5.6.8").

Also, some additional packages may be excluded based on the contents of the DEB_BUILD_PROFILES environment variable and Build-Profiles fields in binary package stanzas in debian/control, according to the draft policy at <https://wiki.debian.org/BuildProfileSpec>.

### 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 #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 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
  if (system($temp)) {
     my $exit_code = ($? >> 8) & 0xff;
     my $signal = $? & 0x7f;
     if ($exit_code) {
         die("The debhelper script failed with error code: ${exit_code}");
     } else {
         die("The debhelper script was killed by signal: ${signal}");
     }
  }
```

### 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 dh_installdebconf(1), your package will generally need to depend on debconf. Or if you use 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 ${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 dh_makeshlibs(1), and the ${perl:Depends} generated by dh_perl(1). You can choose not to use any of these, if debhelper's guesses don't match reality.

### 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/package.

Sometimes, you might want to use some other temporary directory. This is supported by the -P flag. For example, "dh_installdocs -Pdebian/tmp", will use debian/tmp as the temporary directory. Note that if you use -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 -p flag to specify which binary package the debhelper program will act on.

### udebs
Debhelper includes support for udebs. To create a udeb with debhelper, add "Package-Type: udeb" to the package's stanza in debian/control. 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.

## ENVIRONMENT
The following environment variables can influence the behavior of debhelper. It is important to note that these must be actual environment variables in order to function properly (not simply Makefile variables). To specify them properly in debian/rules, be sure to "export" them. For example, "export DH_VERBOSE".

DH_VERBOSE

Set to 1 to enable verbose mode. Debhelper will output every command it runs. Also enables verbose build logs for some build systems like autoconf.

DH_QUIET

Set to 1 to enable quiet mode. Debhelper will not output commands calling the upstream build system nor will dh print which subcommands are called and depending on the upstream build system might make that more quiet, too. This makes it easier to spot important messages but makes the output quite useless as buildd log. Ignored if DH_VERBOSE is also set.

DH_COMPAT

Temporarily specifies what compatibility level debhelper should run at, overriding any value in debian/compat.

DH_NO_ACT

Set to 1 to enable no-act mode.

DH_OPTIONS

Anything in this variable will be prepended to the command line arguments of all debhelper commands. When using dh(1), it can be passed options that will be passed on to each debhelper command, which is generally better than using DH_OPTIONS.

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

## SEE ALSO
/usr/share/doc/debhelper/examples/

A set of example debian/rules files that use debhelper.

<http://joeyh.name/code/debhelper/>

Debhelper web site.

## AUTHOR
Joey Hess <joeyh@debian.org>


debhelper.de

title: debhelper.de(7)

summary: die Debhelper\-Werkzeugsammlung

text:
# debhelper.de(7)

## NAME
debhelper - die Debhelper-Werkzeugsammlung

## ÜBERSICHT
dh_* [-v] [-a] [-i] [-s] [--no-act] [-pPaket] [-NPaket] [-Ptemporäres_Verzeichnis]

## BESCHREIBUNG
Debhelper wird benutzt, um Ihnen beim Bau eines Debian-Pakets zu helfen. Die Philosophie hinter Debhelper ist, eine kleine, einfach und leicht verständliche Werkzeugsammlung bereitzustellen, die in debian/rules verwandt wird, um verschiedene geläufige Aspekte der Paketerstellung zu automatisieren. Dies bedeutet für Sie als Paketierer weniger Arbeit. Außerdem heißt das zu einem gewissen Grad, dass diese Werkzeuge geändert werden können, wenn sich die Debian-Richtlinie ändert und Pakete, die sie heranziehen, nur neu gebaut werden müssen, um ihr zu entsprechen.

Eine typische debian/rules-Datei, die Debhelper benutzt, wird mehrere Debhelper-Befehle hintereinander aufrufen oder dh(1) verwenden, um diesen Prozess zu automatisieren. Beispiele für Regeldateien, die Debhelper einsetzen, liegen in /usr/share/doc/debhelper/examples/.

Um ein neues Debian-Paket unter Benutzung von Debhelper zu erstellen, können Sie einfach eine Beispielregeldatei kopieren und manuell bearbeiten. Oder Sie können das Paket dh-make ausprobieren, das einen dh_make-Befehl enthält, der den Prozess teilweise automatisiert. Für eine behutsamere Einführung enthält das Paket maint-guide ein Lernprogramm, wie Sie Ihr erstes Paket unter Verwendung von Debhelper erstellen.

## DEBHELPER-BEFEHLE
Hier ist die Liste der Debhelper-Befehle, die Sie benutzen können. Zusätzliche Dokumentation finden Sie in deren Handbuchseiten.

dh_auto_build(1)

baut ein Paket automatisch

dh_auto_clean(1)

räumt nach dem Bauen automatisch auf

dh_auto_configure(1)

konfiguriert das Paket automatisch vor dem Bauen.

dh_auto_install(1)

führt »make install« oder Ähnliches aus

dh_auto_test(1)

führt automatisch die Test-Suites eines Programms aus

dh_bugfiles(1)

installiert Dateien zur Anpassung von Fehlerberichten in Bauverzeichnisse von Paketen.

dh_builddeb(1)

baut binäre Debian-Pakete

dh_clean(1)

räumt die Bauverzeichnisse des Pakets auf

dh_compress(1)

komprimiert Dateien und feste symbolische Verweise in Bauverzeichnissen von Paketen

dh_fixperms(1)

korrigiert Zugriffsrechte von Dateien in Bauverzeichnissen

dh_gconf(1)

installiert Standard-GConf-Dateien und registriert Schemen

dh_gencontrol(1)

erzeugt und installiert die Datei »control«

dh_icons(1)

aktualisiert die Zwischenspeicher von Freedesktop-Symbolen

dh_installcatalogs(1)

installiert und registriert SGML-Kataloge

dh_installchangelogs(1)

installiert Änderungsprotokolle (»changelogs«) in die Paketbauverzeichnisse

dh_installcron(1)

installiert Cron-Skripte in etc/cron.*

dh_installdeb(1)

installiert Dateien in das Verzeichnis DEBIAN.

dh_installdebconf(1)

installiert Dateien, die von Debconf im Paketbauverzeichnis benutzt werden

dh_installdirs(1)

erstellt Unterverzeichnisse in den Paketbauverzeichnissen

dh_installdocs(1)

installiert Dokumentation in Paketbauverzeichnisse

dh_installemacsen(1)

registriert ein Emacs-Add-on-Paket

dh_installexamples(1)

installiert Beispieldateien in die Paketbauverzeichnisse.

dh_installifupdown(1)

installiert »if-up«- und »if-down«-Hooks.

dh_installinfo(1)

installiert Info-Dateien

dh_installinit(1)

installiert Dienstinitialisierungsdateien in Paketbauverzeichnisse

dh_installlogcheck(1)

installiert Regeldateien zur Protokollprüfung in etc/logcheck/

dh_installlogrotate(1)

installiert Konfigurationsdateien von Logrotate

dh_installman(1)

installiert Handbuchseiten in Paketbauverzeichnisse

dh_installmenu(1)

installiert Debian-Menü-Dateien in Paketbauverzeichnisse

dh_installmime(1)

installiert MIME-Dateien in Paketbauverzeichnisse

dh_installmodules(1)

registriert Kernel-Module

dh_installpam(1)

installiert PAM unterstützende Dateien

dh_installppp(1)

installiert PPP-ip-up- und -ip-down-Dateien

dh_installudev(1)

installiert udev-Regeldateien

dh_installwm(1)

registriert einen Fenster-Manager

dh_installxfonts(1)

registriert X-Schriften

dh_link(1)

erzeugt symbolische Verweise in Paketbauverzeichnisse

dh_lintian(1)

installiert außer Kraft setzende Dateien für Lintian in Paketbauverzeichnisse

dh_listpackages(1)

listet Binärpakete auf, auf die Dephelper einwirken wird

dh_makeshlibs(1)

erstellt automatisch die Shlibs-Datei und ruft dpkg-gensymbols auf

dh_md5sums(1)

erzeugt die Datei DEBIAN/md5sums

dh_movefiles(1)

verschiebt Dateien aus debian/tmp in Unterpakete

dh_perl(1)

berechnet Perl-Abhängigkeiten und räumt nach MakeMaker auf

dh_prep(1)

führt Säuberungsaktionen als Vorbereitung des Baus von Binärpaketen durch

dh_shlibdeps(1)

berechnet Abhängigkeiten gemeinsam benutzter Bibliotheken

dh_testdir(1)

Verzeichnis vor dem Bauen des Debian-Pakets testen

dh_testroot(1)

stellt sicher, dass ein Paket als Root gebaut wird.

dh_usrlocal(1)

migriert usr/local-Verzeichnisse zu Betreuerskripten

### Missbilligte Befehle
Ein paar Debhelper-Befehle sind missbilligt und sollten nicht benutzt werden.

dh_desktop(1)

missbilligt, Leerbefehl

dh_installmanpages(1)

Handbuchseiteninstallationsprogramm im alten Stil (missbilligt)

dh_scrollkeeper(1)

missbilligter Leerbefehl

dh_suidregister(1)

SUID-Registrierungsprogramm (missbilligt)

dh_undocumented(1)

Programm für symbolische Verweise zu undocumented.7 (missbilligt, Leerbefehl)

### Weitere Befehle
Falls ein Programmname mit dh_ beginnt und das Programm nicht auf obiger Liste steht, dann ist es nicht Teil des Debhelper-Pakets, sollte aber trotzdem wie die anderen auf dieser Seite beschriebenen Programme funktionieren.

## DEBHELPER-KONFIGURATIONSDATEIEN
Viele Debhelper-Befehle machen von den Dateien in debian/ Gebrauch, um zu steuern, was sie tun. Neben den üblichen debian/changelog und debian/control, die in allen Paketen enthalten sind, nicht nur in denen, die Debhelper benutzen, können einige zusätzliche Dateien verwandt werden, um das Verhalten bestimmter Debhelper-Befehle zu konfigurieren. Diese Dateien heißen üblicherweise debian/Paket.foo (wobei Paket natürlich durch das Paket ersetzt wird, auf das es sich auswirkt).

dh_installdocs benutzt beispielsweise Dateien mit dem Namen debian/package.docs, um die Dokumentationsdateien aufzulisten, die es installieren wird. Lesen Sie die Handbuchseiten der einzelnen Befehle, um Einzelheiten über die Namen und Formate der Dateien zu erhalten, die sie verwenden. Im Allgemeinen werden diese Dateien Dateien auflisten, auf die sie einwirken, eine Datei pro Zeile. Einige Programme in Debhelper bedienen sich Paaren von Dateien und Zielen oder etwas kompiziertere Formate.

Beachten Sie, dass Debhelper für das erste (oder einzige) in debian/control aufgelistete Binärpaket debian/foo benutzen wird, wenn es dort keine debian/package.foo-Datei gibt.

In einigen seltenen Fällen möchten Sie möglicherweise unterschiedliche Versionen dieser Dateien für unterschiedliche Architekturen oder Betriebssysteme haben. Falls Dateien mit den Namen debian/Paket.foo.ARCHITEKTUR oder debian/Paket.foo.BETRIEBSSYSTEM existieren, wobei ARCHITEKTUR und BETRIEBSSYSTEM der Ausgabe von »dpkg-architecture -qDEB_HOST_ARCH_OS« entsprechen, dann werden sie gegenüber anderen, allgemeineren Dateien, bevorzugt.

Meist werden diese Konfigurationsdateien benutzt, um verschiedene Typen von Dateien anzugeben – zu installierende Dokumentations- oder Beispieldateien, Dateien zum Verschieben und so weiter. Wenn es in Fällen wie diesem zweckmäßig ist, können Sie die Standardplatzhalterzeichen der Shell in den Dateien verwenden (?, * und [..]-Zeichenklassen). Sie können außerdem Kommentare in diese Dateien einfügen; Zeilen, die mit # beginnen, werden ignoriert.

Die Syntax dieser Dateien ist absichtlich sehr einfach gehalten, damit sie leicht zu lesen, zu verstehen und zu ändern sind. Falls Sie Leistung und Komplexität vorziehen, können Sie die Datei ausführbar machen und ein Programm schreiben, das das ausgibt, was auch immer für eine gegebene Situation gegeignet ist. Wenn Sie dies tun, wird die Ausgabe nicht weiter verarbeitet, um Platzhalter zu expandieren oder Kommentare zu entfernen.

## GEMEINSAM BENUTZTE DEBHELPER-OPTIONEN
Die folgenden Befehlszeilenoptionen werden von allen Debhelper-Programmen unterstützt.

-v, --verbose

detailreicher Modus: zeigt alle Befehle, die das Paketbauverzeichnis ändern

--no-act

tut nicht wirklich etwas. Falls es mit -v benutzt wird, wird als Ergebnis ausgegeben, was der Befehl getan hätte.

-a, --arch

wirkt sich auf architekturabhängige Pakete aus, die für die Bauarchitektur gebaut werden sollen.

-i, --indep

wirkt sich auf alle architekturunabhängigen Pakete aus.

-pPaket, --package=Paket

wirkt sich auf das Paket mit Namen Paket aus. Diese Option kann mehrfach angegeben werden, damit Debhelper mit einer Zusammenstellung von Paketen arbeitet.

-s, --same-arch

Dies wurde als intelligentere Version des Schalters -a benutzt, aber -a ist nun genauso intelligent.

-NPaket, --no-package=Paket

verhindert Auswirkungen auf das angegebene Paket, sogar wenn die Optionen -a, -i oder -p das Paket als zu verarbeiten auflisten.

--remaining-packages

wirkt sich nicht auf die Pakete aus, auf die sich dieser Debhelper-Befehl bereits ausgewirkt hat (d.h. falls der Befehl im Debhelper-Protokoll des Pakets auftaucht). Falls Sie zum Beispiel den Befehl mit speziellen Optionen für nur ein paar Pakete aufrufen müssen, geben Sie diese Option beim letzten Aufruf des Befehls an, um die restlichen Pakete mit Standardeinstellungen zu verarbeiten.

--ignore=Datei

ignoriert die angegebene Datei. Dies ist sinnvoll, falls debian/ eine Debhelper-Konfigurationsdatei enthält, auf die ein Debhelper-Befehl nicht einwirken soll. Beachten Sie, dass debian/compat, debian/control und debian/changelog nicht ignoriert werden können, andererseits sollte es nie einen Grund geben, diese Dateien zu ignorieren. Falls die Originalautoren zum Beispiel ein debian/init liefern, von dem Sie nicht wünschen, dass dh_installinit es installiert, benutzen Sie --ignore=debian/init

-Ptemporäres_Verzeichnis, --tmpdir=temporäres_Verzeichnis

benutzt temporäres_Verzeichnis als Bauverzeichnis des Pakets. Voreinstellung ist debian/Paket.

--mainpackage=Paket

Diese selten benutzte Option ändert, welches Paket Debhelper als »Hauptpaket« ansieht, sprich das erste in debian/control aufgeführte und das, für das debian/foo-Dateien, statt der üblichen debian/Paket.foo-Dateien verwandt werden können.

-O=Option|Bündel

Dies wird von dh(1) verwandt, wenn benutzerdefinierte Optionen an alle von ihm ausgeführten Befehle weitergereicht werden. Falls der Befehl die angegebene Option oder das Bündel von Optionen unterstützt, kommt er zum Tragen. Falls der Befehl (oder irgend ein Teil eines Optionenbündels) den Befehl nicht unterstützt, wird er ignoriert.

## HÄUFIGE DEBHELPER-OPTIONEN
Die folgende Befehlszeile wird von einigen Debhelper-Programmen unterstützt. Eine vollständige Erklärung, was jede Option tut, finden Sie in den Handbuchseiten jedes einzelnen Programms.

-n

verändert keine postinst-, postrm- etc. Skripte

-XElement, --exclude=Element

schließt ein Element von der Verarbeitung aus. Diese Option kann mehrfach benutzt werden, um mehr als nur eins auszuschließen. Das \fElement\fR ist üblicherweise Teil eines Dateinamens und jede Datei, die den angegebenen Text enthält, wird ausgeschlossen.

-A, --all

bewirkt, dass Dateien oder andere Elemente, die auf der Befehlszeile angegeben wurden, sich in ALLEN entsprechenden Paketen auswirken, nicht nur im ersten.

## BAUSYSTEMOPTIONEN
Die folgenden Befehlszeilenoptionen werden von allen dh_auto_*-Debhelper-Ptogrammen unterstützt. Diese Programme unterstützen eine Vielzahl von Bausystemen und bestimmen normalerweise heuristisch, welches benutzt werden soll und wie es verwendet wird. Sie können diese Befehlszeilenoptionen nutzen, um das Standardverhalten zu ändern. Typischerweise werden sie an dh(1) übergeben, das sie dann an all die dh_auto_*-Programme übergibt.

-SBausystem, --buildsystem=Bausystem

erzwingt die Benutzung des angegebenen Bausystems, anstatt zu versuchen, automatisch eins auszuwählen, das für das Paket geeignet sein könnte.

-DVerzeichnis, --sourcedirectory=Verzeichnis

geht davon aus, dass der Quellverzeichnisbaum des Originalpakets im angegebenen Verzeichnis, anstatt auf der obersten Verzeichnisebene des Debian-Quellpaketverzeichnisbaums, liegt.

-B[Verzeichnis], --builddirectory=[Verzeichnis]

Enable out of source building and use the specified directory as the build directory. If directory parameter is omitted, a default build directory will be chosen. Falls diese Option nicht angegeben ist, wird standardmäßig in der Quelle gebaut, falls das Bausystem nicht das Bauen außerhalb des Quellverzeichnisbaums erfordert oder bevorzugt. In einem solchen Fall wird ein Standardbauverzeichnis benutzt, selbst wenn --builddirectory angegeben wurde.

Falls das Bausystem das Bauen außerhalb des Quellverzeichnisbaums bevorzugt, aber das Bauen innerhalb der Quelle immer noch erlaubt, kann Letzteres wieder aktiviert werden, indem ein Bauverzeichnispfad übergeben wird, der dem Quellverzeichnispfad entspricht.

--parallel, --no-parallel

Control whether parallel builds should be used if underlying build system supports them. The number of parallel jobs is controlled by the DEB_BUILD_OPTIONS environment variable ("Debian Policy, section 4.9.1") at build time. It might also be subject to a build system specific limit. If neither option are not specified, debhelper currently defaults to --parallel in compat 10 (or later) and --no-parallel otherwise.

As an optimization, dh will try to avoid passing these options to subprocesses, if they are unncessary and the only options passed. Notably this happens when DEB_BUILD_OPTIONS does not have a parallel parameter (or its value is 1).

--max-parallel=Maximum

Diese Option impliziert --parallel und erlaubt die weitere Begrenzung der Anzahl von Aufgaben, die bei einem parallelen Bauen benutzt werden können. Falls bekannt ist, dass das Bauen des Pakets nur mit einer bestimmten Stufe der Gleichzeitigkeit funktioniert, können Sie diese auf die maximale Stufe setzen, von der bekannt ist, dass sie funktioniert oder auf die, von der Sie wünschen, dass sie unterstützt wird. Notably, setting the maximum to 1 is effectively the same as using --no-parallel.

--list, -l

listet alle Bausysteme auf, die auf diesem System von Debhelper unterstützt werden. Diese Liste enthält sowohl Standardbausysteme als auch Bausysteme Dritter (als solche gekennzeichnet). Außerdem zeigt es, welches Bausystem automatisch ausgewählt würde oder welches durch die Option --buildsystem manuell angegeben wird.

## KOMPATIBILITÄTSSTUFEN
Von Zeit zu Zeit müssen wesentliche, nicht rückwärtskompatible Änderungen an Debhelper vorgenommen werden, um es so ordentlich und gut entworfen wie nötig zu halten und weil sein Autor mehr Erfahrung gewinnt. Um zu verhindern, dass solche wesentlichen Änderungen existierende Pakete kaputt machen, wurde das Konzept der Debhelper-Kompatibilitätsstufen eingeführt. Sie teilen Debhelper mit, welche Kompatibilitätsstufe es nutzen sollte und sie ändern sein Verhalten auf verschiedene Arten.

Schreiben Sie eine Zahl nach debian/compat, um Debhelper mitzuteilen, welche Kompatibilitätsstufe es nutzen soll. Um beispielsweise in den Modus V9 zu schalten geben Sie Folgendes ein:

```
  % echo 9 > debian/compat
```

Ihr Paket wird außerdem eine Bauabhängigkeit mit Versionspflege auf eine Debhelper-Version benötigen, die gleich (oder größer) als die ist, die von der Kompatibilitätsstufe Ihres Pakets verwandt wird. Daher müssen Sie für Kompatibilitätsstufe 9 sicherstellen, dass debian/control Folgendes hat:

```
  Build-Depends: debhelper (>= 9)
```

Wenn nicht anders angegeben, geht sämtliche Debhelper-Dokumentation davon aus, dass Sie die aktuellste Kompatibilitätsstufe nutzen und in den meisten Fällen wird nicht angezeigt, wenn sich dieses Verhalten von einer früheren Kompatibilitätsstufe unterscheidet. Wenn Sie also nicht die aktuellste Kompatibilitätsstufe benutzen, sind Sie gut beraten, das Folgende zu lesen, um Hinweise zu erhalten, was sich gegenüber früheren Kompatibilitätsstufen unterscheidet.

Diese Kompatibilitätsstufen sind verfügbar:

v1

Dies ist die Original-Debhelper-Kompatibilitätsstufe und daher ist sie die Vorgabe. In diesem Modus wird Debhelper debian/tmp als Paketverzeichnisbaum des ersten in der Datei »control« aufgeführten Pakets nehmen, während für alle anderen in der Datei control aufgeführten Pakete debian/Paket genommen wird. Dieser Modus ist missbilligt.

v2

In diesem Modus wird Debhelper durchweg debian/Paket als Paketverzeichnisbaum für jedes Paket nehmen, das gebaut wird. Dieser Modus ist missbilligt.

v3

Dieser Modus funktioniert wie v2 mit den folgenden Zusätzen:

- Debhelper-Konfigurationsdateien unterstützen Platzhalter mittels * und ?, wenn geeignet. Um dies auszuschalten und diese Zeichen im Rohzustand zu verwenden, stellen Sie ihnen einen Rückwärtsschragstrich voran.

- dh_makeshlibs lässt postinst- und postrm-Skripte ldconfig aufrufen.

- Jede Datei in etc/ wird automatisch durch dh_installdeb als Conffile markiert.

Dieser Modus ist missbilligt.

v4

Änderungen gegenüber v3 sind:

- dh_makeshlibs -V wird nicht den Debian-Teil der Versionsnummer in der erzeugten Abhängigkeitslinie in der Shlibs-Datei enthalten.

- Sie werden aufgefordert, das neue ${misc:Depends} in debian/control abzulegen, um das Feld ${shlibs:Depends} zu ergänzen.

- dh_fixperms wird alle Dateien in bin/-Verzeichnissen und in etc/init.d ausführbar machen.

- dh_link wird bestehende Verweise korrigieren, damit sie konform mit der Richtlinie sind.

Dieser Modus ist missbilligt.

v5

Änderungen gegenüber v4 sind:

- Kommentare in Debhelper-Konfigurationsdateien werden ignoriert.

- dh_strip --dbg-package gibt nun den Name des Pakets an, in das Debug-Symbole getan werden, nicht die Pakete, aus denen die Symbole genommen werden.

- dh_installdocs überspringt die Installation leerer Dateien.

- dh_install gibt Fehlermeldungen aus, wenn Platzhalter zu nichts expandieren.

v6

Änderungen gegenüber v5 sind:

- Befehle, die Fragmente von Betreuerskripten erzeugen, werden die Fragmente für die prerm- und postrm-Skripte in umgekehrter Reiherfolge anordnen.

- dh_installwm wird einen untergeordneten Handbuchseitenverweis für x-window-manager.1.gz installieren. falls es die Handbuchseite in usr/share/man/man1 im Bauverzeichnis des Pakets entdeckt.

- dh_builddeb löschte vorher nichts, was auf DH_ALWAYS_EXCLUDE passte, aber es wurde auf eine Liste von Dingen gesetzt, die ausgeschlossen werden sollen, wie CVS:.svn:.git. Nun tut es dies.

- dh_installman erlaubt das Überschreiben existierender Handbuchseiten im Bauverzeichnis des Pakets. In vorhergehenden Kompatibilitätsstufen lehnte es lautlos ab, dies zu tun.

v7

Änderungen gegenüber v6 sind:

- dh_install wird darauf zurückgreifen, in debian/tmp nach Dateien zu suchen, falls es sie nicht im aktuellen Verzeichnis findet (oder wo auch immer Sie es unter Benutzung von --sourcedir vorgeben). Dies ermöglicht dh_install mit dh_auto_install zusammenzuarbeiten, das nach debian/tmp installiert, ohne irgendwelche besonderen Parameter zu benötigen.

- dh_clean wird debian/clean lesen und die dort aufgeführten Dateien löschen.

- <dh_clean> wird die *-stamp-Dateien der obersten Ebene löschen.

- dh_installchangelogs wird abschätzen, in welcher Datei das Änderungsprotokoll der Originalautoren liegt, falls keines angegeben wurde.

v8

Änderungen gegenüber v7 sind:

- Befehle werden fehlschlagen, anstatt zu warnen, wenn ihnen unbekannte Optionen übergeben werden.

- dh_makeshlibs wird dpkg-gensymbols auf allen gemeinsam benutzten Bibliotheken ausführen, für die es Shlib-Dateien erzeugt. Daher kann -X verwandt werden, um Bibliotheken auszuschließen. Außerdem würden Bibliotheken an unüblichen Speicherplätzen, die dpkg-gensymbols nicht verarbeiten würde, bevor es sie übergeben bekäme, eine Verhaltenweise ändern, was dazu führen könnte, dass der Bau einiger Pakete fehlschlagen würde.

- dh erfordert, dass die auszuführende Sequenz als erster Parameter angegeben wird und sämtliche Schalter danach kommen. »dh $@ --foo« nicht »dh --foo $@«.

- dh_auto_* bevorzugt Perls Module::Build gegenüber Makefile.PL.

v9

Dies ist der empfohlene Betriebsmodus. Änderungen gegenüber v8 sind:

- Multiarch-Unterstützung. Insbesondere gibt dh_auto_configure Multiarch-Verzeichnisse an Autoconf in --libdir and --libexecdir weiter.

- dh kennt die üblichen Abhängigkeiten zwischen Zielen in debian/rules. Daher wird »dh binary« alle »build«-, »build-arch«-, »build-indep«-, »install«-Ziele etc. ausführen, die in dieser Regeldatei stehen. Es ist nicht nötig, explizit ein binäres Ziel mit expliziten Abhängigkeiten zu den anderen Zielen zu definieren.

- dh_strip komprimiert Debug-Symboldateien, um die installierte Größe von »-dbg«-Paketen zu verringern.

- dh_auto_configure enthält nicht den Quellpaketnamen in --libexecdir, wenn Autoconf benutzt wird.

- Standardmäßig aktiviert dh nicht --with=python-support.

- Alle dh_auto_*-Debhelper-Programme und dh setzen Umgebungsvariablen, die durch dpkg-buildflags aufgelistet werden, wenn sie nicht bereits gesetzt sind.

- dh_auto_configure übergibt CFLAGS, CPPFLAGS und LDFLAGS von dpkg-buildflags an Perls Makefile.PL und Build.PL.

- dh_strip legt getrennte Debug-Symbole an einer Stelle ab, die auf ihrer Baukennzahl basiert.

- Ausführbare Debhelper-Konfigurationsdateien werden ausgeführt und ihre Ausgabe wird als Konfiguration benutzt.

v10

Diese Kompatibilitätsstufe ist immer noch in Entwicklung; benutzen Sie sie mit Vorsicht. Änderungen gegenüber v9 sind:

- dh_installinit wird nicht mehr eine Datei namens debian/Paket als Init-Skript installieren.

- dh_installdocs will error out if it detects links created with --link-doc between packages of architecture "all" and non-"all" as it breaks binNMUs.

- dh erstellt das Bauverzeichnis des Pakets nicht mehr, wenn die Ausführung von Debhelper-Befehlen übersprungen wird. Dies wird auf Pakete, die nur mit Debhelper-Befehlen bauen, keine Auswirkungen haben, es könnte aber Fehler in Befehlen offenlegen, die nicht in Debhelper enthalten sind.

- dh_installdeb no longer installs a maintainer-provided debian/package.shlibs file. This is now done by dh_makeshlibs instead.

- dh_installwm refuses to create a broken package if no man page can be found (required to register for the x-window-manager alternative).

- Debhelper will default to --parallel for all buildsystems that support parallel building. This can be disabled by using either --no-parallel or passing --max-parallel with a value of 1.

## ANMERKUNGEN

### Unterstützung mehrerer Binärpakete
Falls Ihr Quellpaket mehr als ein Binärpaket erzeugt, werden Debhelper-Programme standardmäßig bei der Ausführung auf alle Paketen einwirken. Falls es vorkommt, dass Ihr Quellpaket ein architekturabhängiges Paket und ein anderes architekturunabhängiges Paket erzeugt, ist dies nicht das korrekte Verhalten, da Sie die architekturabhängigen Pakete im debian/rules-Ziel »binary-arch« erzeugen müssen und die unabhängigen Pakete im debian/rules-Ziel »binary-indep«.

To facilitate this, as well as give you more control over which packages are acted on by debhelper programs, all debhelper programs accept the -a, -i, -p, and -s parameters. These parameters are cumulative. If none are given, debhelper programs default to acting on all packages listed in the control file, with the exceptions below.

First, any package whose Architecture field in debian/control does not match the build architecture will be excluded ("Debian Policy, section 5.6.8").

Also, some additional packages may be excluded based on the contents of the DEB_BUILD_PROFILES environment variable and Build-Profiles fields in binary package stanzas in debian/control, according to the draft policy at <https://wiki.debian.org/BuildProfileSpec>.

### Automatisches Erzeugen von Debian-Installationsskripten
Einige Debhelper-Befehle werden automatisch Teile der Debian-Betreuerskripte erzeugen. Falls Sie diese automatisch erzeugten Dinge in Ihre existierenden Debian-Betreuerskripte einfügen möchten, dann müssen Sie Ihren Skripten #DEBHELPER# an der Stelle hinzufügen, an die der Kode hinzugefügt werden soll. #DEBHELPER# wird bei der Ausführung durch irgendeinen automatisch erzeugten Kode ersetzt.

Falls ein Skript überhaupt noch nicht existiert und Debhelper etwas darin hinzufügen muss, dann wird Debhelper das komplette Skript erstellen.

Alle Debhelper-Befehle, die auf diese Art automatisch Kode erzeugen, lassen dies durch den Parameter -n deaktiviert (siehe oben).

Beachten Sie, dass der eingefügte Kode Shell-Kode sein wird. Sie können ihn daher nicht direkt in einem Perl-Skript verwenden. Falls Sie ihn in ein Perl-Skript einbetten wollen, wird hier eine Möglichkeit beschrieben, dies zu tun (beachten Sie, dass über den Befehl »set« sichergestellt wird, dass $1, $2, etc. gesetzt sind):

```
  my $temp="set -e\nset -- @ARGV\n" . << 'EOF';
  #DEBHELPER#
  EOF
  if (system($temp)) {
     my $exit_code = ($? >> 8) & 0xff;
     my $signal = $? & 0x7f;
     if ($exit_code) {
         die("The debhelper script failed with error code: ${exit_code}");
     } else {
         die("The debhelper script was killed by signal: ${signal}");
     }
  }
```

### Automatisches Erzeugen verschiedener Abhängigkeiten
Einige Debhelper-Befehle könnten dazu führen, dass das erzeugte Paket von einigen anderen Paketen abhängt. Falls Sie beispielsweise dh_installdebconf(1) benutzen, wird Ihr Paket von Debconf abhängen müssen. Oder, falls Sie dh_installxfonts(1) verwenden, wird ihr Paket generell von einer bestimmten Version der Xutils abhängen. Den Überblick über diese verschiedenen Abhängigkeiten zu behalten kann lästig sein, da sie davon abhängen, wie Debhelper Dinge tut, weswegen Debhelper eine Möglichkeit bietet, sie zu automatisieren.

Für jeden Befehl werden die benötigten Abhängigkeiten in den Handbuchseiten dokumentiert. Daneben wird automatisch eine »substvar« erzeugt, die ${misc:Depends} genannt wird. Falls Sie eine Markierung in Ihre debian/control-Datei schreiben, wird es sie zu den Abhängigkeiten expandieren, von denen Debhelper findet, dass Sie sie benötigen.

Dies ist gänzlich unabhängig von dem vorgegebenen ${shlibs:Depends}, das durch dh_makeshlibs(1) erzeugt wurde und den durch dh_perl(1) erzeugten ${perl:Depends}. Sie können auswählen, keines davon zu benutzen, falls die Einschätzung von Debhelper nicht der Wirklichkeit entspricht.

### Paketbauverzeichnisse
Standardmäßig gehen alle Debhelper-Programme davon aus, dass das temporäre Verzeichnis, das zum Zusammenbau des Dateibaums in einem Paket benutzt wird, debian/Paket ist.

Manchmal wollen Sie möglicherweise ein anderes temporäres Vezeichnis benutzen. Dies wird durch den Schalters -P unterstützt. »dh_installdocs -Pdebian/tmp« wird zum Beispiel debian/tmp als temporäres Verzeichnis nutzen. Beachten Sie, falls Sie -P verwenden, dass die Debhelper-Programme nur auf ein einzelnes Paket auf einmal einwirken kann. Falls Sie also ein Paket haben, das mehrere Binärpakete baut, müssen Sie außerdem den Schalter -p einsetzen, um anzugeben, auf welches Binärpaket sich das Debhelper-Programm auswirkt.

### Udebs
Debhelper beinhaltet Unterstützung für Udebs. Um ein Udeb mit Debhelper zu erstellen, fügen Sie dem Absatz des Pakets in debian/control »Package-Type: udeb« hinzu. Debhelper wird versuchen, Udebs zu erstellen, die der Debian-Installer-Richtlinie entsprechen, indem die erzeugten Paketdateien mit .udeb enden, indem keine Dokumentation in ein Udeb installiert wird und indem preinst-, postrm-, prerm- und config-Skripte etc. übersprungen werden.

## UMGEBUNGSVARIABLEN
The following environment variables can influence the behavior of debhelper. It is important to note that these must be actual environment variables in order to function properly (not simply Makefile variables). To specify them properly in debian/rules, be sure to "export" them. For example, "export DH_VERBOSE".

DH_VERBOSE

Set to 1 to enable verbose mode. Debhelper will output every command it runs. Also enables verbose build logs for some build systems like autoconf.

DH_QUIET

Set to 1 to enable quiet mode. Debhelper will not output commands calling the upstream build system nor will dh print which subcommands are called and depending on the upstream build system might make that more quiet, too. This makes it easier to spot important messages but makes the output quite useless as buildd log. Ignored if DH_VERBOSE is also set.

DH_COMPAT

gibt vorübergehend an, auf welcher Kompatibilitätsstufe Debhelper ausgeführt werden sollte und setzt dabei jeden Wert in debian/compat außer Kraft.

DH_NO_ACT

auf 1 gesetzt, um Modus ohne Aktion zu aktivieren.

DH_OPTIONS

Alles in dieser Variable wird den Befehlszeilenargumenten aller Debhelper-Befehle vorangestellt. Wenn dh(1) benutzt wird, können ihm Optionen übergeben werden, die es an jeden Debhelper-Befehl weitergibt, was im Allgemeinen besser ist, als DH_OPTIONS zu verwenden.

DH_ALWAYS_EXCLUDE

Falls gesetzt, fügt dies den Wert, auf den die Variable gesetzt ist, den -X-Optionen aller Befehle hinzu, die die Option -X unterstützen. Außerdem wird dh_builddeb für alles, das dem Wert in Ihrem Paketbaubaum entspricht, rm -rf ausführen. Dies kann nützlich sein, falls Sie aus einem CVS-Quellverzeichnisbaum bauen. In diesem Fall verhindert das Setzen von DH_ALWAYS_EXCLUDE=CVS, dass irgendwelche CVS-Verzeichnisse sich in das Paket einschleichen, das Sie bauen. Oder, falls ein Paket einen Quell-Tarball hat, der (unklugerweise) CVS-Verzeichnisse enthält, möchten Sie möglicherweise DH_ALWAYS_EXCLUDE=CVS in debian/rules exportieren, damit es wirksam ist, wo auch immer Ihr Paket gebaut wird.

Mehrere Dinge, die ausgeschlossen werden sollen, können mit Doppelpunkten getrennt werden, wie in DH_ALWAYS_EXCLUDE=CVS:.svn.

## SIEHE AUCH
/usr/share/doc/debhelper/examples/

eine Zusammenstellung von debian/rules-Beispieldateien, die Debhelper benutzen

<http://joeyh.name/code/debhelper/>

Debhelper-Website

## ÜBERSETZUNG
Diese Übersetzung wurde mit dem Werkzeug po4a <http://po4a.alioth.debian.org/> durch Chris Leick c.leick@vollbio.de und das deutsche Debian-Übersetzer-Team im Dezember 2011 erstellt.

Bitte melden Sie alle Fehler in der Übersetzung an debian-l10n-german@lists.debian.org oder als Fehlerbericht an das Paket debhelper.

Sie können mit dem folgenden Befehl das englische Original anzeigen man -L en Abschnitt Handbuchseite

## AUTOR
Joey Hess <joeyh@debian.org>


debhelper.es

title: debhelper.es(7)

summary: El conjunto de herramientas debhelper

text:
# debhelper.es(7)

## NOMBRE
debhelper - El conjunto de herramientas debhelper

## SINOPSIS
dh_* [-v] [-a] [-i] [-s] [--no-act] [-ppaquete] [-Npaquete] [-Pdirectorio-temporal]

## DESCRIPCIÓN
debhelper ayuda a construir un paquete de Debian. La filosofía que se esconde detrás de debhelper es ofrecer una colección de herramientas pequeñas, simples y fáciles de entender que se utilizan en debian/rules para automatizar varios aspectos comunes a la hora de construir un paquete. Esto hace que usted, el empaquetador, tenga menos trabajo. Además, si cambian las directrices de Debian, los paquetes que precisan cambios sólo necesitan ser reconstruidos para que se ajusten a las nuevas directrices.

Un fichero debian/rules típico que utiliza debhelper invoca órdenes de debhelper en cadena, o utiliza dh(1) para automatizar el proceso. Puede encontrar ejemplos de ficheros «rules» que usan debhelper en /usr/share/doc/debhelper/examples/.

Para crear un nuevo paquete de Debian utilizando debhelper, simplemente puede copiar uno de los ficheros «rules» de ejemplo y editarlo a mano, o utilizar el paquete dh-make, que contiene la orden dh_make, que automatiza parcialmente el proceso. Para una introducción más apropiada, el paquete maint-guide contiene una guía que muestra cómo hacer su primer paquete que utiliza debhelper (N. del T. existe una versión traducida al castellano en el paquete maint-guide-es).

## ÓRDENES DE DEBHELPER
A continuación se muestra una lista de las órdenes de debhelper que puede usar. Para más información consulte sus respectivas páginas de manual.

dh_auto_build(1)

Construye un paquete de forma automática

dh_auto_clean(1)

Limpia automáticamente después de una construcción

dh_auto_configure(1)

Configura un paquete automáticamente antes de la construcción

dh_auto_install(1)

Ejecuta «make install» o similar automáticamente

dh_auto_test(1)

Ejecuta automáticamente un conjunto de pruebas de un paquete

dh_bugfiles(1)

Instala ficheros personalizados para el informe de fallos en los directorios de construcción del paquete

dh_builddeb(1)

Construye paquetes binarios de Debian

dh_clean(1)

Limpia los directorios de construcción de paquete

dh_compress(1)

Comprime ficheros y arregla enlaces simbólicos en los directorios de construcción del paquete

dh_fixperms(1)

Arregla los permisos de los ficheros en los directorios de construcción

dh_gconf(1)

Instala ficheros de valores predeterminados de GConf y registra esquemas

dh_gencontrol(1)

Genera e instala el fichero de control

dh_icons(1)

Update caches of Freedesktop icons

dh_installcatalogs(1)

Instala y registra catálogos SGML

dh_installchangelogs(1)

Instala los ficheros de cambios en los directorios de construcción

dh_installcron(1)

Instala scripts para cron en etc/cron.*

dh_installdeb(1)

Instala ficheros en el directorio DEBIAN

dh_installdebconf(1)

Instala ficheros utilizados por debconf en los directorios de construcción

dh_installdirs(1)

Crea subdirectorios en los directorios de construcción del paquete

dh_installdocs(1)

Instala documentación en los directorios de construcción del paquete

dh_installemacsen(1)

Registra un paquete de extensión de Emacs

dh_installexamples(1)

Instala ficheros de ejemplo en los directorios de construcción

dh_installifupdown(1)

Instala «hooks» para if-up e if-down

dh_installinfo(1)

Instala ficheros info

dh_installinit(1)

install service init files into package build directories

dh_installlogcheck(1)

Instala ficheros de reglas para logcheck en etc/logcheck/

dh_installlogrotate(1)

Instala ficheros de configuración de logrotate

dh_installman(1)

Instala páginas de manual en los directorios de construcción del paquete

dh_installmenu(1)

Instala ficheros de menú de Debian en los directorios de construcción del paquete

dh_installmime(1)

Instala ficheros mime en los directorios de construcción del paquete

dh_installmodules(1)

register kernel modules

dh_installpam(1)

Instala ficheros de compatibilidad de pam

dh_installppp(1)

Instala los ficheros ip-up e ip-down de ppp

dh_installinfo(1)

Instala ficheros de reglas de udev

dh_installwm(1)

Registra un gestor de ventanas

dh_installxfonts(1)

Registra tipos de letra para X

dh_link(1)

Crea enlace simbólicos en los directorios de construcción del paquete

dh_lintian(1)

Instala ficheros «override» de lintian en los directorios de construcción del paquete

dh_listpackages(1)

Lista los paquetes binarios sobre los que actuará debhelper

dh_makeshlibs(1)

Crea automáticamente el fichero «shlibs» e invoca dpkg-gensymbols

dh_md5sums(1)

Genera el fichero DEBIAN/md5sums

dh_movefiles(1)

Mueve ficheros desde debian/tmp a subpaquetes

dh_perl(1)

Calcula dependencias de Perl y limpia después de MakeMaker

dh_prep(1)

Realiza una limpieza para preparar la construcción de un paquete binario

dh_shlibdeps(1)

Calcula dependencias sobre bibliotecas compartidas

dh_testdir(1)

Comprueba el directorio antes de construir un paquete de Debian

dh_testroot(1)

Compruebe que el paquete se construye como usuario «root»

dh_usrlocal(1)

Migra directorios «usr/local» a scripts del desarrollador

### Órdenes obsoletas
Existe un conjunto de órdenes de debhelper que han quedado obsoletas y que no se deberían utilizar.

dh_desktop(1)

Orden obsoleta sin efecto

dh_installmanpages(1)

Instalador de viejo estilo de páginas de manual (obsoleto)

dh_scrollkeeper(1)

Orden obsoleta sin efecto

dh_suidregister(1)

Programa de registro suid (obsoleto)

dh_undocumented(1)

Programa de enlace simbólico a undocumented.7 (orden obsoleta sin efecto)

### Otras órdenes
Si el nombre de un programa empieza con dh_, y no está en las listas anteriores, no es parte del paquete debhelper, pero aún así debería funcionar como los programas descritos en está página.

## FICHEROS DE CONFIGURACIÓN DE DEBHELPER
Muchas de las órdenes de debhelper hacen uso de ficheros en debian/ para controlar lo que hacen. Además de los ficheros comunes debian/changelog y debian/control, que están en todos los paquetes, no sólo aquellos que utilizan debhelper, se pueden utilizar ficheros adicionales para configurar el comportamiento de una orden específica de debhelper. Estos ficheros se suelen llamar «debian/paquete.tal» (donde paquete es reemplazado por el paquete sobre el que se está actuando).

Por ejemplo, dh_installdocs utiliza ficheros llamados debian/paquete.docs para listar los ficheros de documentación que instalará. Consulte las páginas de manual de cada orden para conocer más detalles acerca de los nombres y formatos de los ficheros que utilizan. Habitualmente, estos ficheros listan los ficheros sobre los que se actúa, uno por línea. Algunos programas de debhelper utilizan parejas de ficheros y destinos o algún formato un poco más complicado.

Tenga en cuenta que si un paquete es el primero (o el único) paquete binario listado en debian/control, debhelper utiliza debian/tal si no existe un fichero debian/paquete.tal.

En algunos casos especiales, puede querer tener diferentes versiones de estos ficheros para diferentes arquitecturas o sistemas operativos. Si los ficheros «debian/paquete.tal.ARCH» y «debian/paquete.tal.OS» existen, donde ARCH y OS son igual a las salidas de «dpkg-architecture -qDEB_HOST_ARCH» / «dpkg-architecture -qDEB_HOST_ARCH_OS», se utilizarán preferentemente a otros ficheros generales.

Generalmente, estos ficheros de configuración se utilizan para definir varios tipos de ficheros. Documentación o ficheros de ejemplo a instalar, ficheros a mover, y demás. Cuando sea apropiado, en casos como estos, puede utilizar comodines del intérprete de órdenes como (?, * y clases de carácter [..]) en estos ficheros. También puede incluir comentarios en estos ficheros; se ignoran las líneas que empiezan con #.

La sintaxis de estos ficheros es intencionadamente sencilla para facilitar la lectura, la comprensión y la modificación. Si prefiere potencia y complejidad, puede dar al fichero permisos de ejecución, y crear un programa que muestra un contenido adecuado para la situación dada. Si lo hace, la salida no se proceso para expandir comodines o eliminar comentarios.

## OPCIONES COMPARTIDAS DE DEBHELPER
Las siguientes opciones de línea de órdenes son aceptadas por todos los programas de debhelper.

-v, --verbose

Modo explicativo: muestra todas las órdenes que modifican el directorio de construcción del paquete.

--no-act

No hace nada realmente. Si se utiliza con «-v», mostrará todo lo que hubiera hecho.

-a, --arch

Actúa sobre todos los paquetes dependientes de la arquitectura que se deberían construir para la arquitectura de construcción.

-i, --indep

Actúa en todos los paquetes independientes de la arquitectura.

-ppaquete, --package=paquete

Actúa sobre el paquete nombrado paquete. Esta opción se puede definir varias veces para hacer que debhelper opere sobre un conjunto dado de paquetes.

-s, --same-arch

Solía ser una versión más inteligente de la opción -a, pero actualmente la opción -a es igual de inteligente.

-Npaquete, --no-package=paquete

No actúa sobre un paquete especificado incluso si las opciones -a, -i, o -p listan este paquete como uno sobre los que se debería actuar.

--remaining-packages

No actúa sobre los paquetes sobre los que ya se actuó anteriormente con esta orden de debhelper (esto es, si la orden está presente en el registro de debhelper). Por ejemplo, si necesita invocar la orden con opciones particulares para una pareja de paquetes binarios, introduzca esta opción a la última invocación de la orden para procesar el resto de paquetes con la configuración predeterminada.

--ignore=fichero

Ignora el fichero dado. Se puede utilizar si debian/ contiene un fichero de configuración de debhelper sobre el que una orden de debhelper no debería actuar. Tenga en cuenta que no puede ignorar debian/compat, debian/control y debian/changelog, aunque nunca debería existir una razón para ignorar esos ficheros. Por ejemplo, si la fuente original distribuye un fichero debian/init que no desea que dh_installinit instale, use --ignore=debian/init.

-Pdirectorio_temporal, --tmpdir=directorio_temporal

Utiliza directorio_temporal como el directorio de construcción del paquete. Por omisión es «debian/paquete».

--mainpackage=paquete

Esta opción poco utilizada cambia el paquete que debhelper considera el «paquete principal», esto es, el primero listado en debian/control, y sobre el cual se pueden utilizar los ficheros debian/tal en vez de los usuales debian/package.tal.

-O=opción|fichero

dh(1) utiliza está orden al orden al introducir opciones definidas por el usuario a todas las órdenes que ejecuta. Si la orden acepta la opción definida o conjunto de opciones, tendrá efecto. Si la orden no acepta la opción (o alguna sección del conjunto de opciones), se ignorará.

## OPCIONES COMUNES DE DEBHELPER
Las siguientes opciones son válidas para algunos programas de debhelper. Consulte la página de manual de cada programa para una explicación detallada de lo que hace cada una.

-n

No modifica los scripts postinst, postrm, etc.

-Xelemento, --exclude=elemento

Exclude an item from processing. This option may be used multiple times, to exclude more than one thing. The \fIitem\fR is typically part of a filename, and any file containing the specified text will be excluded.

-A, --all

Hace que los ficheros o elementos especificados en la línea de órdenes tengan efecto en TODOS los paquetes sobre los que actúa, no sólo el primero.

## OPCIONES DEL SISTEMA DE CONSTRUCCIÓN
Las siguientes opciones de línea de órdenes son compatibles con todos los programas dh_auto_* de debhelper. Estos programas permiten utilizar varios sistemas de construcción, y habitualmente realizan una estimación de cuál utilizar, y cómo. Puede utilizar estas opciones de línea de órdenes para anular el comportamiento predeterminado. Habitualmente, se introducen a dh(1), que a su vez los introduce en todos los programas dh_auto_*.

-Ssistema-de-construcción, --buildsystem=sistema-de-construcción

Fuerza el uso del sistema-de-construcción definido, en lugar de intentar seleccionar uno de forma automática que podría ser adecuado para el paquete.

-Ddirectorio, --sourcedirectory=directorio

Supone que el árbol de código fuente original del paquete está en el directorio definido, en lugar del directorio de nivel superior del árbol del paquete fuente de Debian.

-B[directorio], --builddirectory=[directorio]

Enable out of source building and use the specified directory as the build directory. If directory parameter is omitted, a default build directory will be chosen. Si no se define esta opción, la construcción tendrá lugar en las fuentes de forma predeterminada a menos que el sistema de construcción requiera o prefiera la construcción fuera del árbol de fuentes. En ese caso, se utilizará el directorio de construcción predeterminado incluso si no se define --builddirectory.

Si el sistema de construcción prefiere realizar la construcción fuera del árbol de fuentes, pero permite la construcción en las fuentes, puede reactivar lo último introduciendo una ruta al directorio de construcción igual a la ruta del directorio de fuentes.

--parallel, --no-parallel

Control whether parallel builds should be used if underlying build system supports them. The number of parallel jobs is controlled by the DEB_BUILD_OPTIONS environment variable ("Debian Policy, section 4.9.1") at build time. It might also be subject to a build system specific limit. If neither option are not specified, debhelper currently defaults to --parallel in compat 10 (or later) and --no-parallel otherwise.

As an optimization, dh will try to avoid passing these options to subprocesses, if they are unncessary and the only options passed. Notably this happens when DEB_BUILD_OPTIONS does not have a parallel parameter (or its value is 1).

--max-parallel=máximo

Esta opción implica --parallel, y permite limitar el número de tareas que se pueden utilizar en una construcción en paralelo. Si se sabe que la construcción del paquete sólo funciona con ciertos niveles de concurrencia, puede definir esto con el nivel máximo conocido con el que funciona, o que desea permitir. Notably, setting the maximum to 1 is effectively the same as using --no-parallel.

--list, -l

Lista todos los sistemas construcción en el sistema que debhelper acepta. La lista incluye sistemas de construcción de terceras fuentes (marcadas como tal) y la predeterminada. También muestra el sistema de construcción que se seleccionará automáticamente, o cuál está definido mediante la opción --buildsystem.

## NIVELES DE COMPATIBILIDAD
Cada cierto tiempo, debhelper necesita cambios que lo pueden hacer incompatible con versiones anteriores para así continuar con un buen y limpio diseño a medida que las necesidades cambian y que su autor gana más experiencia. Los niveles de compatibilidad de debhelper se crearon para impedir que estos cambios estropeen algún paquete. Según el nivel de compatibilidad que se especifique debhelper se comporta de diferentes maneras.

Para especificar a debhelper qué nivel de compatibilidad debe utilizar, escriba un número en debian/compat. Por ejemplo, para activar el modo v9:

```
  % echo 9 > debian/compat
```

El paquete también requiere como dependencia de construcción («build-depend») una versión de debhelper igual o mayor que el nivel de compatibilidad de debhelper que utiliza el paquete. Por ejemplo, para utilizar el nivel de compatibilidad 9, compruebe que «debian/control» contiene lo siguiente:

```
  Build-Depends: debhelper (>= 9)
```

A menos que se indique lo contrario, toda la documentación de debhelper supone que utiliza el nivel de compatibilidad más reciente, y en la mayoría de los casos no indica si el comportamiento de debhelper es distinto bajo otro nivel de compatibilidad. Por ello, si no está utilizando el nivel de compatibilidad más reciente, recomendamos que lea a continuación las notas acerca de las diferencias con anteriores niveles de compatibilidad.

Los niveles de compatibilidad disponibles son:

v1

Este es el nivel de compatibilidad original de debhelper, y por tanto es el nivel predeterminado. En este modo, debhelper utiliza debian/tmp como el árbol de directorios del paquete, y «debian/paquete» para el resto de paquetes listados en el fichero control. Este modo está obsoleto.

v2

En este modo, debhelper utilizará «debian/paquete» de forma consistente como el árbol de directorios para cada paquete que se construya. Este modo está obsoleto.

v3

Este modo funciona como v2, con los siguientes añadidos:

- Los ficheros de configuración de Debhelper aceptan comodines globales mediante * y ? cuando sea apropiado. Para utilizar «*» y «?» como caracteres simplemente debe insertar como prefijo una barra invertida.

- dh_makeshlibs hace que los scripts postinst y postrm ejecuten ldconfig.

- dh_installdeb marca automáticamente todos los ficheros en etc/ como conffiles.

Este modo está obsoleto.

v4

Los cambios desde el nivel v3 son:

- dh_makeshlibs -V no incluirá la parte de Debian en el numero de versión generado en la línea de dependencias del fichero «shlibs».

- Se aconseja que use el nuevo ${misc:Depends} en debian/control para reemplazar el campo ${shlibs:Depends}.

- dh_fixperms hará ejecutables todos los ficheros en los directorios bin/ y etc/init.d.

- dh_link corregirá los enlaces existentes para ajustarse a las normas de Debian.

Este modo está obsoleto.

v5

Los cambios desde el nivel v4 son:

- Se ignoran los comentarios en los ficheros de configuración de debhelper.

- dh_strip --dbg-package ahora especifica el nombre del paquete en el que se colocan los símbolos de depuración, no los paquetes desde los que obtener los símbolos.

- dh_installdocs omite la instalación de ficheros vacíos.

- dh_install devuelve un error si los comodines se expanden a un valor vacío.

v6

Los cambios desde el nivel v5 son:

- Las órdenes que generan segmentos de scripts de desarrollador ordenarán estos segmentos en orden inverso para los scripts prerm y postrm.

- dh_installwm instalará un enlace esclavo a la página de manual x-window-manager.1.gz en caso de encontrar la página de manual en usr/share/man/man1 dentro del directorio de construcción del paquete.

- Anteriormente, dh_builddeb no eliminaba todo aquello que coincidiese con DH_ALWAYS_EXCLUDE, si es que se definía con una lista de elementos a excluir, como por ejemplo CVS:.svn:.git. Ahora sí lo hace.

- dh_installman permite sobreescribir páginas de manual existentes en el directorio de construcción del paquete. Bajo los niveles de compatibilidad anteriores simplemente rechazaba hacerlo, de forma silenciosa.

v7

Los cambios desde el nivel v6 son:

- dh_install buscará ficheros en debian/tmp de forma predeterminada si no los encuentra en el directorio actual (o dónde indicó hacerlo mediante --sourcedir). Esto permite la interoperabilidad entre dh_install y dh_auto_install, que instala en debian/tmp, sin necesidad de parámetros especiales.

- dh_clean leerá debian/clean y eliminará los ficheros ahí listados.

- dh_clean eliminará ficheros *-stamp del nivel superior.

- dh_installchangelogs intentará averiguar el fichero de registro de cambios de la fuente original si no se especifica ninguno.

v8

Los cambios desde el nivel v7 son:

- Las órdenes fallarán, en lugar de emitir un aviso, cuando se les introduzcan opciones desconocidas.

- dh_makeshlibs ejecutará dpkg-gensymbols sobre todas las bibliotecas compartidas para las que genera ficheros «shlibs». Por ello, puede utilizar -X para excluir bibliotecas. Así mismo, se introducirán a dpkg-gensymbols bibliotecas en ubicaciones inusuales que antes no procesaba, un cambio de comportamiento que puede impedir la construcción de algunos paquetes.

- dh requiere que la secuencia a ejecutar se defina como el primer parámetro, y que las opciones aparezcan a continuación. Por ejemplo, use dh $@ --foo, no dh --foo $@.

- dh_auto_* prefiere utilizar el módulo de Perl Module::Build con preferencia a un fichero Makefile.PL.

v9

Este es el modo de operación aconsejado. Los cambios desde el nivel v8 son:

- Compatibilidad multiarquitectura, dh_auto_configure introduce directorios multiarquitectura a autoconf en «--libdir» y «--libexecdir».

- dh es consciente de las dependencias habituales entre objetivos en «debian/rules». Por ello, «dh binary» ejecuta cualquier objetivo build, build-arch, build-indep e install que se encuentre en el fichero «rules». No es necesario definir un objetivo binario explícito con dependencias explícitas sobre otros objetivos.

- dh_strip comprime ficheros de símbolos de depuración de fallos para reducir el tamaño de los paquetes -dbg.

- dh_auto_configure no incluye el nombre de paquete fuente en «--libexecdir» al utilizar autoconf.

- dh no activa «--with=python-support» de forma predeterminada.

- Todos los programas de debhelper dh_auto_* definen variables de entorno listados en dpkg-buildflags, a menos que ya estén definidas.

- dh_auto_configure introduce dpkg-buildflags CFLAGS, CPPFLAGS, y LDFLAGS a ficheros de Perl Makefile.PL y Build.PL

- dh_strip ubica símbolos de depuración separados en una ubicación según su build-id.

- Se utilizan como configuración los ficheros de configuración ejecutables de debhelper y su salida.

v10

Este nivel de compatibilidad aún está en desarrollo, utilícelo con precaución. Los cambios desde el nivel v9 son:

- dh_installinit will no longer install a file named debian/package as an init script.

- dh_installdocs will error out if it detects links created with --link-doc between packages of architecture "all" and non-"all" as it breaks binNMUs.

- dh no longer creates the package build directory when skipping running debhelper commands. This will not affect packages that only build with debhelper commands, but it may expose bugs in commands not included in debhelper.

- dh_installdeb no longer installs a maintainer-provided debian/package.shlibs file. This is now done by dh_makeshlibs instead.

- dh_installwm refuses to create a broken package if no man page can be found (required to register for the x-window-manager alternative).

- Debhelper will default to --parallel for all buildsystems that support parallel building. This can be disabled by using either --no-parallel or passing --max-parallel with a value of 1.

## NOTAS

### Compatibilidad con varios paquetes binarios
Si su paquete fuente genera más de un paquete binario, los programas de debhelper actuarán sobre todos los paquetes binarios de forma predeterminada. Si se diera el caso de que su paquete fuente genera un paquete dependiente de la arquitectura, y otro independiente, éste no sería un comportamiento correcto porque necesitará generar los paquetes dependientes de la arquitectura en el objetivo binary-arch de debian/rules, y los paquetes independientes de la arquitectura en el objetivo binary-indep de debian/rules.

To facilitate this, as well as give you more control over which packages are acted on by debhelper programs, all debhelper programs accept the -a, -i, -p, and -s parameters. These parameters are cumulative. If none are given, debhelper programs default to acting on all packages listed in the control file, with the exceptions below.

First, any package whose Architecture field in debian/control does not match the build architecture will be excluded ("Debian Policy, section 5.6.8").

Also, some additional packages may be excluded based on the contents of the DEB_BUILD_PROFILES environment variable and Build-Profiles fields in binary package stanzas in debian/control, according to the draft policy at <https://wiki.debian.org/BuildProfileSpec>.

### Generación automática de los scripts de instalación de Debian
Algunas órdenes de debhelper generarán automáticamente parte de los scripts de instalación de Debian. Si quiere que estas órdenes generen automáticamente lo que esté incluido en sus scripts de instalación de Debian, necesitará añadir #DEBHELPER# a sus scripts, en el lugar donde el código se deba añadir. #DEBHELPER# será remplazado por cualquier código auto-generado cuando ejecute dh_installdeb.

Si el script no existe y debhelper necesita añadir algo en particular, creará el script por completo.

Todas las órdenes de debhelper que generan código automáticamente de esta manera se pueden deshabilitar con el parámetro «-n» (ver arriba).

Observe que el código insertado sera código de consola, y por ello no puede utilizarlo directamente en un script de Perl. Si desea introducirlo en un script de Perl, hágalo de la siguiente forma (tenga en cuenta que en este caso comprobé que $1, $2, etc se definen con la orden «set»):

```
  my $temp="set -e\nset -- @ARGV\n" . << 'EOF';
  #DEBHELPER#
  EOF
  if (system($temp)) {
     my $exit_code = ($? >> 8) & 0xff;
     my $signal = $? & 0x7f;
     if ($exit_code) {
         die("The debhelper script failed with error code: ${exit_code}");
     } else {
         die("The debhelper script was killed by signal: ${signal}");
     }
  }
```

### Generación automática de diversas dependencias.
Es posible que algunas órdenes de debhelper hagan que los paquetes generados dependan de otros paquetes. Por ejemplo, si utiliza dh_installdebconf(1), el paquete generado dependerá de debconf. Si utiliza dh_installxfonts(1), el paquete dependerá de una determinada versión de xutils. Llevar la cuenta de todas estas dependencias puede ser tedioso porque dependen de cómo debhelper haga las cosas, y por ello debhelper ofrece una manera de automatizarlo.

Todas las órdenes de este tipo, además de documentar qué dependencias pueden ser necesarias en sus páginas de manual, generarán automáticamente una variable de sustitución llamada ${misc:Depends}. Si introduce esta variable en el fichero debian/control, se expandirá a las dependencias que debhelper crea oportunas.

Esto es totalmente independiente del campo estándar ${shlibs:Depends} generado por dh_makeshlibs(1), y del ${perl:Depends} generada por dh_perl(1). Puede preferir no utilizar ninguno de estos si la expansión de debhelper de estas variables no es correcta.

### Directorios de construcción del paquete
Por omisión, todos los programas de debhelper asumen que el directorio temporal utilizado para ensamblar el árbol de ficheros en un paquete es «debian/paquete».

Algunas veces, puede que desee utilizar otro directorio temporal. Esto se puede conseguir con la opción -P. Por ejemplo, dh_installdocs -Pdebian/tmp, utilizará el directorio debian/tmp como directorio temporal. Tenga en cuenta que si utiliza la opción -P, los programas de debhelper sólo podrán actuar sobre un paquete a la vez. Por eso, si tiene un paquete que construye muchos paquetes binarios, tendrá que hacer uso de la opción -p para especificar el paquete binario sobre el que debhelper actuará.

### udebs
Debhelper incluye la compatibilidad con paquetes udeb. Para crear un udeb con debhelper, añada Package-Type: udeb al párrafo del paquete binario en debian/control. Debhelper tratará de crear udebs que cumplan con las normas de debian-installer, haciendo que los ficheros de los paquetes terminen en .udeb, no instalando ninguna documentación en un udeb, y omitiendo los scripts preinst, postrm, prerm, scripts config, etc.

## ENTORNO
The following environment variables can influence the behavior of debhelper. It is important to note that these must be actual environment variables in order to function properly (not simply Makefile variables). To specify them properly in debian/rules, be sure to "export" them. For example, "export DH_VERBOSE".

DH_VERBOSE

Set to 1 to enable verbose mode. Debhelper will output every command it runs. Also enables verbose build logs for some build systems like autoconf.

DH_QUIET

Set to 1 to enable quiet mode. Debhelper will not output commands calling the upstream build system nor will dh print which subcommands are called and depending on the upstream build system might make that more quiet, too. This makes it easier to spot important messages but makes the output quite useless as buildd log. Ignored if DH_VERBOSE is also set.

DH_COMPAT

Especifica temporalmente bajo qué nivel de compatibilidad debe actuar debhelper, ignorando cualquier valor en debian/compat.

DH_NO_ACT

Defina como 1 para habilitar el modo no-act.

DH_OPTIONS

Cualquier dato contenido en esta variable se añade a los argumentos de línea de órdenes de todas las órdenes de debhelper. Al utilizar dh(1), puede aceptar opciones que se introducen a cada orden de debhelper, lo que habitualmente es mejor que utilizar «DH_OPTIONS».

DH_ALWAYS_EXCLUDE

Si se define, añade su valor a la opción -X de todas las órdenes que permiten dicha opción. Es más, dh_builddeb ejecutará rm -rf con todo lo que coincida con el valor dentro del árbol de construcción del paquete. Puede ser útil si está compilando desde un árbol de CVS, en cuyo caso estableciendo DH_ALWAYS_EXCLUDE=CVS evitará que los directorios CVS se introduzcan en el paquete construido. O, si su paquete original (imprudentemente) incluye directorios CVS, puede ser útil exportar DH_ALWAYS_EXCLUDE=CVS en debian/rules, para que esto tenga efecto en cualquier sitio donde se construya el paquete.

Puede separar varias cosas a excluir mediante dos puntos, por ejemplo: DH_ALWAYS_EXCLUDE=CVS:.svn

## VÉASE TAMBIÉN
/usr/share/doc/debhelper/examples/

Varios ficheros de ejemplo debian/rules que utilizan debhelper.

<http://joeyh.name/code/debhelper/>

Sitio web de Debhelper.

## AUTOR
Joey Hess <joeyh@debian.org>

## TRADUCTOR
Traducci�n de Rub�n Porras Campo <debian-l10n-spanish@lists.debian.org> Actualizaci�n de Omar Campagne Polaino