Provided by: dpkg-dev_1.17.5ubuntu5.8_all 
NAME
dpkg-gensymbols - erstelle Symboldateien (Abhängigkeitsinformationen für
Laufzeitbibliotheken)
ÜBERSICHT
dpkg-gensymbols [Option ?]
BESCHREIBUNG
dpkg-gensymbols durchsucht einen temporären Baubaum (standardmäßig debian/tmp), sucht nach
Bibliotheken und erstellt eine Datei symbols, die diese beschreibt. Diese Datei wird,
falls sie nicht leer ist, in das Unterverzeichnis DEBIAN des Baubaums installiert, so dass
sie schlussendlich in der Steuerinformation des Pakets auftaucht.
Beim Erstellen dieser Dateien verwendet es als Eingabe einige vom Betreuer bereitgestellte
Symboldateien. Es sucht nach den folgenden Dateien (und verwendet die erste, die gefunden
wird):
• debian/Paket.symbols.Architektur
• debian/symbols.Architektur
• debian/Paket.symbols
• debian/symbols
Der Hauptzweck dieser Dateien besteht darin, die minimale Version bereitzustellen, die mit
jedem von der Bibliothek bereitgestellten Symbol verknüpft ist. Normalerweise entspricht
dies der ersten Version des Pakets, die dieses Symbol bereitgestellt hat, kann aber vom
Betreuer erhöht werden, falls die ABI des Symbols ohne Brechen der Rückwärtskompatibilität
erweitert wurde. Es liegt in der Verwantwortung des Betreuers, diese Dateien aktuell zu
halten, aber dpkg-gensymbols hilft dabei.
Wenn die erstellten Symboldateien sich von denen, die der Betreuer bereitgestellt hat,
unterscheiden, wird dpkg-gensymbols ein Diff zwischen den zwei Versionen anzeigen. Falls
die Unterschiede desweiteren zu gravierend sind, wird es sogar fehlschlagen (Sie können
einstellen, wie große Unterschiede Sie tolerieren können, sehen Sie hierzu die Option -c).
SYMBOLDATEIEN PFLEGEN
Die Symboldateien sind nur wirklich nützlich, falls sie die Entwicklung eines Paketes über
mehrere Veröffentlichungen hinweg wiedergeben. Daher muss der Betreuer sie immer
aktualisieren, wenn eine neues Symbol hinzugefügt wird, so dass die zugeordnete minimale
Version der Realität entspricht. Um dies vernünftig durchzuführen, können die Diffs aus
den Bauprotokollen verwandt werden. Meistens kann der Diff direkt auf die Datei
debian/Paket.symbols angewandt werden. Allerdings werden normalerweise weitere Anpassungen
notwendig: es wird beispielsweise empfohlen, die Debian-Revision von der minimalen Version
zu entfernen, so dass Backports mit einer niedrigeren Versionsnummer aber der gleichen
Version der Originalautoren immer noch die erstellten Abhängigkeiten erfüllen. Falls die
Debian-Revision nicht entfernt werden kann, da das Symbol wirklich von der
Debian-spezifischen Änderung hinzugefügt wurde, dann sollte der Version »~« angehängt
werden.
Bevor irgendein Patch auf die Symboldatei angewendet wird, sollte der Betreuer zweimal
prüfen, dass der Patch vernünftig ist. Öffentliche Symbole sollten nicht verschwinden,
daher sollte der Patch idealerweise nur neue Zeilen hinzufügen.
Beachten Sie, dass Sie in Symboldateien Kommentare einfügen können: jede Zeile, die mit
»#« als ersten Zeichen beginnt, ist ein Kommentare, falls sie nicht mit »#include« beginnt
(siehe Abschnitt Includes verwenden). Zeilen, die mit »#MISSING:« anfangen, sind besondere
Kommentare, die verschwundene Symbole dokumentieren.
Verwendung der #PACKAGE#-Ersetzung
In einigen seltenen Fällen unterscheidet sich der Name der Bibliothek auf verschiedenen
Architekturen. Um zu vermeiden, dass der Paketname in der Symboldatei fest kodiert wird,
können Sie die Markierung #PACKAGE# verwenden. Während der Installation der Symboldatei
wird sie durch den echten Paketnamen ersetzt. Anders als die Markierung #MINVER# wird
#PACKAGE# nie in der Symboldatei innerhalb eines Binärpakets auftauchen.
Verwendung von Symbolkennzeichnungen
Symbolkennzeichnungen sind nützlich, um Symbole zu markieren, die in irgendeiner Weise
besonders sind. Jedes Symbol kann eine beliebige Anzahl zugeordneter Kennzeichnungen
besitzen. Während alle Kennzeichnungen ausgewertet und gespeichert werden, werden nur
einige von dpkg-gensymbols verstanden und lösen eine Spezialbehandlung der Symbole aus.
Lesen Sie den Unterabschnit Standardsymbolkennzeichnungen für eine Referenz dieser
Kennzeichnungen.
Kennzeichnungsspezifikationen kommen direkt vor dem Symbolnamen (dazwischen sind keine
Leerzeichen erlaubt). Sie beginnen immer mit einer öffnenden Klammer (, enden mit einer
schließenden Klammer ) und müssen mindestens eine Kennzeichnung enthalten. Mehrere
Kennzeichnungen werden durch das Zeichen | getrennt. Jede Kennzeichnungen kann optional
einen Wert enthalten, der von der Kennzeichnung durch das Zeichen = getrennt wird.
Kennzeichennamen und -werte können beliebige Zeichenketten sein, sie dürfen allerdings
keine der der besonderen Zeichen ) | = enthalten. Symbolnamen, die einer
Kennzeichnungsspezifikation folgen, können optional mit den Zeichen ' oder " zitiert
werden, um Leerzeichen darin zu erlauben. Falls keine Kennzeichnungen für das Symbol
spezifiziert sind, werden Zitatzeichen als Teil des Symbolnamens behandelt, der bis zum
ersten Leerzeichen geht.
(Kennz1=bin markiert|Name mit Leerraum)"zitiertes gekennz Symbol"@Base 1.0
(optional)gekennzeichnet_unzitiertes_Symbol@Base 1.0 1
ungekennzeichnetes_Symbol@Base 1.0
Das erste Symbol im Beispiel heißt zitiertes gekennz Symbol und hat zwei Kennzeichnungen:
Kennz1 mit dem Wert bin markiert und Name mit Leerraum ohne Wert. Das zweite Symbol heißt
gekennzeichnet_unzitiertes_Symbol und ist nur mit dem Kennzeichen namens optional
gekennzeichnet. Das letzte Symbol ist ein Beispiel eines normalen, nicht gekennzeichneten
Symbols.
Da Symbolkennzeichnungen eine Erweiterung des Formats deb-symbols(5) sind, können sie nur
Teil der in Quellpaketen verwandten Symboldateien sein (diese Dateien sollten dann als
Vorlagen zum Bau der Symboldateien, die in Binärpakete eingebettet werden, gesehen
werden). Wenn dpkg-gensymbols ohne die Option -t aufgerufen wird, wird es alle Symbole
ausgeben, die zum Format deb-symbols(5) kompatibel sind: Es verarbeitet die Symbole
entsprechend der Anforderungen ihrer Standardkennzeichnungen und entfernt alle
Kennzeichnungen aus der Ausgabe. Im Gegensatz dazu werden alle Symbole und ihre
Kennzeichnungen (sowohl die Standardkennzeichnungen als auch die unbekannten) im
Vorlagenmodus (-t) in der Ausgabe beibehalten und in ihrer Originalform wie sie geladen
wurden auch geschrieben.
Standard-Symbolkennzeichnungen
optional
Ein als »optional« gekennzeichnetes Symbol kann jederzeit von der Bibliothek
verschwinden und wird nie zum Fehlschlag von dpkg-gensymbols führen. Verschwundene
optionale Symbole werden kontinuierlich als MISSING (Fehlend) in dem Diff in jeder
neuen Paketversion auftauchen. Dieses Verhalten dient als Erinnerung für den
Betreuer, dass so ein Symbol aus der Symboldatei entfernt oder wieder der
Bibliothek hinzugefügt werden muss. Wenn das optionale Symbol, dass bisher als
MISSING bezeichnet gewesen war, plötzlich in der nächsten Version wieder auftaucht,
wird es wieder auf den Status »existing« (existierend) gebracht, wobei die minimale
Version unverändert bleibt.
Diese Markierung ist für private Symbole nützlich, deren Verschwinden keinen
ABI-Bruch auslöst. Beispielsweise fallen die meisten C++-Template-Instanziierungen
in diese Kategorie. Wie jede andere Markierung kann auch diese einen beliebigen
Wert haben: sie könnte angeben, warum dieses Symbol als optional betrachtet wird.
arch=Architekturliste
Die Markierung erlaubt es, den Satz an Architekturen einzugrenzen, auf denen das
Symbol existieren sollte. Wenn die Symbolliste mit den in der Bibliothek entdeckten
Symbolen aktualisiert wird, werden alle architekturspezifischen Symbole, die nicht
auf die aktuelle Host-Architektur passen, so behandelt, als ob sie nicht
existierten. Falls ein architekturspezifisches Symbol, das auf die aktuelle
Host-Architektur passt, in der Bibliothek nicht existiert, werden die normalen
Regeln für fehlende Symbole angewandt und dpkg-gensymbols könnte dadurch
fehlschlagen. Auf der anderen Seite, falls das architekturspezifische Symbol
gefunden wurde, wenn es nicht existieren sollte (da die aktuelle Host-Architektur
nicht in der Markierung aufgeführt ist), wird sie architekturneutral gemacht (d.h.
die Architekturmarkierung wird entfernt und das Symbol wird im Diff aufgrund dieser
Änderung auftauchen), aber es wird nicht als neu betrachtet.
Beim Betrieb im standardmäßigen nicht-Vorlagen-Modus werden unter den
architekturspezifischen Symbolen nur die in die Symboldatei geschrieben, die auf
die aktuelle Host-Architektur passen. Auf der anderen Seite werden beim Betrieb im
Vorlagenmodus alle architekturspezifischen Symbole (darunter auch die von fremden
Architekturen) immer in die Symboldatei geschrieben.
Das Format der Architekturliste ist das gleiche wie das des Feldes Build-Depends in
debian/control (außer den einschließenden eckigen Klammern []). Beispielsweise wird
das erste Symbol aus der folgenden Liste nur auf den Architekturen Alpha, Any-amd64
und Ia64 betrachtet, das zweite nur Linux-Architekturen, während das dritte überall
außer auf Armel betrachtet wird.
(arch=alpha any-amd64 ia64)a_64bit_specific_symbol@Base 1.0
(arch=linux-any)linux_specific_symbol@Base 1.0
(arch=!armel)symbol_armel_does_not_have@Base 1.0
ignore-blacklist
dpkg-gensymbols verfügt über eine interne Ausschußliste (»blacklist«) von Symbolen,
die nicht in Symboldateien auftauchen sollten, da sie normalerweise nur
Seiteneffekte von Implementierungsdetails in der Werkzeugkette darstellen. Falls
Sie aus irgendeinem Grund wollen, dass diese Symbole in der Symboldatei aufgenommen
werden, sollten Sie das Symbol mit ignore-blacklist kennzeichnen. Dies kann für
einige grundlegende Bibliotheken der Werkzeugkette wie libgcc notwendig sein.
c++ Gibt c++-Symbolmuster an. Lesen Sie den Unterabschnitt Verwendung von Symbolmuster
unten.
symver Gibt symver (Symbolversion)-Symbolmuster an. Lesen Sie den Unterabschnitt
Verwendung von Symbolmuster unten.
regex Gibt regex-Symbolmuster an. Lesen Sie den Unterabschnitt Verwendung von
Symbolmuster unten.
Verwendung von Symbolmustern
Anders als die Standardsymbolspezifikation kann ein Muster mehrere reale Symbole aus der
Bibliothek abdecken. dpkg-gensymbols wird versuchen, jedes Muster auf jedes reale Symbol,
für das kein spezifisches Symbolgegenstück in der Symboldatei definiert ist, zu passen.
Wann immer das erste passende Muster gefunden wurde, werden alle Kennzeichnungen und
Eigenschaften als Basisspezifikation des Symbols verwandt. Falls keines der Muster passt,
wird das Symbol als neu betrachtet.
Ein Muster wird als verloren betrachtet, falls es auf kein Symbol in der Bibliothek passt.
Standardmäßig wird dies ein Versagen von dpkg-gensymbols in der Stufe -c1 oder höher
auslösen. Falls der Fehlschlag allerdings unerwünscht ist, kann das Muster mit der
Kennzeichnung optional markiert werden. Falls das Muster dann auf nichts passt wird es im
Diff nur als MISSING (fehlend) auftauchen. Desweiteren kann das Muster wie jedes Symbol
auf die spezielle Architektur mit der Kennzeichnung arch beschränkt werden. Bitte lesen
Sie den Unterabschnitt Standard Symbolkennzeichnungen oben für weitere Informationen.
Muster sind eine Erweiterung des Formats deb-symbols(5); sie sind daher nur in
Symboldatei-Vorlagen gültig. Die Musterspezifikationssyntax unterscheidet sich nicht von
der eines spezifischen Symbols. Allerdings dient der Symbolnamenteil der Spezifikation als
Ausdruck, der gegen Name@Version eines realen Symbols gepasst wird. Um zwischen den
verschiedenen Mustertypen zu unterscheiden, wird es typischerweise mit einer speziellen
Kennzeichnung gekennzeichnet.
Derzeit unterstützt dpkg-gensymbols drei grundlegene Mustertypen:
c++
Dieses Muster wird durch die Kennzeichnung c++ verzeichnet. Es passt nur auf die
entworrenen (»demangled«) Symbolnamen (wie sie vom Hilfswerkzeug c++filt(1) ausgegeben
werden). Dieses Muster ist sehr hilfreich um auf Symbole zu passen, bei dem die
verworrenen (»mangled«) Namen sich auf verschiedenen Architekturen unterscheiden
während die entworrenen die gleichen bleiben. Eine Gruppe solcher Symbole ist
non-virtual thunks, die einen architekturspezifischen Versatz in ihren verworrenen
Namen eingebettet haben. Eine häufige Instanz dieses Falles ist ein virtueller
Destruktur, der unter rautenförmiger Vererbung ein nicht-virtuelles Thunk-Symbol
benötigt. Selbst wenn beispielsweise _ZThn8_N3NSB6ClassDD1Ev@Base auf 32
Bit-Architekturen _ZThn16_N3NSB6ClassDD1Ev@Base auf 64 Bit-Architekturen ist, kann es
mit einem einzigen c++-Muster gepasst werden:
libdummy.so.1 libdummy1 #MINVER#
[?]
(c++)"non-virtual thunk to NSB::ClassD::~ClassD()@Base" 1.0
[?]
Der entworrene Name oben kann durch Ausführung folgenden Befehls erhalten werden:
$ echo '_ZThn8_N3NSB6ClassDD1Ev@Base' | c++filt
Bitte beachten Sie, dass per Definition zwar der verworrene Name in der Bibliothek
eindeutig ist, die aber nicht notwendigerweise für die entworrenen Namen zutrifft. Ein
Satz von unterschiedlichen realen Symbolen können den gleichen entworrenen Namen haben.
Beispielsweise ist das der Fall bei nicht-virtuellen Thunk-Symbolen in komplexen
Vererbungskonfigurationen oder bei den meisten Konstruktoren und Destruktoren (da g++
typischerweise zwei reale Symbole für sie generiert). Da diese Kollisionen aber auf dem
ABI-Niveau passieren, sollten sie nicht die Qualität der Symboldatei reduzieren.
symver
Dieses Muster wird durch die Kennzeichnung symver verzeichnet. Gut betreute
Bibliotheken verfügen über versionierte Symbole, wobei jede Version zu der Version der
Originalautoren passt, in der dieses Symbol hinzugefügt wurde. Falls das der Fall ist,
können SIe ein symver-Muster verwenden, um auf jedes zu einer spezifizierten Version
zugeordnete Symbol zu passen. Beispiel:
libc.so.6 libc6 #MINVER#
(symver)GLIBC_2.0 2.0
[?]
(symver)GLIBC_2.7 2.7
access@GLIBC_2.0 2.2
Alle Version GLIBC_2.0 und GLIBC_2.7 zugeordneten Symbole werden zu einer minimalen
Version 2.0 bzw. 2.7 führen, wobei das Symbol access@GLIBC_2.0 die Ausnahme darstellt.
Es wird zu einer minimalen Abhängigkeit auf libc6 Version 2.2 führen, obwohl es im
Geltungsbereich des Musters »(symver)GLIBC_2.0« passt, da spezielle Symbole vor Mustern
Vorrang haben.
Bitte beachten Sie, dass Platzhaltermuster im alten Format (angezeigt durch »*@version«
im Symbolnamenfeld) zwar noch unterstützt werden, sie aber durch die Syntax im neuen
Format »(symver|optional)version« abgelöst wurden. Beispielsweise sollte »*@GLIBC_2.0
2.0« als »(symver|optional)GLIBC_2.0 2.0« geschrieben werden, falls das gleiche
Verhalten benötigt wird.
regex
Muster mit regulären Ausdrücken werden durch die Kennzeichnung regex verzeichnet. Sie
passen auf den regulären Ausdruck von Perl, der im Symbolnamenfeld angegeben ist. Ein
regulärer Ausdruck wird wie er ist gepasst. Denken Sie daher daran, ihn mit dem Zeichen
^ zu beginnen, da er ansonsten auf jeden Teil der Zeichenkette des realen Symbols
name@version passt. Beispiel:
libdummy.so.1 libdummy1 #MINVER#
(regex)"^mystack_.*@Base$" 1.0
(regex|optional)"private" 1.0
Symbole wie »mystack_new@Base«, »mystack_push@Base«, »mystack_pop@Base« usw. werden vom
ersten Muster gepasst, während dies z.B. für »ng_mystack_new@Base« nicht der Fall ist.
Das zweite Muster wird auf alle Symbole, die die Zeichenkette »private« in ihren Namen
enthalten, passen und die gepassten Symbole erben die Kennzeichnung optional vom
Muster.
Die oben aufgeführten grundlegenden Muster können - wo es Sinn ergibt - kombiniert werden.
In diesem Fall werden sie in der Reihenfolge verarbeitet, in der die Kennzeichnungen
angegeben sind. Im Beispiel
(c++|regex)"^NSA::ClassA::Private::privmethod\d\(int\)@Base" 1.0
(regex|c++)N3NSA6ClassA7Private11privmethod\dEi@Base 1.0
werden die Symbole »_ZN3NSA6ClassA7Private11privmethod1Ei@Base« und
»_ZN3NSA6ClassA7Private11privmethod2Ei@Base« gepasst. Beim Passen der ersten Musters wird
das rohe Symbol erst als C++-Symbol entworren, dann wird der entworrende Name gegen den
regulären Ausdruck gepasst. Auf der anderen Seite wird beim Passen des zweiten Musters der
reguläre Ausdruck gegen den rohen Symbolnamen gepasst, dann wird das Symbol überprüft, ob
es ein C++-Symbol ist, indem das Entwirren versucht wird. Ein Fehlschlag eines einfachen
Musters wird zum Fehlschlag des gesamten Musters führen. Daher wird beispielsweise
»__N3NSA6ClassA7Private11privmethod\dEi@Base« keines der Muster passen, da es kein
gültiges C++-Symbol ist.
Im Allgemeinen werden die Muster in zwei Kategorien eingeteilt: Aliase (grundlegende c++-
und symver-Muster) und generische Muster (regex und alle Kombinationen grundlegender
Muster). Passen von grundlegenden alias-basierenden Mustern ist schnell (O(1)), während
generische Muster O(N) (wobei N die Anzahl der generischen Muster ist) für jedes Symbol
ist. Daher wird empfohlen, generische Muster nicht zu viel zu verwenden.
Wenn mehrere Muster auf das gleiche Symbol passen, werden Aliase (zuerst c++, dann symver)
gegenüber den generischen Mustern bevorzugt. Generische Muster werden in der Reihenfolge,
in der sie in der Symboldateivorlage gefunden werden, gepasst, bis zum ersten Erfolg.
Beachten Sie aber, dass das manuelle Anordnen der Vorlagendateieinträge nicht empfohlen
wird, da dpkg-gensymbols Diffs basierend auf der alphanumerischen Reihenfolge ihrer Namen
erstellt.
Includes verwenden
Wenn der Satz der exportierten Symbolen sich zwischen Architekturen unterscheidet, kann es
ineffizient werden, eine einzige Symboldatei zu verwenden. In diesen Fällen kann sich eine
Include-Direktive in einer Reihe von Arten als nützlich erweisen:
• Sie können den gemeinsamen Teil in eine externe Datei auslagern und diese Datei dann
in Ihre Paket.symbols.Arch-Datei mit einer include-Direktive wie folgt einbinden:
#include "Pakete.symbols.common"
• Die Include-Direktive kann auch wie jedes Symbol gekennzeichnet werden:
(Kennzeichen|?|KennzeichenN)#include "einzubindende-Datei"
Als Ergebnis werden alle Symbole aus einzubindende-Datei standardmäßig als mit
Kennzeichen ? KennzeichenN gekennzeichnet betrachtet. Sie können diese Funktionalität
benutzen, um eine gemeinsame Datei Paket.symbols zu erstellen, die
architekturspezifische Symboldateien einbindet:
common_symbol1@Base 1.0
(arch=amd64 ia64 alpha)#include "Paket.symbols.64bit"
(arch=!amd64 !ia64 !alpha)#include "Paket.symbols.32bit"
common_symbol2@Base 1.0
Die Symboldateien werden Zeile für Zeile gelesen und include-Direktiven werden bearbeitet,
sobald sie erkannt werden. Das bedeutet, dass der Inhalt der Include-Datei jeden Inhalt
überschreiben kann, der vor der Include-Direktive aufgetaucht ist und Inhalt nach der
Direktive alles aus der Include-Datei überschreiben kann. Jedes Symbol (oder sogar weitere
#include-Direktiven) in der Include-Datei kann zusätzliche Kennzeichnungen spezifizieren
oder Werte der vererbtgen Kennzeichnungen in ihrer Kennzeichnungsspezifikation
überschreiben. Allerdings gibt es keine Möglichkeit für ein Symbol, die ererbten
Kennzeichnungen zu überschreiben.
Eine eingebundene Datei kann die Kopfzeile wiederholen, die den SONAME der Bibliothek
enthält. In diesem Fall überschreibt sie jede vorher gelesene Kopfzeile. Allerdings ist es
im Allgemeinen am Besten, die Wiederholung von Kopfzeilen zu vermeiden. Ein Weg dies zu
erreichen, ist wie folgt:
#include "libirgendwas1.symbols.common"
arch_spezifisches_Symbol@Base 1.0
Gute Bibliotheksverwaltung
Eine gut verwaltete Bibliothek hat die folgenden Eigenschaften:
• seine API ist stabil (öffentliche Symbole entfallen nie, nur neue öffentliche Symbole
werden hinzugefügt) und inkompatible Änderungen erfolgen nur, wenn sich der SONAME
ändert,
• idealerweise verwendet sie Symbolversionierung, um ABI-Stabilität trotz interner
Änderungen und API-Erweiterungen zu erreichen,
• sie exportiert nie private Symbole (als Hilfslösung können diese als optional
gekennzeichnet werden).
Bei der Verwaltung der Symboldatei kann das Auftauchen und Verschwinden von Symbolen
leicht bemerkt werden. Es ist aber schwieriger, inkompatbile API- und ABI-Änderungen zu
bemerken. Daher sollte der Betreuer intensiv die Changelog-Einträge durchschauen und nach
Fällen suchen, in denen die Regeln der guten Bibliotheksverwaltung gebrochen wurden. Falls
mögliche Probleme entdeckt wurden, sollten der Originalautor informiert werden, da eine
Korrektur vom Originalautor immer besser als eine Debian-spezifische Hilfslösung ist.
OPTIONEN
-PPaketbauverzeichnis
Suche nach Paketbauverzeichnis statt nach debian/tmp.
-pPaket
Definiert den Paketnamen. Benötigt, falls mehr als ein binäres Paket in
debian/control aufgeführt ist (oder falls es keine Datei debian/control gibt).
-vVersion
Definiert die Paketversion. Standardmäßig wird eie Version aus debian/changelog
ausgelesen. Benötigt, falls der Aufruf außerhalb des Quellpaketbaums erfolgt.
-eBibliotheksdatei
Nur die explizit aufgeführten Bibliotheken untersuchen statt alle öffentlichen
Bibliotheken zu finden. Sie können Shell-Muster, die zur Expansion von Pfadnamen
verwandt werden (siehe die Handbuchseite File::Glob(3perl) für weitere Details) in
Bibliotheksdatei verwenden, um mehrere Bibliotheken mit einem einzelnen Argument zu
passen (andernfalls benötigen Sie mehrere -e).
-IDateiname
Verwende Dateiname als Referenzdatei, um die Symboldatei zu erstellen, die dann im
Paket selbst integriert wird.
-O[Dateiname]
Die erstellte Symbols-Datei auf die Standardausgabe oder nach Dateiname, falls
angegeben, ausgeben statt in debian/tmp/DEBIAN/symbols (oder
Paket-Bauverzeichnis/DEBIAN/symbols falls -P verwandt wurde). Falls Dateiname
bereits existiert, wird deren Inhalt als Grundlage für die erstellte Symboldatei
verwandt. Sie können diese Funktionalität benutzen, um eine Symboldatei zu
aktualisieren, so dass sie zu einer neueren Version der Originalautoren Ihrer
Bibliothek passt.
-t Schreibe die Symboldatei im Vorlagenmodus statt im zu deb-symbols(5) kompatiblen
Format. Der Hauptunterschied besteht darin, dass im Vorlagenmodus die Symbolnamen
und Kennzeichnungen in ihrer Originalform geschrieben werden, im Gegensatz zu den
verarbeiteten Symbolnamen mit entfernen Kennzeichnungen im Kompatibilitätsmodus.
Desweiteren könnten einige Symbole beim Schreiben einer Standard
deb-symbols(5)-Datei entfernt werden (gemäß der Verarbeitungsregeln für
Kennzeichen), während in der Symboldateivorlage immer alle Symbole geschrieben
werden.
-c[0-4]
Definiert die Prüfungen, die beim Vergleich der erstellten Symboldatei mit der
Vorlagendatei als Startpunkt erfolgen sollen. Standardardstufe ist 1. Zunehmende
Stufen führen mehr Prüfungen durch und enthalten alle Prüfungen der niedrigeren
Stufen. Stufe 0 schlägt nie fehl. Stufe 1 schlägt fehl, wenn einige Symbole
verschwunden sind. Stufe 2 schlägt fehlt, falls einige neue Symbole eingeführt
wurden. Stufe 3 schlägt fehl, falls einige Bibliotheken verschwunden sind. Stufe 4
schlägt fehl, falls einige Bibliotheken hinzugekommen sind.
Dieser Wert kann von der Umgebungsvariablen DPKG_GENSYMBOLS_CHECK_LEVEL
überschrieben werden.
-q Ruhig verhalten und nie einen Diff zwischen der erstellten Symboldatei und der als
Startpunkt verwandten Vorlagendatei erstellen oder keine Warnungen bezüglich
neuer/verlorender Bibliotheken oder neuer/verlorender Symbole ausgeben. Diese
Option deaktiviert nur die informative Ausgabe aber nicht die Prüfungen selbst
(sehen Sie hierzu die Option -c).
-aArchitektur
Nehme Arch als Host-Architektur beim Verarbeiten der Symboldateien an. Verwenden
Sie diese Option, um Symboldateien oder Diffs für beliebige Architekturen zu
erstellen, vorausgesetzt, die Binärprogramme sind bereits verfügbar.
-d Debug-Modus aktivieren. Eine Vielzahl von Nachrichten wird angezeigt, um zu
erklären, was dpkg-gensymbols durchführt.
-V Ausführlichen Modus aktivieren. Die erstellte Symboldatei enthält veraltete Symbole
als Kommentare. Im Vorlagenmodus werden Mustersymbole desweiteren von Kommentaren
gefolgt, die die echten Symbole aufführen, die auf dieses Muster passen.
-?, --help
Zeige den Bedienungshinweis und beende.
--version
Gebe die Version aus und beende sich.
ÜBERSETZUNG
Die deutsche Übersetzung wurde 2004, 2006-2013 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.
SIEHE AUCH
https://people.redhat.com/drepper/symbol-versioning
https://people.redhat.com/drepper/goodpractice.pdf
https://people.redhat.com/drepper/dsohowto.pdf
deb-symbols(5), dpkg-shlibdeps(1).