Provided by: dpkg-dev_1.19.7ubuntu3.2_all 
BEZEICHNUNG
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. Die in den
Bauprotokollen enthaltenen Diffs können als Startpunkt benutzt werden, aber zusätzlich hat der Betreuer
sicherzustellen, dass sich das Verhalten dieser Symbole nicht derart geändert hat, dass irgendetwas, was
diese Symbole verwendet und gegen die neue Version gelinkt ist, daran hindern würde, mit der alten
Version zu funktionieren. 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 Kommentar, falls sie nicht mit ‚#include’ beginnt (siehe Abschnitt Includes
verwenden). Zeilen, die mit ‚#MISSING:’ anfangen, sind besondere Kommentare, die verschwundene Symbole
dokumentieren.
Vergessen Sie nicht, zu überprüfen, ob alte Versionen aktualisiert werden müssen. Es gibt für
dpkg-gensymbols keine Möglichkeit, hierzu eine Warnung auszugeben. Wird der Diff blind akzeptiert oder
wird angenommen, dass nichts geändert werden muss, wenn es keinen Diff gibt, ohne auf Änderungen zu
prüfen, kann dies dazu führen, dass lockere Abhängigkeiten erzeugt werden, laut deren mit älteren
Versionen gearbeitet werden kann, obwohl dies nicht möglich ist. Dies wird zu schwer zu findenden Fehlern
bei (teilweisen) Upgrades führen.
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 Leerraumzeichen
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
Leerraumzeichen 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
arch-bits=Architektur-Bits
arch-endian=Architektur-Endianness
Diese Markierungen erlauben es, den Satz an Architekturen einzugrenzen, auf denen das Symbol
existieren sollte. Die Markierungen arch-bits und arch-endian werden seit Dpkg 1.18.0 unterstützt.
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 oder nicht auf die Endianess und Bits
passt), wird sie architekturneutral gemacht (d.h. die Architektur-, Architektur-Bits- und
Architektur-Endianessmarkierungen werden 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)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
architecture-bits ist entweder 32 oder 64.
(arch-bits=32)32bit_specific_symbol@Base 1.0
(arch-bits=64)64bit_specific_symbol@Base 1.0
architecture-endianness ist entweder little oder big.
(arch-endian=little)little_endian_specific_symbol@Base 1.0
(arch-endian=big)big_endian_specific_symbol@Base 1.0
Mehrere Einschränkungen können aneinandergehängt werden.
(arch-bits=32|arch-endian=little)32bit_le_symbol@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 die Version aus debian/changelog entnommen.
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).
-lVerzeichnis
Stellt Verzeichnis der Liste der zu durchsuchenden privaten Laufzeitbibliotheken voran (seit Dpkg
1.19.1). Diese Option kann mehrfach angegeben werden.
Hinweis: Verwenden Sie diese Variable, statt LD_LIBRARY_PATH zu setzten, da diese
Umgebungsvariable verwandt wird, um den Laufzeit-Linker zu steuern und ihr Missbrauch zum Setzen
von Pfaden zu Laufzeitbibliotheken zur Bauzeit kann beispielsweise beim Cross-Übersetzen
problematisch werden.
-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. Standardstufe 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 außer Kraft gesetzt
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.
UMGEBUNG
DPKG_GENSYMBOLS_CHECK_LEVEL
Setzt die Befehlsüberprüfungsstufe außer Kraft, selbst wenn das Befehlszeilenargument -c übergeben
wurde (beachten Sie, dass dies der üblichen Konvention widerspricht, demnach
Befehlszeilenargumente Vorrang über Umgebungsvariablen haben).
DPKG_COLORS
Setzt den Farbmodus (seit Dpkg 1.18.5). Die derzeit unterstützten Werte sind: auto (Vorgabe),
always und never.
DPKG_NLS
Falls dies gesetzt ist, wird es zur Entscheidung, ob Native Language Support, auch als
Internationalisierung (oder i18n) Unterstützung bekannt, aktiviert wird (seit Dpkg 1.19.0). Die
akzeptierten Werte sind: 0 und 1 (Vorgabe).
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).
ÜBERSETZUNG
Die deutsche Übersetzung wurde 2004, 2006-2019 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.
1.19.7 2022-05-25 dpkg-gensymbols(1)