1 files changed, 342 insertions, 0 deletions
diff --git a/man/de/dpkg-maintscript-helper.pod b/man/de/dpkg-maintscript-helper.pod
new file mode 100644
index 0000000..db4ebbd
--- /dev/null
+++ b/man/de/dpkg-maintscript-helper.pod
@@ -0,0 +1,342 @@
+
+        *****************************************************
+        *           GENERATED FILE, DO NOT EDIT             *
+        * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION *
+        *****************************************************
+
+This file was generated by po4a(7). Do not store it (in VCS, for example),
+but store the PO file used as source file by po4a-translate.
+
+In fact, consider this as a binary, and the PO file as a regular .c file:
+If the PO get lost, keeping this translation up-to-date will be harder.
+
+=encoding UTF-8
+
+=head1 BEZEICHNUNG
+
+dpkg-maintscript-helper - Bekannte Einschränkungen in Dpkg in
+Betreuerskripten umgehen
+
+=head1 ÜBERSICHT
+
+B<dpkg-maintscript-helper> I<Befehl> [I<Parameter> …] B<-->
+I<Betr-Skript-Parameter> …
+
+=head1 BEFEHLE UND PARAMETER
+
+=over 
+
+=item B<supports> I<Befehl>
+
+=item B<rm_conffile> I<Conffile> [I<vorhergehende_Version> [I<Paket>]]
+
+=item B<mv_conffile> I<alte_Conffile> I<neue_Conffile> [I<vorhergehende_Version>
+[I<Paket>]]
+
+=item B<symlink_to_dir> I<Pfadname> I<altes_Ziel> [I<vorhergehende_Version>
+[I<Paket>]]
+
+=item B<dir_to_symlink> I<Pfadname> I<neues_Ziel> [I<vorhergehende_Version>
+[I<Paket>]]
+
+=back
+
+=head1 BESCHREIBUNG
+
+Dieses Programm wurde so entworfen, dass es in Betreuerskripten ausgeführt
+werden kann, um einige Aufgaben zu erledigen, die B<dpkg> (noch) nicht
+selbst erledigen kann, entweder aufgrund von Design-Entscheidungen oder
+aufgrund aktueller Einschränkungen.
+
+Viele dieser Aufgaben benötigen koordinierte Aktionen aus mehreren
+Betreuerskripten (B<preinst>, B<postinst>, B<prerm>, B<postrm>). Um Fehler
+zu vermeiden, wird der gleiche Aufruf einfach in alle Skripte eingefügt und
+das Programm wird sein Verhalten automatisch abhängig von der Variable
+B<DPKG_MAINTSCRIPT_NAME> und den Argumenten im Betreuerskript, die Sie nach
+einem doppelten Bindestrich übergeben müssen, anpassen.
+
+=head1 GEMEINSAME PARAMETER
+
+=over 
+
+=item I<vorhergehende_Version>
+
+Definiert die letzte Version des Pakets, dessen Upgrade die Aktion auslösen
+soll. Es ist wichtig, I<vorhergehende_Version> korrekt zu berechnen, so dass
+die Aktionen korrekt ausgeführt werden, selbst falls der Benutzer das Paket
+mit einer lokalen Version neu gebaut hat. Falls I<vorhergehende_Version>
+leer ist oder weggelassen wurde, wird die Aktion bei jedem Upgrade versucht
+(Hinweis: Es ist sicherer, die Version anzugeben und damit die Aktion nur
+einmal versuchen zu lassen).
+
+Falls die Conffile in mehreren Versionen nicht ausgeliefert wurde und Sie
+jetzt die Betreuerskripte anpassen, um die überflüssige Datei zu entfernen,
+sollte I<vorhergehende_Version> auf die Version des Pakets gesetzt werden,
+die Sie jetzt zusammenstellen, nicht auf die erste Version des Pakets, bei
+dem die Conffile fehlte. Dies trifft genauso auch auf alle anderen Aktionen
+zu.
+
+Wird beispielsweise eine Conffile in Version B<2.0-1> eines Pakets entfernt,
+sollte I<vorhergehende_Version> auf B<2.0-1~> gesetzt werden. Dies führt
+dazu, dass die Conffile entfernt wird, selbst falls der Benutzer die
+vorhergehende Version B<1.0-1> als B<1.0-1local1> neu gebaut hat. Oder ein
+Paket, das einen Pfad von einem Symlink (das in Version B<1.0-1>
+ausgeliefert wurde) zu einem Verzeichnis (ausgeliefert in Version B<2.0-1>)
+wechselt, aber die eigentliche Umstellung in den Betreuerskripten in Version
+B<3.0-1> durchführt, sollte I<vorhergehende_Version> auf B<3.0-1~> setzen.
+
+=item I<Paket>
+
+Der Paketname, dem der Pfadname gehört bzw. die Pfadnamen gehören. Wenn das
+Paket „Multi-Arch: same“ ist, muss dieser Parameter die
+Architekturspezifikation enthalten, andernfalls sollte er normalerweise die
+Architekturspezifikation B<nicht> enthalten (da dies Cross-Grades verhindern
+oder die Umstellung von architekturspezifisch auf die Architektur B<all>
+oder umgekehrt verhindern würde). Falls dieser Parameter leer oder nicht
+angegeben ist, werden die (von B<dpkg> bei der Ausführung der
+Betreuerskripte gesetzten) Umgebungsvariablen B<DPKG_MAINTSCRIPT_PACKAGE>
+und B<DPKG_MAINTSCRIPT_ARCH> verwandt, um den Architektur-spezifizierten
+Paketnamen zu erstellen.
+
+=item B<-->
+
+Alle Parameter der Betreuerskripte müssen nach B<--> an das Programm
+weitergeleitet werden.
+
+=back
+
+=head1 CONFFILE-BEZOGENE AUFGABEN
+
+Beim Upgrade eines Pakets wird B<dpkg> eine Conffile (eine
+Konfigurationsdatei, bei der B<dpkg> die Änderungen des Benutzers erhalten
+soll) nicht automatisch entfernen, falls sie nicht in der neueren Version
+enthalten ist. Es gibt zwei Hauptgründe dafür; der erste ist, dass die
+Conffile versehentlich entfallen sein und die nächste Version sie wieder
+herstellen könnte und die Benutzer die Änderung nicht weggeworfen sehen
+wollen. Der zweite besteht darin, dass Paketen erlaubt werden soll, von
+einer Dpkg-betreuten Conffile auf eine Datei, die von den Betreuerskripten
+des Pakets, normalerweise mit einem Werkzeug wie Debconf oder Ucf, verwaltet
+wird, umzustellen.
+
+Das bedeutet, falls ein Paket eine Conffile umbenennen oder entfernen soll,
+muss es dies explizit durchführen und B<dpkg-maintscript-helper> kann dazu
+verwandt werden, eine sanfte Löschung und Verschiebung von Conffiles
+innerhalb von Betreuerskripten durchzuführen.
+
+=head2 Eine Conffile entfernen
+
+Hinweis: In den meisten Fällen kann dies durch den Schalter
+C<remove-on-upgrade> in F<DEBIAN/conffiles> (seit Dpkg 1.20.6) ersetzt
+werden, siehe L<deb-conffiles(5)>.
+
+Falls eine Conffile komplett entfernt wird, sollte sie von der Platte
+entfernt werden, falls der Benutzer sie nicht verändert hat. Falls es lokale
+Anpassungen gibt, sollten diese erhalten werden. Falls das Upgrade des
+Pakets abgebrochen wird, sollte die neuerdings veraltete Conffile nicht
+verschwinden.
+
+All dies wird durch Einsetzen der folgenden Shell-Schnipsel in die
+Betreuerskripte B<preinst>, B<postinst> und B<postrm> implementiert:
+
+=over 
+
+Z<>
+ dpkg-maintscript-helper rm_conffile \
+    I<Conffile> I<vorhergehende_Version> I<Paket> -- "$@"
+
+=back
+
+I<Conffile> ist der Dateiname der zu entfernenden Conffile.
+
+Aktuelle Implementierung: im B<preinst> wird geprüft, ob die Conffile
+geändert wurde. Dann wird sie entweder in I<Conffile>B<.dpkg-remove> (falls
+sie nicht geändert wurde) oder in I<Conffile>B<.dpkg-backup> (falls sie
+geändert wurde) umbenannt. Im B<postinst> wird Letztere in
+I<Conffile>B<.dpkg-bak> umbenannt und als Referenz behalten, da sie
+Benutzeränderungen enthält, während Erstere entfernt wird. Falls das Upgrade
+des Pakets abgebrochen wird, reinstalliert B<postrm> die ursprüngliche
+Conffile. Während des vollständigen Löschens wird B<postrm> auch die bisher
+behaltene Datei B<.dpkg-bak> entfernen.
+
+=head2 Eine Conffile umbenennen
+
+Falls eine Conffile von einem Ort zu einem anderen verschoben wird, müssen
+Sie sicherstellen, dass Sie auch alle Änderungen des Benutzers mit
+übernehmen. Anfänglich erscheint dies als einfache Änderung am Skript
+B<preinst>, allerdings wird dies dazu führen, dass der Benutzer von B<dpkg>
+aufgefordert wird, die Bearbeitung der Conffile zu bestätigen, obwohl sie
+für diese gar nicht verantwortlich sind.
+
+Sanfte Umbenennung kann durch Einsetzen der folgenden Shell-Schnipsel in die
+Betreuerskripte B<preinst>, B<postinst> und B<postrm> implementiert werden:
+
+=over 
+
+Z<>
+ dpkg-maintscript-helper mv_conffile \
+    I<alte_Conffile> I<neue_Conffile> I<vorhergehende_Version> I<Paket> -- "$@"
+
+=back
+
+I<alte_Conffile> und I<neue_Conffile> sind der alte und der neue Name der
+umzubenennenden Conffile.
+
+Aktuelle Implementierung: das B<preinst> überprüft, ob die Conffile
+verändert wurde, falls ja, verbleibt sie am Platz, andernfalls wird sie in
+I<alte_Conffile>B<.dpkg-remove> umbenannt. Bei der Konfiguration entfernt
+das B<postinst> I<alte_Conffile>B<.dpkg-remove> und benennt I<alte_Conffile>
+in I<neue_Conffile> um, falls I<alte_Conffile> noch existiert. Falls
+abort-upgrade/abort-install eintritt, benennt das B<postrm> wieder
+I<alte_Conffile>B<.dpkg-remove> in I<alte_Conffile> zurück, falls notwendig.
+
+=head1 SYMLINK- UND VERZEICHNISUMWANDLUNGEN
+
+Beim Upgrade eines Pakets wird B<dpkg> einen Symlink nicht automatisch in
+ein Verzeichnis und umgekehrt umwandeln. Installationen älterer Versionen
+(„downgrades“) werden nicht unterstützt und der Pfad verbleibt wie er ist.
+
+=head2 Einen Symlink in ein Verzeichnis umwandeln
+
+Falls ein Symlink in ein echtes Verzeichnis umgewandelt wird, müssen Sie vor
+dem Entpacken sicherstellen, dass der Symlink entfernt wird. Anfänglich
+erscheint dies als einfache Änderung am Skript B<preinst>, allerdings wird
+dies zu einigen Problemen führen, falls der Administrator lokale Anpassungen
+des Symlinks durchgeführt hat oder falls ein Downgrade des Pakets auf eine
+alte Version durchgeführt wird.
+
+Sanfte Umbenennung kann durch Einsetzen der folgenden Shell-Schnipsel in die
+Betreuerskripte B<preinst>, B<postinst> und B<postrm> implementiert werden:
+
+=over 
+
+Z<>
+ dpkg-maintscript-helper symlink_to_dir \
+    I<Pfadname> I<altes_Ziel> I<vorhergehende_Version> I<Paket> -- "$@"
+
+=back
+
+I<Pfadname> ist der absolute Name des alten Symlinks (der Pfad wird am Ende
+der Installation ein Verzeichnis sein) und I<altes_Ziel> ist der Name des
+Ziels des vorherigen Symlinks unter I<Pfadname>. Es kann entweder absolut
+oder relativ zum Verzeichnis, das I<Pfadname> enthält, sein.
+
+Aktuelle Implementierung: das B<preinst> überprüft, ob der Symlink existiert
+und auf I<altes_Ziel> zeigt. Falls dies nicht der Fall ist, bleibt der
+Symlink existent, andernfalls wird er in I<Pfadname>B<.dpkg-backup>
+umbenannt. Bei der Konfiguration entfernt das B<postinst>
+I<Pfadname>B<.dpkg-backup>, falls I<Pfadname>B<.dpkg-backup> noch ein
+Symlink ist. Falls abort-upgrade/abort-install eintritt, benennt das
+B<postrm> wieder I<Pfadname>B<.dpkg-backup> in I<Pfadname> zurück, falls
+notwendig.
+
+=head2 Ein Verzeichnis in einen Symlink umwandeln
+
+Falls ein echtes Verzeichnis in einen Symlink umgewandelt wird, müssen Sie
+vor dem Entpacken sicherstellen, dass das Verzeichnis entfernt
+wird. Anfänglich erscheint dies als einfache Änderung am Skript B<preinst>,
+allerdings wird dies zu einigen Problemen führen, falls das Verzeichnis
+Conffiles, Pfadnamen anderer Pakete oder lokal erstellte Pfadnamen enthält
+oder wenn ein Downgrade des Pakets durchgeführt wird.
+
+Sanfte Umwandlung kann durch Einsetzen der folgenden Shell-Schnipsel in die
+Betreuerskripte B<preinst>, B<postinst> und B<postrm> implementiert werden:
+
+=over 
+
+Z<>
+ dpkg-maintscript-helper dir_to_symlink \
+    I<Pfadname> I<neues_Ziel> I<vorhergehende_Version> I<Paket> -- "$@"
+
+=back
+
+I<Pfadname> ist der absolute Name des alten Verzeichnisses (der Pfad wird am
+Ende der Installation ein Symlink sein) und I<neues_Ziel> ist das Ziel des
+neuen Symlinks unter I<Pfadname>. Es kann entweder absolut oder relativ zum
+Verzeichnis, das I<Pfadname> enthält, sein.
+
+Aktuelle Implementierung: das B<preinst> überprüft, ob das Verzeichnis
+existiert, keine Conffiles, Pfadnamen anderer Pakete oder lokal erstellte
+Pfadnamen enthält. Falls nicht, bleibt es an Ort und Stelle, andernfalls
+wird es in I<Pfadname>B<.dpkg-backup> umbenannt und ein leeres
+Vorbereitungsverzeichnis mit Namen I<Pfadname> erstellt und durch eine Datei
+markiert, so dass Dpkg es nachverfolgen kann. Bei der Konfiguration beendet
+B<postinst> die Umstellung, falls I<Pfadname>.B<.dpkg-backup> noch ein
+Verzeichnis und I<Pfadname> noch das Vorbereitungsverzeichnis ist. Es
+entfernt die Markierungsdatei im Vorbereitungsverzeichnis, verschiebt die
+neu erstellten Dateien im Vorbereitungsverzeichnis in das Symlink-Ziel
+I<neues_Ziel>/, ersetzt das jetzt leere Vorbereitungsverzeichnis I<Pfadname>
+durch einen Symlink auf I<neues_Ziel> und entfernt
+I<Pfadname>.B<.dpkg-backup>. Falls abort-upgrade/abort-install eintritt,
+benennt das B<postrm> wieder I<Pfadname>B<.dpkg-backup> in I<Pfadname>
+zurück, falls notwendig.
+
+=head1 INTEGRATION IN PAKETE
+
+Bei der Benutzung der Paketierungshelfer prüfen Sie bitte, ob eine native
+B<dpkg-maintscript-helper>-Integration existiert. Hierdurch könnte Ihr
+Aufwand verringert werden. Lesen Sie beispielsweise B<dh_installdeb>(1).
+
+Da B<dpkg-maintscript-helper> im B<preinst> verwandt wird, benötigt der
+bedingungslose Einsatz eine prä-Abhängigkeit (I<pre-dependency>), um
+sicherzustellen, dass die Mindestversion von B<dpkg> bereits entpackt
+wurde. Die benötigte Version hängt vom verwandten Befehl ab, für
+B<rm_conffile> und B<mv_conffile> lautet sie 1.15.7.2, für B<symlink_to_dir>
+und B<dir_to_symlink> lautet sie 1.17.14:
+
+=over 
+
+ Pre-Depends: dpkg (>= 1.17.14)
+
+=back
+
+In vielen Fällen sind aber die Ausführungen des Programms für das Paket
+nicht kritisch und statt einer prä-Abhängigkeit soll das Programm nur
+aufgerufen werden, falls bekannt ist, dass der benötigte Befehl vom derzeit
+installierten B<dpkg> unterstützt wird:
+
+=over 
+
+Z<>
+ if dpkg-maintscript-helper supports I<Befehl>; then
+    dpkg-maintscript-helper I<Befehl> …
+ fi
+
+=back
+
+Der Befehl B<supports> liefert im Erfolgsfall 0, ansonsten 1 zurück. Der
+Befehl B<supports> überprüft, ob die durch Dpkg gesetzten und vom Skript
+benötigten Umgebungsvariablen vorhanden sind und betrachtet es als
+Fehlschlag, falls die Umgebung nicht ausreichend ist.
+
+=head1 UMGEBUNG
+
+=over 
+
+=item B<DPKG_ROOT>
+
+Falls gesetzt wird dies als Dateisystemwurzelverzeichnis verwandt.
+
+=item B<DPKG_ADMINDIR>
+
+Falls gesetzt wird dies als Datenverzeichnis von B<dpkg> verwandt.
+
+=item B<DPKG_COLORS>
+
+Setzt den Farbmodus (seit Dpkg 1.19.1). Die derzeit unterstützten Werte
+sind: B<auto> (Vorgabe), B<always> und B<never>.
+
+=back
+
+=head1 SIEHE AUCH
+
+B<dh_installdeb>(1).
+
+
+=head1 ÜBERSETZUNG
+
+Die deutsche Übersetzung wurde 2004, 2006-2020 von Helge Kreutzmann
+<debian@helgefjell.de>, 2007 von Florian Rehnisch <eixman@gmx.de> und
+2008 von Sven Joachim <svenjoac@gmx.de>
+angefertigt. Diese Übersetzung ist Freie Dokumentation; lesen Sie die
+GNU General Public License Version 2 oder neuer für die Kopierbedingungen.
+Es gibt KEINE HAFTUNG.