.\" Automatically generated by Pod::Man 4.10 (Pod::Simple 3.35)
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. \*(C+ will
.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
.\" nothing in troff, for use with C<>.
.tr \(*W-
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
. ds -- \(*W-
. ds PI pi
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
. ds L" ""
. ds R" ""
. ds C` ""
. ds C' ""
'br\}
.el\{\
. ds -- \|\(em\|
. ds PI \(*p
. ds L" ``
. ds R" ''
. ds C`
. ds C'
'br\}
.\"
.\" Escape single quotes in literal strings from groff's Unicode transform.
.ie \n(.g .ds Aq \(aq
.el .ds Aq '
.\"
.\" If the F register is >0, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.\"
.\" Avoid warning from groff about undefined register 'F'.
.de IX
..
.nr rF 0
.if \n(.g .if rF .nr rF 1
.if (\n(rF:(\n(.g==0)) \{\
. if \nF \{\
. de IX
. tm Index:\\$1\t\\n%\t"\\$2"
..
. if !\nF==2 \{\
. nr % 0
. nr F 2
. \}
. \}
.\}
.rr rF
.\" ========================================================================
.\"
.IX Title "DH 1"
.TH DH 1 "2021-03-06" "13.3.3~bpo10+1" "Debhelper"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
.nh
.SH "NAME"
dh \- Debhelper\-Befehls\-Sequenzer
.SH "ÜBERSICHT"
.IX Header "ÜBERSICHT"
\&\fBdh\fR \fISequenz\fR [\fB\-\-with\fR \fIAdd-on\fR[\fB,\fR\fIAdd-on\fR …]] [\fB\-\-list\fR]
[\fIDebhelper-Optionen\fR]
.SH "BESCHREIBUNG"
.IX Header "BESCHREIBUNG"
\&\fBdh\fR führt eine Sequenz von Debhelper-Befehlen aus. Die unterstützten
\&\fISequenz\fRen entsprechen den Zielen einer \fIdebian/rules\fR\-Datei:
\&\fBbuild-arch\fR, \fBbuild-indep\fR, \fBbuild\fR, \fBclean\fR, \fBinstall-indep\fR,
\&\fBinstall-arch\fR, \fBinstall\fR, \fBbinary-arch\fR, \fBbinary-indep\fR und \fBbinary\fR.
.SH "OVERRIDE\- UND HOOK-ZIELE"
.IX Header "OVERRIDE- UND HOOK-ZIELE"
Eine \fIdebian/rules\fR\-Datei, die \fBdh\fR benutzt, kann einen Befehl in jedem
Schritt einer Sequenz außer Kraft setzen, indem sie ein Override-Ziel
(Override target) definiert. Es ist auch möglich, Befehle vor oder nach
jedem Schritt einzuspeisen, ohne den Schritt selbst zu beeinflussen.
.SS "Befehle vor oder nach einem Schritt einspeisen"
.IX Subsection "Befehle vor oder nach einem Schritt einspeisen"
\&\fIHinweis\fR: Diese Funktionalität erfordert Debhelper 12.8 oder neuer, zudem
muss das Paket Kompatibilitätsmodus 10 oder neuer nutzen.
.PP
Um Befehle vor \fIdh_Befehl\fR einzuspeisen, fügen Sie den Rules-Dateien ein
Ziel namens \fBexecute_before_\fR\fIdh_Befehl\fR hinzu. Genauso fügen Sie, wenn
Sie nach \fIdh_Befehl\fR Befehle einspeisen wollen,
\&\fBexecute_after_\fR\fIdh_Befehl\fR hinzu. Beide Ziele können für denselben
\&\fIdh_Befehl\fR benutzt werden und das sogar dann, wenn der Befehl außer Kraft
gesetzt wurde (wie nachfolgend in \*(L"Einen Befehl außer Kraft setzen\*(R"
beschrieben).
.PP
Wenn diese Ziele definiert sind, wird \fBdh\fR die Ziele vor beziehungsweise
nach dem Aufruf von \fIdh_Befehl\fR (oder dessen Override-Ziel) aufrufen.
.SS "Einen Befehl außer Kraft setzen"
.IX Subsection "Einen Befehl außer Kraft setzen"
Um \fIdh_Befehl\fR außer Kraft zu setzen, fügen Sie der Datei »rules« ein Ziel
mit Namen \fBoverride_\fR\fIdh_Befehl\fR hinzu. Sobald es normalerweise
\&\fIdh_Befehl\fR ausführen würde, wird \fBdh\fR stattdessen dieses Ziel
aufrufen. Das Override-Ziel kann dann den Befehl mit zusätzlichen Optionen
oder stattdessen ganz andere Befehle ausführen. Siehe die folgenden
Beispiele.
.SS "Architekturabhängige/\-unabhängige Override\- und Hook-Ziele"
.IX Subsection "Architekturabhängige/-unabhängige Override- und Hook-Ziele"
Die Override\- und Hook-Ziele können so definiert werden, dass sie nur
ausgeführt werden, wenn architekturabhängige bzw. \-unabhängige Pakete gebaut
werden. Benutzen Sie dazu Ziele mit Namen wie
\&\fBoverride_\fR\fIdh_Befehl\fR\fB\-arch\fR und \fBoverride_\fR\fIdh_Befehl\fR\fB\-indep\fR.
.PP
Diese Funktionalität ist seit Debhelper 8.9.7 (für Override-Ziele) und 12.8
(für Hook-Ziele) verfügbar.
.SS "Komplett leere Ziele"
.IX Subsection "Komplett leere Ziele"
Als besondere Optimierung wird \fBdh\fR ein Ziel überspringen, falls es
komplett leer ist. Dies eignet sich für Override-Ziele, bei denen der Befehl
einfach nur übersprungen und so der Mehraufwand beim Aufruf eines
Scheinziels eingespart wird.
.PP
Beachten Sie, das das Ziel komplett leer sein muss, damit dies funktioniert.
.PP
.Vb 3
\& # überspringt dh_bar auf die gute und optimierte Art
\& # hier wird eine Begründung zum Überspringen von dh_bar eingefügt
\& override_dh_bar:
\&
\&
\&
\& # überspringt dh_foo auf die langsame Art
\& override_dh_foo:
\& # hier wird eine Begründung des Überspringens von dh_foo eingefügt
\& # (diese Kommentare verursachen die Ausführung eines Scheinziels)
.Ve
.SS "Überprüfung, dass Ziele von dh aufgenommen werden"
.IX Subsection "Überprüfung, dass Ziele von dh aufgenommen werden"
Um zu bestätigen, dass \fBdh\fR ein Override\- oder Hook-Ziel gefunden hat,
können Sie beispielsweise folgenden Befehl verwenden:
.PP
.Vb 6
\& $ dh binary \-\-no\-act | grep dh_install | head \-n5
\& dh_installdirs
\& dh_install
\& debian/rules execute_after_dh_install
\& dh_installdocs
\& dh_installchangelogs
.Ve
.PP
Das \fBdebian/rules execute_after_dh_install\fR in der Ausgabe zeigt an, dass
\&\fBdh\fR ein \fBexecute_after_dh_install\fR\-Ziel registriert hat und es direkt
nach \fBdh_install\fR\|(1) ausführen würde.
.PP
Beachten Sie, dass \*(L"Komplett leere Ziele\*(R" im oberen Listing weggelassen
wurde. Damit wird es etwas schwieriger zu finden, weil Sie nach der
Weglassung eines Befehlsnamens suchen. Aber andererseits bleibt das Prinzip
dasselbe.
.SS "Vorbehalte bei Hook-Zielen und Makefile-Bedingungen (conditionals)"
.IX Subsection "Vorbehalte bei Hook-Zielen und Makefile-Bedingungen (conditionals)"
Wenn Sie sich entscheiden, ein Hook-Target in Makefile-Bedingungen
einzubetten, seien Sie sich bitte bewusst, dass \fBdh\fR alle Hook-Targets im
Voraus berechnet und die Rechenergebnisse zwischenspeichert. Darüber hinaus
werden die Bedingungen später wieder ausgelöst, wenn \fBdh\fR das Hook-Target
aufruft, und es wird dabei davon ausgehen, dass sich die Ergebnisse nicht
geändert haben.
.PP
Die Auswertung und das Zwischenspeichern passieren \fIoft\fR schon, bevor \fBdh\fR
weiß, ob es Pakete für arch:any (\-a) und/oder arch:all (\-i) bauen wird, und
kann deswegen verwirrende Resultate erzielen – vor allem, wenn
\&\fBdh_listpackages\fR\|(1) Teil der Bedingung ist.
.PP
Die meisten Probleme lassen sich vermeiden, indem das Hook-Ziel von
Bedingungen befreit wird und danach der »body«\-Teil teilweise oder komplett
konditional gemacht wird. Beispielsweise:
.PP
.Vb 10
\& # EINFACH: Es ist durchdefiniert, was passieren wird. Das Hook\-Ziel
\& # wird immer berücksichtigt. Der »vielleicht ausführen«\-Teil hat eine
\& # Bedingung, aber dh_foo wird mit Sicherheit übersprungen.
\& #
\& # Hinweis: Der Bedingungsteil wird »zweimal« untersucht, bevor er
\& # beeinflusst, was passiert. Einmal, wenn dh nachsieht, welche
\& # Hook\-Ziele vorkommen und das zweite Mal, wenn das Hook\-Ziel override_dh_foo
\& # ausgeführt wird. Falls *eines* davon FALSE zurückliefert, wird »vielleicht
\& # ausführen« übersprungen.
\& override_dh_foo:
\& ifneq (...)
\& vielleicht ausführen
\& endif
\&
\& # EINFACH: Dies hier ist genaus durchdefiniert. Das Hook\-Ziel wird immer
\& # ausgeführt und dh_bar wird übersprungen. Der »vielleicht ausführen«\-Teil ist
\& # bedingt, so wie man es erwarten würde.
\& #
\& # Hinweis: Die Bedingung wird trotzdem mehrmals überprüft (jedes
\& # Mal in einem anderen Prozess). Nur die Untersuchung während des
\& # Laufs des Hook\-Ziels beeinflusst, was passiert.
\& override_dh_bar:
\& : # Scheinbefehl, der erzwingt, dass das Ziel immer ausgeführt wird
\& ifneq (...)
\& vielleicht ausführen
\& endif
\&
\&
\&
\& # KOMPLIZIERT: Dieser Fall ist ggf. nicht trivial und hat seine Haken.
\& # Benutzen Sie es auf eigene Verantwortung, wenn dh_listpackages in der Bedingung steckt.
\& #
\& # Hier wird entweder dh_baz normal ODER stattdessen »vielleicht ausführen« ausgeführt.
\& #
\& # Es wird noch komplizierter, wenn die Frage aufkommt, ob dh in
\& # debian/rules rekursiv arbeiten muss, weil Sie ein »explicit« Standardziel
\& # (z. B. ein »build\-arch:«\-Ziel, das von »%:« getrennt ist) haben.
\& ifneq (...)
\& override_dh_baz:
\& vielleicht ausführen
\& endif
.Ve
.PP
Diese Rezepte funktionieren auch bei bedingten Abhängigkeitszielen, die oft
in einer Abwandlung des folgenden Beispiels anzutreffen sind:
.PP
.Vb 5
\& COND_TASKS =
\& ifneq (...)
\& COND_TASKS += vielleicht\-ausführen
\& endif
\& ...
\&
\& vielleicht\-ausführen:
\& ...
\&
\& # EINFACH: Es ist durchdefiniert, was passiert. Die
\& # $(COND_TASKS) werden entweder übersprungen oder nicht.
\& #
\& # Hinweis: Die Bedingung wird »zweimal« überprüft und beeinflusst immer,
\& # was passiert. Einmal, wenn dh nachsieht, welche Hook\-Ziele
\& # vorhanden sind, und einmal, wenn das Hook\-Ziel override_dh_foo
\& # ausgeführt wird. Wenn bei *einem* der beiden Male ein FALSE # zurückgeliefert wird, wird $(COND_TASKS) übersprungen
\& override_dh_foo: $(COND_TASKS)
\&
\&
\&
\& # EINFACH: Dieses hier ist genauso durchdefiniert. Das Hook\-Ziel
\& # wird ausgeführt und dh_bar wird übersprungen. Der $(COND_TASKS)\-Teil
\& # ist so bedingt wie man erwarten würde.
\& #
\& # Hinweis: Die Bedingung wird trotzdem mehrmals überprüft (jedes # Mal in einem anderen Prozess. Nur die Überprüfung während des Laufs des
\& # Hook\-Ziels beeinflusst, was passiert.
\& override_dh_bar: $(COND_TASKS)
\& : # Scheinbefehl, der das Ziel zwingt, immer ausgeführt zu werden
\&
\& # KOMPLIZIERT: Dieser Fall kann kompliziert sein und seine Haken haben.
\& # Verwenden Sie es auf Ihre eigene Verantwortung, wenn dh_listpackages in der Bedingung vorkommt.
\& #
\& ifneq (...)
\& override_dh_baz: $(COND_TASKS)
\& endif
.Ve
.PP
Im Zweifelsfall suchen Sie sich eins der \fB\s-1EINFACHEN\s0\fR Fallbeispiele aus,
welches zu Ihrem Bedarf passt.
.SH "OPTIONEN"
.IX Header "OPTIONEN"
.IP "\fB\-\-with\fR \fIErweiterung\fR[\fB,\fR\fIAdd-on\fR …]" 4
.IX Item "--with Erweiterung[,Add-on …]"
fügt die Debhelper-Befehle, die durch die genannte Erweiterung angegeben
wurden an geeigneten Stellen der ausgeführten Befehlssequenz hinzu. Diese
Option kann mehr als einmal wiederholt werden oder es können mehrere Add-ons
durch Kommas getrennt aufgeführt werden. Dies wird benutzt, wenn es ein
Fremdpaket gibt, das Debhelper-Befehle bereitstellt. Dokumentation über die
Sequenz-Erweiterungsschnittstelle finden Sie in der Datei \fI\s-1PROGRAMMING\s0\fR.
.Sp
Eine \fBBuild-Depends\fR\-Beziehung zum Paket \fBdh\-sequence\-\fR\fIErweiterung\fR
setzt eine \fB\-\-with\fR\-\fIErweiterung\fR voraus. Das vermeidet, dass ein
explizites \fB\-\-with\fR in \fIdebian/rules\fR benötigt wird, das nur dupliziert,
was bereits über die Bauabhängigkeiten in \fIdebian/control\fR erklärt
wurde. Die Beziehung kann (seit 12.5) optional gemacht werden, z. B. über
Bauprofile. Dies versetzt Sie in die Lage, einfach eine Erweiterung zu
deaktivieren, die nur zu einem bestimmten Profil passt (z. B. um
Bootstrapping zu erleichtern).
.Sp
Ab Debhelper 12.5 können Erweiterungen auch im reinen \fBindep\fR\-Modus (über
\&\fBBuild-Depends-Indep\fR) oder reinen \fBarch\fR\-Modus (über
\&\fBBuild-Depends-Arch\fR) aktiviert werden. Derartige Erweiterungen sind nur in
der bestimmten Sequenz aktiv (z. B. \fBbinary-indep\fR), die
Abhängigkeitsverwaltung für Cross-Bauen vereinfachen.
.Sp
Bitte beachten Sie, dass Erweiterungen, die über \fBBuild-Depends-Indep\fR oder
\&\fBBuild-Depends-Arch\fR aktiviert wurden, zusätzlichen Beschränkungen
unterliegen, die sicherzustellen, dass das Ergebnis sogar dann
deterministisch ist, wenn die Erweiterung nicht verfügbar ist (z. B. während
des Aufräumens). Dies impliziert, dass einige Erweiterungen mit diesen
Beschränkungen inkompatibel sind und nur über \fBBuild-Depends\fR (oder manuell
ber \fIdebian/rules\fR) benutzt werden können. Derzeit können derartige
Erweiterungen nur Befehle zu Sequenzen hinzufügen.
.IP "\fB\-\-without\fR \fIErweiterung\fR" 4
.IX Item "--without Erweiterung"
das Gegenteil von \fB\-\-with\fR, deaktiviert die Benutzung der angegebenen
Erweiterung. Diese Option kann mehrfach wiederholt werden oder es können
mehrere Erweiterungen zum Deaktivieren durch Kommas getrennt aufgelistet
werden.
.IP "\fB\-\-list\fR, \fB\-l\fR" 4
.IX Item "--list, -l"
listet alle verfügbaren Erweiterungen auf.
.Sp
Wenn es nur mit dieser Option aufgerufen wird, kann \fBdh\fR aus jedem
Verzeichnis aufgerufen werden (d.h. es benötigt keinen Zugriff auf Dateien
aus einem Quellpaket).
.IP "\fB\-\-no\-act\fR" 4
.IX Item "--no-act"
gibt Befehle aus, die für eine angegebene Sequenz ausgeführt würden, führt
sie aber nicht aus
.Sp
Beachten Sie, dass dh normalerweise die Ausführung von Befehlen, von denen
es weiß, dass sie nichts tun, überspringt. Mit »\-\-no\-act« wird die
vollständige Liste der Befehle der Reihe nach ausgegeben.
.PP
Andere an \fBdh\fR übergebene Optionen werden an jeden Befehl, den es ausführt,
weitergereicht. Damit kann eine Option wie \fB\-v\fR, \fB\-X\fR oder \fB\-N\fR sowie
spezialisiertere Optionen gesetzt werden.
.SH "BEISPIELE"
.IX Header "BEISPIELE"
Um zu sehen, welche Befehle in einer Sequenz enthalten sind, ohne
tatsächlich etwas zu tun, geben Sie Folgendes ein:
.PP
.Vb 1
\& dh binary\-arch \-\-no\-act
.Ve
.PP
Dies ist eine sehr einfache »rules«\-Datei für Pakete, bei denen die
vorgegebenen Befehlssequenzen ohne zusätzliche Optionen arbeiten.
.PP
.Vb 3
\& #!/usr/bin/make \-f
\& %:
\& dh $@
.Ve
.PP
Oft möchten Sie eine Option an einen speziellen Debhelper-Befehl
übergeben. Der einfachste Weg, dies zu tun, besteht darin, ein Override-Ziel
für diesen Befehl hinzuzufügen.
.PP
.Vb 3
\& #!/usr/bin/make \-f
\& %:
\& dh $@
\&
\& override_dh_strip:
\& dh_strip \-Xfoo
\&
\& override_dh_auto_configure:
\& dh_auto_configure \-\- \-\-with\-foo \-\-disable\-bar
.Ve
.PP
Manchmal ist ein Paket den \fBdh_auto_configure\fR\|(1) und \fBdh_auto_build\fR\|(1)
so fremd, dass sie nicht automaitsch einschätzen können, was daran zu machen
ist. Um ihre Ausführung zu verhindern und stattdessen Ihre eigenen Befehle
einzusetzen, schreiben Sie Folgendes:
.PP
.Vb 3
\& #!/usr/bin/make \-f
\& %:
\& dh $@
\&
\& override_dh_auto_configure:
\& ./mondoconfig
\&
\& override_dh_auto_build:
\& mach\-dass\-sich\-das\-Universum\-in\-Wohlgefallen\-auflöst
.Ve
.PP
Ein weiterer häufiger Fall ist, dass Sie vor oder nach der Ausführung eines
besonderen Debhelper-Befehls manuell etwas tun möchten.
.PP
.Vb 3
\& #!/usr/bin/make \-f
\& %:
\& dh $@
\&
\& # Beispiel geht von Debhelper/12.8 und Kompatibilitätsstufe 10+ aus
\& execute_after_dh_fixperms:
\& chmod 4755 debian/foo/usr/bin/foo
.Ve
.PP
Falls Sie auf einer älteren Debhelper\-Kompatibilitätsstufe sind, würde das
Beispiel wie folgt aussehen:
.PP
.Vb 3
\& #!/usr/bin/make \-f
\& %:
\& dh $@
\&
\& # ältere Debhelper\-Versionen oder Verwendung von Kompatibilitätsstufe 9
\& #und niedriger
\& override_dh_fixperms:
\& dh_fixperms
\& chmod 4755 debian/foo/usr/bin/foo
.Ve
.PP
Python-Werkzeuge werden aufgrund ständiger Änderungen in diesem Bereich
nicht standardmäßig von dh ausgeführt. Sie können \fBdh_python2\fR
folgendermaßen benutzen.
.PP
.Vb 3
\& #!/usr/bin/make \-f
\& %:
\& dh $@ \-\-with python2
.Ve
.PP
So wird die Benutzung von Perls Bausystem \fBModule::Build\fR erzwungen wird,
was nötig sein kann, falls Debhelper fälschlicherweise feststellt, dass das
Programm MakeMaker verwendet.
.PP
.Vb 3
\& #!/usr/bin/make \-f
\& %:
\& dh $@ \-\-buildsystem=perl_build
.Ve
.PP
Hier ein Beispiel für das außer Kraft setzen, wobei die
\&\fBdh_auto_\fR\fI*\fR\-Befehle den Paketquelltext für ein Paket finden, bei dem der
Quelltext in einem Unterverzeichnis liegt.
.PP
.Vb 3
\& #!/usr/bin/make \-f
\& %:
\& dh $@ \-\-sourcedirectory=src
.Ve
.PP
Und hier ist ein Beispiel, wie \fBdh_auto_\fR\fI*\fR\-Befehlen mitgeteilt wird,
dass in einem Unterverzeichnis gebaut wird, das beim \fBAufräumen\fR entfernt
wird.
.PP
.Vb 3
\& #!/usr/bin/make \-f
\& %:
\& dh $@ \-\-builddirectory=build
.Ve
.PP
Falls Ihr Paket parallel gebaut werden kann, benutzen Sie bitte entweder
Kompatibilitätsmodus 10 oder übergeben Sie \fB\-\-parallel\fR an Dh. Dann wird
\&\fBdpkg-buildpackage \-j\fR funktionieren.
.PP
.Vb 3
\& #!/usr/bin/make \-f
\& %:
\& dh $@ \-\-parallel
.Ve
.PP
Falls Ihr Paket nicht verlässlich unter Verwendung mehrerer Threads gebaut
werden kann, übergeben Sie bitte \fB\-\-no\-parallel\fR an Dh (oder den
zuständigen \fBdh_auto_\fR\fI*\fR\-Befehl):
.PP
.Vb 3
\& #!/usr/bin/make \-f
\& %:
\& dh $@ \-\-no\-parallel
.Ve
.PP
Es folgt eine Möglichkeit, die Ausführung mehrerer Befehle, die Sie nicht
ausführen möchten, durch \fBdh\fR zu verhindern, indem Sie leere Override-Ziele
für jeden Befehl definieren.
.PP
.Vb 3
\& #!/usr/bin/make \-f
\& %:
\& dh $@
\&
\& # nicht auszuführende Befehle:
\& override_dh_auto_test override_dh_compress override_dh_fixperms:
.Ve
.PP
Ein langer Bauprozess für ein separates Dokumentationspaket kann durch
Benutzung von architekturabhängigen Außerkraftsetzungen (Overrides)
abgetrennt werden. Diese Ziele werden übersprungen, wenn »build\-arch«\- und
»binary\-arch«\-Sequenzen ausgeführt werden.
.PP
.Vb 3
\& #!/usr/bin/make \-f
\& %:
\& dh $@
\&
\& override_dh_auto_build\-indep:
\& $(MAKE) \-C docs
\&
\& # Keine Tests für Dokumente nötig
\& override_dh_auto_test\-indep:
\&
\& override_dh_auto_install\-indep:
\& $(MAKE) \-C docs install
.Ve
.PP
Angenommen, Sie möchten zusätzlich zum vorhergehenden Beispiel die
Dateimodusbits einer Datei ändern, aber nur, wenn Sie ein
architekturabhängiges Paket bauen, da sie beim Bauen der Dokumentation nicht
vorhanden ist.
.PP
.Vb 3
\& # Beispiel geht von Debhelper/12.8 und Kompatibilitätsstufe 10+ aus
\& execute_after_dh_fixperms\-arch:
\& chmod 4755 debian/foo/usr/bin/foo
.Ve
.SH "INTERNA"
.IX Header "INTERNA"
Falls Sie neugierig auf die Interna von \fBdh\fR sind, ist hier beschrieben,
wie es unter der Haube arbeitet.
.PP
Im Kompatibilitätsmodus 10 (oder höher) erzeugt \fBdh\fR eine Stempeldatei
\&\fIdebian/debhelper\-build\-stamp\fR, nachdem die Bauschritte abgeschlossen sind,
um ein erneutes Ausführen zu vermeiden. Es ist möglich, die Stempeldatei zu
verhindern, indem \fB\-\-without=build\-stamp\fR an \fBdh\fR übergeben wird. Dies
sorgt dafür, dass »unsauber« gebaute Pakete sich eher so verhalten, wie es
manche Leute erwarten. Allerdings wird der Bau und das Testen möglicherweise
zweimal ausgeführt (das zweite Mal als root oder unter \fBfakeroot\fR\|(1)).
.PP
Innerhalb eines Override-Ziels werden \fBdh_*\fR\-Befehle eine
\&\fIdebian/package.debhelper.log\fR\-Protokolldatei erzeugen, um den Überblick zu
behalten, für welche Pakete die Befehle ausgeführt wurden. Diese
Protokolldateien werden entfernt, sobald die Override-Ziele erledigt sind.
.PP
Im Kompatibilitätsmodus 9 oder älter wird jeder Debhelper-Befehl in
\&\fIdebian/package.debhelper.log\fR aufgezeichnet, wenn er erfolgreich
ausgeführt wurde. (Was durch \fBdh_clean\fR gelöscht wird.) Daher kann \fBdh\fR
sagen, welche Befehle bereits für welche Pakete ausgeführt wurden und die
erneute Ausführung dieser Befehle überspringen.
.PP
Jedes Mal, wenn \fBdh\fR (im Kompatibilitätsmodus 9 oder älter) ausgeführt
wird, geht es das Protokoll durch, um festzustellen, welcher Befehl in der
angegebenen Sequenz zuletzt ausgeführt wurde. Es fährt dann mit dem nächsten
Befehl fort.
.PP
Eine Sequenz kann außerdem abhänge Ziele in debian/rules ausführen. Die
Sequenz »binary« führt zum Beispiel das Ziel »install« aus.
.PP
\&\fBdh\fR benutzt die Umgebungsvariable \fB\s-1DH_INTERNAL_OPTIONS\s0\fR, um Informationen
an die Debhelper-Befehle durchzureichen, die innerhalb der Ziele ausgeführt
werden. Der Inhalt (und die tatsächliche Existenz) dieser Umgebungsvariable
ist, wie der Name schon andeutet, Gegenstand dauernder Änderungen.
.PP
Befehle in den Sequenzen \fBbuild-indep\fR, \fBinstall-indep\fR und
\&\fBbinary-indep\fR werden an die Option \fB\-i\fR übergeben, um sicherzustellen,
dass sie nur auf architekturunabhängigen Paketen funktionieren. Befehle in
den Sequenzen \fBbuild-arch\fR, \fBinstall-arch\fR und \fBbinary-arch\fR werden an
die Option \fB\-a\fR übergeben, um sicherzustellen, dass sie nur auf
architekturabhängigen Paketen funktionieren.
.SH "SIEHE AUCH"
.IX Header "SIEHE AUCH"
\&\fBdebhelper\fR\|(7)
.PP
Dieses Programm ist Teil von Debhelper.
.SH "ÜBERSETZUNG"
.IX Header "ÜBERSETZUNG"
Diese Übersetzung wurde mit dem Werkzeug
\&\fBpo4a\fR
durch Chris Leick
\&\fIc.leick@vollbio.de\fR
und das deutsche Debian\-Übersetzer\-Team im
Dezember 2011 erstellt.
.PP
Bitte melden Sie alle Fehler in der Übersetzung an
\&\fIdebian\-l10n\-german@lists.debian.org\fR
oder als Fehlerbericht an das Paket
\&\fIdebhelper\fR.
.PP
Sie können mit dem folgenden Befehl das englische
Original anzeigen
man \-L en Abschnitt Handbuchseite
.SH "AUTOR"
.IX Header "AUTOR"
Joey Hess