Provided by: dpkg-dev_1.19.7ubuntu3.2_all bug

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