diff options
author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-27 09:40:31 +0000 |
---|---|---|
committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-27 09:40:31 +0000 |
commit | b86570f63e533abcbcb97c2572e0e5732a96307b (patch) | |
tree | cabc83be691530ae685c45a8bc7620ccc0e1ebdf /man/de/deb-control.pod | |
parent | Initial commit. (diff) | |
download | dpkg-upstream.tar.xz dpkg-upstream.zip |
Adding upstream version 1.20.13.upstream/1.20.13upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to '')
-rw-r--r-- | man/de/deb-control.pod | 412 |
1 files changed, 412 insertions, 0 deletions
diff --git a/man/de/deb-control.pod b/man/de/deb-control.pod new file mode 100644 index 0000000..b1b9213 --- /dev/null +++ b/man/de/deb-control.pod @@ -0,0 +1,412 @@ + + ***************************************************** + * 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 + +deb-control - Dateiformat der Hauptsteuerdatei von binären Debian-Paketen + +=head1 ÜBERSICHT + +B<DEBIAN/control> + +=head1 BESCHREIBUNG + +Jedes Debian-Binärpaket enthält eine Datei B<control> in seinem +B<control>-Element. Ihr L<deb822(5)>-Format ist eine Teilmenge der +Hauptdatei B<debian/control> in dem Debian-Quellpaket, siehe +B<deb-src-control>(5). + +Diese Datei enthält eine Reihe von Feldern. Jedes Feld beginnt mit einer +Markierung, wie B<Package> oder B<Version> (Groß-/Kleinschreibung egal), +gefolgt von einem Doppelpunkt und dem Inhalt des Feldes +(Groß-/Kleinschreibung ist relevant, außer anders angegeben). Felder werden +nur durch die Feldmarkierungen abgegrenzt. Mit anderen Worten, Feldtexte +können mehrere Zeilen überspannen, aber die Installationswerkzeuge werden im +Allgemeinen die Zeilen bei der Verarbeitung des Feldinhaltes zusammenfassen +(mit Ausnahme des B<Description>-Feldes, sehen Sie dazu unten). + +=head1 FELDER + +=over + +=item B<Package:> I<Paketname> (verpflichtend) + +Der Wert dieses Feldes bestimmt den Paketnamen und wird von den meisten +Installationswerkzeugen verwendet, um Dateinamen zu erstellen. + +=item B<Package-Type:> B<deb>|B<udeb>|I<type> + +Dieses Feld definiert die Art des Pakets. B<udeb> ist für größenbegrenzte +Pakete, wie sie vom Debian-Installer verwandt werden. B<deb> ist der +Standardwert, er wird angenommen, falls das Feld fehlt. Weitere Typen +könnten in der Zukunft hinzugefügt werden. + +=item B<Version:> I<Versionszeichenkette> (verpflichtend) + +Typischerweise ist das die Original-Paketversionsnummer, in der Form, die +der Programmautor verwendet. Es kann auch eine Debian-Revisionsnummer +enthalten (für nicht aus Debian stammende Pakete). Das genaue Format und der +Sortieralgorithmus sind in B<deb-version>(7) beschrieben. + +=item B<Maintainer:> I<Vollständiger-Name-und-E-Mail> (empfohlen) + +Sollte in dem Format „Joe Bloggs E<lt>jbloggs@foo.comE<gt>“ sein und ist +typischerweise die Person, die das Paket erstellt hat, im Gegensatz zum +Autor der Software, die paketiert wurde. + +=item B<Description:> I<Kurzbeschreibung> (empfohlen) + +=item B<> I<Langbeschreibung> + +Das Format der Paketbeschreibung ist eine kurze knappe Zusammenfassung auf +der ersten Zeile (nach dem Feld B<Description>). Die folgenden Zeilen +sollten als längere, detailliertere Beschreibung verwendet werden. Jede +Zeile der Langbeschreibung muss mit einem Leerzeichen beginnen und +Leerzeilen in der Langbeschreibung müssen einen einzelnen ‚B<.>’ hinter dem +einleitenden Leerzeichen enthalten. + +=item B<Section:> I<Sektion> + +Dies ist ein allgemeines Feld, das das Paket in eine Kategorie einordnet, +basierend auf der Software, die es installiert. Einige übliche Sektionen +sind B<utils>, B<net>, B<mail>, B<text>, B<x11> usw. + +=item B<Priority:> I<Priorität> + +Setzt die Bedeutung dieses Pakets in Bezug zu dem Gesamtsystem. Übliche +Prioritäten sind B<required>, B<standard>, B<optional>, B<extra> usw. + +=back + +Die Felder B<Section> und B<Priority> haben eine definierte Menge an Werten, +abhängig von den jeweiligen Distributionsrichtlinien. + +=over + +=item B<Installed-Size:> I<Größe> + +Die ungefähre Gesamtgröße der vom Paket installierten Dateien, in Einheiten +von KiB. + +=item B<Protected:> B<yes>|B<no> + +Dieses Feld wird normalerweise nur benötigt, wenn die Antwort B<yes> +lautet. Es bezeichnet ein Paket, das für den ordnungsgemäßen Systemstart +benötigt wird. L<dpkg(1)> oder jedes andere Installationswerkzeug wird es +nicht erlauben, ein B<Protected>-Paket zu entfernen (zumindest nicht ohne +die Verwendung einer der „force“-Optionen). + +=item B<Essential:> B<yes>|B<no> + +Dieses Feld wird normalerweise nur benötigt, wenn die Antwort B<yes> +lautet. Es bezeichnet ein Paket, das für den ordnungsgemäßen Betrieb des +Systems benötigt wird. L<dpkg(1)> oder jedes andere Installationswerkzeug +wird es nicht erlauben, ein B<Essential>-Paket zu entfernen (zumindest nicht +ohne die Verwendung einer der „force“-Optionen). + +=item B<Build-Essential:> B<yes>|B<no> + +Dieses Feld wird normalerweise nur benötigt, wenn die Antwort B<yes> lautet +und es wird typischerweise durch die Archivsoftware eingefügt. Es vermerkt +ein Paket, das zum Bau anderer Pakete benötigt wird. + +=item B<Architecture:> I<arch>|B<all> (empfohlen) + +Die Architektur spezifiziert den Hardwaretyp, für den dieses Paket +kompiliert wurde. Geläufige Architekturen sind B<amd64>, B<armel>, B<i386>, +B<powerpc> usw. Beachten Sie, dass der Wert B<all> für Pakete gedacht ist, +die Architektur-unabhängig sind. Einige Beispiele hierfür sind Shell- und +Perl-Skripte und Dokumentation. + +=item B<Origin:> I<Name> + +Der Name der Distribution, aus der dieses Paket ursprünglich stammt. + +=item B<Bugs:> I<URL> + +Die I<URL> der Fehlerdatenbank für dieses Paket. Das derzeit verwendete +Format ist I<BTS-Art>B<://>I<BTS-Adresse> wie in +B<debbugs://bugs.debian.org>. + +=item B<Homepage:> I<URL> + +Die I<URL> des Original- (Upstream-)Projekts. + +=item B<Tag:> I<Liste-von-Markierungen> + +Liste der unterstützten Markierungen („Tags“), die die Eigenschaften des +Pakets beschreiben. Die Beschreibung und die Liste der unterstützten +Markierungen kann in dem Paket B<debtags> gefunden werden. + +=item B<Multi-Arch:> B<no>|B<same>|B<foreign>|B<allowed> + +Dieses Feld wird zum Anzeigen verwandt, wie sich das Paket auf einer +Multi-Arch-Installation verhalten soll. + +=over + +=item B<no> + +Dieser Wert ist die Vorgabe, falls das Feld nicht angegeben ist. In diesem +Fall ist das Hinzufügen des Feldes mit dem expliziten Wert B<no> im +Allgemeinen nicht notwendig. + +=item B<same> + +Das Paket ist mit sich selbst koinstallierbar, darf aber nicht dazu verwandt +werden, die Abhängigkeit irgendeines Pakets von einer anderen Architektur +auf sich zu erfüllen. + +=item B<foreign> + +Das Paket ist nicht mit sich selbst koinstallierbar, aber es sollte erlaubt +sein, die nichtarchitekturabhängige Abhängigkeit eines Pakets von einer +anderen Architektur auf sich zu erfüllen (falls eine Abhängigkeit explizit +architekturqualifiziert wurde, dann wird der Wert B<foreign> ignoriert). + +=item B<allowed> + +Dies erlaubt es inversen Abhängigkeiten, in ihrem Feld B<Depends> +anzuzeigen, dass sie Pakete von einer fremden Architektur akzeptieren, indem +sie den Paketnamen mit B<:any> qualifizieren. Hat weiter keinen Effekt. + +=back + +=item B<Source:> I<Quellname> [B<(>I<Quellversion>B<)>] + +Der Name des Quellpakets, aus dem dieses Binärpaket stammt, falls es sich +vom Namen des Pakets selbst unterscheidet. Falls die Quellversion sich von +der Binärversion unterscheidet, folgt dem I<Quellnamen> in Klammern eine +I<Quellversion>. Dies kann zum Beispiel bei einem rein-binären, nicht +Betreuer-Upload passieren, oder wenn mittels „B<dpkg-gencontrol -v>“ eine +andere Binärversion gesetzt wird. + +=item B<Subarchitecture:> I<Wert> + +=item B<Kernel-Version:> I<Wert> + +=item B<Installer-Menu-Item:> I<Wert> + +Diese Felder werden im Debian-Installer verwandt und werden normalerweise +nicht benötigt. Lesen Sie /usr/share/doc/debian-installer/devel/modules.txt +aus dem Paket B<debian-installer> für weitere Informationen über sie. + +=item B<Depends:> I<Paketliste> + +Liste von Paketen, die benötigt werden, damit dieses Paket eine +nicht-triviale Menge an Funktionen anbieten kann. Die +Paketverwaltungssoftware wird es nicht erlauben, dass ein Paket installiert +wird, falls die in seinem B<Depends>-Feld aufgeführten Pakete nicht +installiert sind (zumindest nicht ohne Verwendung der „force“-Optionen). Bei +einer Installation werden Postinst-Skripte von Paketen, die im Feld +B<Depends> aufgeführt sind, vor den Postinst-Skripten der eigentlichen +Pakete ausgeführt. Bei der gegenteiligen Aktion, der Paket-Entfernung, wird +das Prerm-Skript eines Paketes vor den Prerm-Skripten der Pakete ausgeführt, +die im Feld B<Depends> aufgeführt sind. + +=item B<Pre-Depends:> I<Paketliste> + +Liste an Paketen, die installiert B<und> konfiguriert sein müssen, bevor +dieses Paket installiert werden kann. Dies wird normalerweise in dem Fall +verwendet, wo dieses Paket ein anderes Paket zum Ausführen seines +Preinst-Skriptes benötigt. + +=item B<Recommends:> I<Paketliste> + +Liste an Paketen, die zusammen mit diesem in allen - außer in eher +ungewöhnlichen - Installationen enthalten wären. Die +Paketverwaltungssoftware wird den Benutzer warnen, falls er ein Paket ohne +die im B<Recommends>-Feld aufgeführten Pakete installiert. + +=item B<Suggests:> I<Paketliste> + +Liste an Paketen, die einen Bezug zu diesem haben und vielleicht seinen +Nutzwert vergrößern könnten, aber ohne die das zu installierende Paket +dennoch sinnvoll nutzbar ist. + +=back + +Die Syntax der Felder B<Depends>, B<Pre-Depends>, B<Recommends> und +B<Suggests> ist eine Liste von Gruppen von alternativen Paketen. Jede Gruppe +ist eine Liste von durch vertikale Striche (oder „Pipe“-Symbole) ‚B<|>’ +getrennte Pakete. Die Gruppen werden durch Kommata getrennt. Kommata müssen +als „UND“, vertikale Striche als „ODER“ gelesen werden, wobei die vertikalen +Striche stärker binden. Jedem Paketnamen folgt optional eine +Architekturspezifikation, die nach einem Doppelpunkt „:“ angehängt wird, +optional gefolgt von einer Versionsnummer-Spezifikation in Klammern. + +Eine Architekturspezifikation kann eine echte Debian-Architektur sein (seit +Dpkg 1.16.5) oder B<any> (seit Dpkg 1.16.2). Falls sie fehlt, ist die +Vorgabe die aktuelle Programmpaketarchitektur. Ein echter +Debian-Architekturname wird genau auf diese Architektur für diesen +Paketnamen passen, B<any> wird auf jede Architektur für diesen Paketnamen +passen, falls das Paket als B<Multi-Arch: allowed> markiert wurde. + +Eine Versionsnummer kann mit ‚B<E<gt>E<gt>>’ beginnen, in diesem Falle +passen alle neueren Versionen, und kann die Debian-Paketrevision (getrennt +durch einen Bindestrich) enthalten oder auch nicht. Akzeptierte +Versionsbeziehungen sind ‚B<E<gt>E<gt>>’ für größer als, ‚B<E<lt>E<lt>>’ für +kleiner als, ‚B<E<gt>=>’ für größer als oder identisch zu, ‚B<E<lt>=>’ für +kleiner als oder identisch zu und ‚B<=>’ für identisch zu. + +=over + +=item B<Breaks:> I<Paketliste> + +Listet Paketen auf, die von diesem Paket beschädigt werden, zum Beispiel in +dem sie Fehler zugänglich machen, wenn sich das andere Paket auf dieses +Paket verlässt. Die Paketverwaltungssoftware wird es beschädigten Paketen +nicht erlauben, sich zu konfigurieren; im Allgemeinen wird das Problem +behoben, indem ein Upgrade des im B<Breaks>-Feld aufgeführten Pakets +durchgeführt wird. + +=item B<Conflicts:> I<Paketliste> + +Liste an Paketen, die mit diesem in Konflikt stehen, beispielsweise indem +beide Dateien gleichen Namens enthalten. Die Paketverwaltungssoftware wird +es nicht erlauben, Pakete, die in Konflikt stehen, gleichzeitig zu +installieren. Zwei in Konflikt stehende Pakete sollten jeweils eine +B<Conflicts>-Zeile enthalten, die das andere Paket erwähnen. + +=item B<Replaces:> I<Paketliste> + +Liste an Paketen, von denen dieses Dateien ersetzt. Dies wird dazu +verwendet, um diesem Paket zu erlauben, Dateien von einem anderen Paket zu +ersetzen und wird gewöhnlich mit dem B<Conflicts>-Feld verwendet, um die +Entfernung des anderen Paketes zu erlauben, falls dieses auch die gleichen +Dateien wie das im Konflikt stehende Paket hat. + +=back + +Die Syntax von B<Breaks>, B<Conflicts> und B<Replaces> ist eine Liste von +Paketnamen, getrennt durch Kommata (und optionalen Leerraumzeichen). Im +B<Breaks>- und B<Conflicts>-Feld sollte das Komma als „ODER“ gelesen +werden. Eine optionale Architekturspezifikation kann mit der gleichen Syntax +wie oben an den Paketnamen angehängt werden; der Vorgabewert ist allerdings +B<any> statt der Architektur des Programms. Eine optionale Version kann auch +mit der gleichen Syntax wie oben für die B<Breaks>-, B<Conflicts>- und +B<Replaces>-Felder angegeben werden. + +=over + +=item B<Enhances:> I<Paketliste> + +Dies ist eine Liste von Paketen, die dieses Paket erweitert. Es ist ähnlich +B<Suggests>, aber in der umgekehrten Richtung. + +=item B<Provides:> I<Paketliste> + +Dies ist eine Liste von virtuellen Paketen, die dieses Paket +bereitstellt. Gewöhnlich wird dies verwendet, wenn mehrere Pakete alle den +gleichen Dienst bereitstellen. Beispielsweise können Sendmail und Exim als +Mailserver dienen, daher stellen sie ein gemeinsames Paket +(„mail-transport-agent“) bereit, von dem andere Pakete abhängen können. Dies +erlaubt es Sendmail oder Exim, als gültige Optionen zur Erfüllung der +Abhängigkeit zu dienen. Dies verhindert, dass Pakete, die von einem +E-Mail-Server abhängen, alle Paketnamen für alle E-Mail-Server kennen und +‚B<|>’ zur Unterteilung der Liste verwenden müssen. + +=back + +Die Syntax von B<Provides> ist eine Liste von Paketnamen, getrennt durch +Kommata (und optionalen Leerraumzeichen). Eine optionale +Architekturspezifikation kann mit der gleichen Syntax wie oben an den +Paketnamen angehängt werden. Falls diese fehlt, ist die Vorgabe die binäre +Paketarchitektur. Eine optionale genaue („identisch mit“) Version kann auch +mit der gleichen Syntax wie oben angegeben werden (seit Dpkg 1.17.11 +berücksichtigt). + +=over + +=item B<Built-Using:> I<Paketliste> + +Dieses Feld führt zusätzliche Quellpakete auf, die während des Baus des +Binärpakets verwandt wurden. Dies dient als Hinweis für die +Archivverwaltungssoftware, dass zusätzliche Quellpakete vorhanden bleiben +müssen, während dieses Binärpaket betreut wird. Dieses Feld muss eine Liste +von Quellpaketnamen enthalten, bei denen eine strenge Versionsbeziehung +‚B<=>’ angegeben ist. Beachten Sie, dass die Archivverwaltungssoftware +wahrscheinlich einen Upload ablehnen wird, bei dem eine +B<Built-Using>-Beziehung angegeben wurde, die innerhalb des Archivs nicht +erfüllt werden kann. + +=item B<Built-For-Profiles:> I<Profilliste> (veraltet) + +Dieses Feld legte eine durch Leerraumzeichen getrennte Liste von Bauprofilen +fest, unter denen dieses Programmpaket gebaut wurde (von Dpkg 1.17.2 bis +1.18.18). Die bisher in diesem Feld enthaltene Informationen können jetzt in +der Datei B<.buildinfo> gefunden werden, die es ersetzt. + +=item B<Auto-Built-Package:> I<Begründungsliste> + +Dieses Feld legt eine durch Leerraumzeichen getrennte Liste von Begründungen +fest, warum dieses Paket automatisch erstellt wurde. Binärpakete, die mit +diesem Feld markiert wurden, werden nicht in der Hauptquellsteuerdatei +I<debian/control> auftauchen. Die einzige derzeit verwandte Begründung ist +B<debug-symbols>. + +=item B<Build-Ids:> I<ELF-Baukennungsliste> + +Das Feld gibt eine durch Leerraum getrennte Liste von ELF-Baukennugen +an. Dies sind eindeutige Kennzeichner für semantisch identische ELF-Objekte, +für jedes von diesen innerhalb des Pakets. + +Das Format oder die Art, jede Baukennung zu berechnen, ist designbedingt +nicht festgelegt. + +=back + +=head1 BEISPIEL + + Package: grep + Essential: yes + Priority: required + Section: base + Maintainer: Wichert Akkerman <wakkerma@debian.org> + Architecture: sparc + Version: 2.4-1 + Pre-Depends: libc6 (>= 2.0.105) + Provides: rgrep + Conflicts: rgrep + Description: GNU grep, egrep und fgrep. + Die GNU-Familie der Grep-Werkzeuge könnte die „schnellste im Westen“ sein. + GNU Grep basiert auf einem schellen „lazy-state deterministic matcher“ + (rund zweimal so schnell wie der standardmäßige Unix-Egrep) hybridisiert + mit einer Boyer-Moore-Gosper-Suche für eine feste Zeichenkette, die + unmöglichen Text von der Betrachtung durch den vollen „Matcher“ verhindert, + ohne notwendigerweise jedes Zeichen anzuschauen. Das Ergebnis ist + typischerweise um ein Mehrfaches schneller als Unix Grep oder Egrep. + (Reguläre Ausdrücke, die Rückreferenzierungen enthalten, werden allerdings + langsamer laufen.) + +=head1 FEHLER + +Das Feld B<Build-Ids> verwendet einen eher generischen Namen aus seinem +ursprünglichen Zusammenhang innerhalb eines ELF-Objektes, das einem sehr +speziellen Zweck und ausführbaren Format dient. + +=head1 SIEHE AUCH + +L<deb822(5)>, B<deb-src-control>(5), B<deb>(5), B<deb-version>(7), +B<debtags>(1), B<dpkg>(1), B<dpkg-deb>(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. |