path: root/man/de/dpkg-maintscript-helper.pod

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