diff options
Diffstat (limited to 'man/de/dpkg-gensymbols.man')
| -rw-r--r-- | man/de/dpkg-gensymbols.man | 593 |
1 files changed, 593 insertions, 0 deletions
diff --git a/man/de/dpkg-gensymbols.man b/man/de/dpkg-gensymbols.man new file mode 100644 index 0000000..11e2333 --- /dev/null +++ b/man/de/dpkg-gensymbols.man @@ -0,0 +1,593 @@ +.\" dpkg manual page - dpkg-gensymbols(1) +.\" +.\" Copyright © 2007-2011 Raphaël Hertzog <hertzog@debian.org> +.\" Copyright © 2009-2010 Modestas Vainius <modestas@vainius.eu> +.\" Copyright © 2012-2015 Guillem Jover <guillem@debian.org> +.\" +.\" This is free software; you can redistribute it and/or modify +.\" it under the terms of the GNU General Public License as published by +.\" the Free Software Foundation; either version 2 of the License, or +.\" (at your option) any later version. +.\" +.\" This is distributed in the hope that it will be useful, +.\" but WITHOUT ANY WARRANTY; without even the implied warranty of +.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +.\" GNU General Public License for more details. +.\" +.\" You should have received a copy of the GNU General Public License +.\" along with this program. If not, see <https://www.gnu.org/licenses/>. +. +.\"******************************************************************* +.\" +.\" This file was generated with po4a. Translate the source file. +.\" +.\"******************************************************************* +.TH dpkg\-gensymbols 1 %RELEASE_DATE% %VERSION% dpkg\-Programmsammlung +.nh +.SH BEZEICHNUNG +dpkg\-gensymbols \- Symboldateien (Abhängigkeitsinformationen für +Laufzeitbibliotheken) erstellen +. +.SH ÜBERSICHT +\fBdpkg\-gensymbols\fP [\fIOption\fP …] +. +.SH BESCHREIBUNG +\fBdpkg\-gensymbols\fP durchsucht einen temporären Baubaum (standardmäßig +debian/tmp), sucht nach Bibliotheken und erstellt eine Datei \fIsymbols\fP, 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. +.P +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): +.IP • 4 +debian/\fIPaket\fP.symbols.\fIArchitektur\fP +.IP • 4 +debian/symbols.\fIArchitektur\fP +.IP • 4 +debian/\fIPaket\fP.symbols +.IP • 4 +debian/symbols +.P +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 Verantwortung des Betreuers, diese Dateien aktuell zu +halten, aber \fBdpkg\-gensymbols\fP hilft dabei. +.P +Wenn die erstellten Symboldateien sich von denen, die der Betreuer +bereitgestellt hat, unterscheiden, wird \fBdpkg\-gensymbols\fP einen 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 +\fB\-c\fP). +.SH "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/\fIPaket\fP.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 ‚\fB~\fP’ angehängt werden. +.P +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. +.P +Beachten Sie, dass Sie Kommentare in Symboldateien stellen können: Jede +Zeile, die mit ‚#’ als erstem Zeichen beginnt, ist ein Kommentar, falls sie +nicht mit ‚#include’ beginnt (siehe Abschnitt \fBIncludes +verwenden\fP). Zeilen, die mit ‚#MISSING:’ anfangen, sind besondere +Kommentare, die verschwundene Symbole dokumentieren. +.P +Vergessen Sie nicht, zu überprüfen, ob alte Versionen aktualisiert werden +müssen. Es gibt für \fBdpkg\-gensymbols\fP 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. +.SS "Verwendung der #PACKAGE#\-Ersetzung" +.P +In einigen seltenen Fällen sind die Namen der Bibliotheken nicht auf allen +Architekturen gleich. Um zu vermeiden, dass der Paketname in der Symboldatei +fest kodiert wird, können Sie die Markierung \fI#PACKAGE#\fP verwenden. Während +der Installation der Symboldatei wird sie durch den echten Paketnamen +ersetzt. Anders als die Markierung \fI#MINVER#\fP wird \fI#PACKAGE#\fP nie in der +Symboldatei innerhalb eines Binärpakets auftauchen. +.SS "Verwendung von Symbolkennzeichnungen" +.P +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 \fBdpkg\-gensymbols\fP +verstanden und lösen eine Spezialbehandlung der Symbole aus. Lesen Sie den +Unterabschnitt \fBStandardsymbolkennzeichnungen\fP für eine Referenz dieser +Kennzeichnungen. +.P +Kennzeichnungsspezifikationen kommen direkt vor dem Symbolnamen (dazwischen +sind keine Leerraumzeichen erlaubt). Sie beginnen immer mit einer öffnenden +Klammer \fB(\fP, enden mit einer schließenden Klammer \fB)\fP und müssen +mindestens eine Kennzeichnung enthalten. Mehrere Kennzeichnungen werden +durch das Zeichen \fB|\fP getrennt. Jede der Kennzeichnungen kann optional +einen Wert enthalten, der von der Kennzeichnung durch das Zeichen \fB=\fP +getrennt wird. Kennzeichennamen und \-werte können beliebige Zeichenketten +sein, sie dürfen allerdings keine der der besonderen Zeichen \fB)\fP \fB|\fP \fB=\fP +enthalten. Symbolnamen, die einer Kennzeichnungsspezifikation folgen, können +optional mit den Zeichen \fB'\fP oder \fB"\fP zitiert werden, um Leerraumzeichen +darin zu erlauben. Falls keine Kennzeichnungen für das Symbol spezifiziert +sind, werden Anführungszeichen als Teil des Symbolnamens behandelt, der bis +zum ersten Leerzeichen geht. +.P + (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 +.P +Das erste Symbol im Beispiel heißt \fIzitiertes gekennz Symbol\fP und hat zwei +Kennzeichnungen: \fIKennz1\fP mit dem Wert \fIbin markiert\fP und \fIName mit +Leerraum\fP ohne Wert. Das zweite Symbol heißt +\fIgekennzeichnet_unzitiertes_Symbol\fP und ist nur mit dem Kennzeichen namens +\fIoptional\fP gekennzeichnet. Das letzte Symbol ist ein Beispiel eines +normalen, nicht gekennzeichneten Symbols. +.P +Da Symbolkennzeichnungen eine Erweiterung des Formats \fBdeb\-symbols\fP(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 \fBdpkg\-gensymbols\fP +ohne die Option \fB\-t\fP aufgerufen wird, wird es alle Symbole ausgeben, die +zum Format \fBdeb\-symbols\fP(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 (\fB\-t\fP) in der Ausgabe beibehalten und in +ihrer Originalform, wie sie geladen wurden, auch geschrieben. +.SS Standard\-Symbolkennzeichnungen +.TP +\fBoptional\fP +Ein als „optional“ gekennzeichnetes Symbol kann jederzeit von der Bibliothek +verschwinden und wird nie zum Fehlschlag von \fBdpkg\-gensymbols\fP +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, das bisher als MISSING angegeben 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. +.TP +\fBarch=\fP\fIArchitekturliste\fP +.TQ +\fBarch\-bits=\fP\fIArchitektur\-Bits\fP +.TQ +\fBarch\-endian=\fP\fIArchitektur\-Bytereihenfolge\fP +Diese Markierungen erlauben es, den Satz an Architekturen einzugrenzen, auf +denen das Symbol existieren sollte. Die Markierungen \fBarch\-bits\fP und +\fBarch\-endian\fP 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 \fBdpkg\-gensymbols\fP 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 \fIArchitekturliste\fP ist das gleiche wie das des Feldes +\fBBuild\-Depends\fP in \fIdebian/control\fP (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 auf 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 + +\fIArchitektur\-Bits\fP ist entweder \fB32\fP oder \fB64\fP. + + (arch\-bits=32)32bit_specific_symbol@Base 1.0 + (arch\-bits=64)64bit_specific_symbol@Base 1.0 + +\fIArchitektur\-Bytereihenfolge\fP ist entweder \fBlittle\fP oder \fBbig\fP. + + (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 +.TP +\fBignore\-blacklist\fP +dpkg\-gensymbols verfügt über eine interne Ausschlussliste („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 +\fBignore\-blacklist\fP kennzeichnen. Dies kann für einige grundlegende +Bibliotheken der Werkzeugkette wie Libgcc notwendig sein. +.TP +\fBc++\fP +Gibt \fIc++\fP\-Symbolmuster an. Lesen Sie den Unterabschnitt \fBVerwendung von +Symbolmustern\fP unten. +.TP +\fBsymver\fP +Gibt \fIsymver\fP (Symbolversion)\-Symbolmuster an. Lesen Sie den Unterabschnitt +\fBVerwendung von Symbolmustern\fP unten. +.TP +\fBregex\fP +Gibt \fIregex\fP\-Symbolmuster an. Lesen Sie den Unterabschnitt \fBVerwendung von +Symbolmustern\fP unten. +.SS "Verwendung von Symbolmustern" +.P +Anders als die Standardsymbolspezifikation kann ein Muster mehrere reale +Symbole aus der Bibliothek abdecken. \fBdpkg\-gensymbols\fP wird versuchen, +jedes Muster auf jedes reale Symbol, für das \fIkein\fP spezifisches +Symbolgegenstück in der Symboldatei definiert ist, abzugleichen. 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 +\fBdpkg\-gensymbols\fP in der Stufe \fB\-c1\fP oder höher auslösen. Falls der +Fehlschlag allerdings unerwünscht ist, kann das Muster mit der Kennzeichnung +\fIoptional\fP 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 \fIarch\fP +beschränkt werden. Bitte lesen Sie den Unterabschnitt +\fBStandard\-Symbolkennzeichnungen\fP oben für weitere Informationen. + +Muster sind eine Erweiterung des Formats \fBdeb\-symbols\fP(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 +\fIName@Version\fP eines realen Symbols abgeglichen wird. Um zwischen den +verschiedenen Mustertypen zu unterscheiden, wird es typischerweise mit einer +speziellen Kennzeichnung gekennzeichnet. + +Derzeit unterstützt \fBdpkg\-gensymbols\fP drei grundlegene Mustertypen: +.TP 3 +\fBc++\fP +Dieses Muster wird durch die Kennzeichnung \fIc++\fP verzeichnet. Es passt nur +auf die entworrenen („demangled“) Symbolnamen (wie sie vom Hilfswerkzeug +\fBc++filt\fP(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 \fInon\-virtual thunks\fP, die +einen architekturspezifischen Versatz in ihren verworrenen Namen eingebettet +haben. Eine häufige Instanz dieses Falles ist ein virtueller Destruktor, 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 \fIc++\fP\-Muster abgeglichen 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. +.TP +\fBsymver\fP +Dieses Muster wird durch die Kennzeichnung \fIsymver\fP 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 \fIsymver\fP\-Muster verwenden, um +jedes zu einer spezifizierten Version zugehörige Symbol +zuzuordnen. 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 den Versionen 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“ gehört, 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. +.TP +\fBregex\fP +Muster mit regulären Ausdrücken werden durch die Kennzeichnung \fIregex\fP +verzeichnet. Sie passen auf den regulären Ausdruck von Perl, der im +Symbolnamenfeld angegeben ist. Ein regulärer Ausdruck wird wie er ist +abgeglichen. Denken Sie daher daran, ihn mit dem Zeichen \fI^\fP zu beginnen, +da er ansonsten auf jeden Teil der Zeichenkette des realen Symbols +\fIname@version\fP 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 abgeglichen, 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 abgeglichenen Symbole erben die Kennzeichnung \fIoptional\fP vom Muster. +.P +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\ed\e(int\e)@Base" 1.0 + (regex|c++)N3NSA6ClassA7Private11privmethod\edEi@Base 1.0 + +werden die Symbole „_ZN3NSA6ClassA7Private11privmethod1Ei@Base“ und +„_ZN3NSA6ClassA7Private11privmethod2Ei@Base“ verglichen. Beim Vergleichen +des ersten Musters wird das rohe Symbol erst als C++\-Symbol entworren, dann +wird der entworrene Name mit den regulären Ausdruck verglichen. Auf der +anderen Seite wird beim Vergleichen des zweiten Musters der reguläre +Ausdruck gegen den rohen Symbolnamen verglichen, 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\edEi@Base“ auf keines der Muster passen, +da es kein gültiges C++\-Symbol ist. + +Im Allgemeinen werden die Muster in zwei Kategorien eingeteilt: Aliase +(grundlegende \fIc++\fP\- und \fIsymver\fP\-Muster) und generische Muster (\fIregex\fP +und alle Kombinationen grundlegender Muster). Abgleichen 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 +\fIc++\fP, dann \fIsymver\fP) gegenüber den generischen Mustern +bevorzugt. Generische Muster werden in der Reihenfolge, in der sie in der +Symboldateivorlage gefunden werden, verglichen, bis zum ersten +Erfolg. Beachten Sie aber, dass das manuelle Anordnen der +Vorlagendateieinträge nicht empfohlen wird, da \fBdpkg\-gensymbols\fP Diffs +basierend auf der alphanumerischen Reihenfolge ihrer Namen erstellt. +.SS "Includes verwenden" +.P +Wenn der Satz der exportierten Symbole 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: +.IP • 4 +Sie können den gemeinsamen Teil in eine externe Datei auslagern und diese +Datei dann in Ihre \fIPaket\fP.symbols.\fIArch\fP\-Datei mit einer +include\-Direktive wie folgt einbinden: + +#include "\fIPakete\fP.symbols.common" +.IP • +Die Include\-Direktive kann auch wie jedes Symbol gekennzeichnet werden: + +(Kennzeichen|…|KennzeichenN)#include "einzubindende\-Datei" + +Als Ergebnis werden alle Symbole aus der \fIeinzubindende\-Datei\fP +standardmäßig als mit \fIKennzeichen\fP … \fIKennzeichenN\fP gekennzeichnet +betrachtet. Sie können diese Funktionalität benutzen, um eine gemeinsame +Datei \fIPaket\fP.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 +.P +Die Symboldateien werden Zeile für Zeile gelesen und include\-Direktiven +werden bearbeitet, sobald sie erkannt werden. Das bedeutet, dass der Inhalt +der mit include eingebundenen Datei jeden Inhalt überschreiben kann, der vor +der Include\-Direktive aufgetaucht ist und Inhalt nach der Direktive alles +aus der eingebundenen Datei überschreiben kann. Jedes Symbol (oder sogar +weitere #include\-Direktiven) in der eingebundenen Datei kann zusätzliche +Kennzeichnungen spezifizieren oder Werte der vererbten Kennzeichnungen in +ihrer Kennzeichnungsspezifikation überschreiben. Allerdings gibt es keine +Möglichkeit für ein Symbol, die ererbten Kennzeichnungen zu überschreiben. +.P +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. Eine Art, dies zu erreichen, ist wie folgt: +.PP +#include "libirgendwas1.symbols.common" + arch_spezifisches_Symbol@Base 1.0 +.SS "Gute Bibliotheksverwaltung" +.P +Eine gut verwaltete Bibliothek hat die folgenden Eigenschaften: +.IP • 4 +ihre API ist stabil (öffentliche Symbole entfallen nie, nur neue öffentliche +Symbole werden hinzugefügt) und inkompatible Änderungen erfolgen nur, wenn +sich der SONAME ändert, +.IP • 4 +idealerweise verwendet sie Symbolversionierung, um ABI\-Stabilität trotz +interner Änderungen und API\-Erweiterungen zu erreichen, +.IP • 4 +sie exportiert nie private Symbole (als Hilfslösung können diese als +optional gekennzeichnet werden). +.P +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 der Originalautoren 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. +.SH OPTIONEN +.TP +\fB\-P\fP\fIPaketbauverzeichnis\fP +Sucht nach \fIPaketbauverzeichnis\fP statt nach debian/tmp. +.TP +\fB\-p\fP\fIPaket\fP +Definiert den Paketnamen. Wird benötigt, falls mehr als ein binäres Paket in +debian/control aufgeführt ist (oder falls es keine Datei debian/control +gibt). +.TP +\fB\-v\fP\fIVersion\fP +Definiert die Paketversion. Standardmäßig wird die Version aus +\fIdebian/changelog\fP entnommen. Benötigt, falls der Aufruf außerhalb des +Quellpaketbaums erfolgt. +.TP +\fB\-e\fP\fIBibliotheksdatei\fP +Untersucht nur die explizit aufgeführten Bibliotheken, statt nach allen +öffentlichen Bibliotheken zu suchen. Sie können Shell\-Muster, die zur +Expansion von Pfadnamen verwandt werden (siehe die Handbuchseite +\fBFile::Glob\fP(3perl) für weitere Details) in \fIBibliotheksdatei\fP verwenden, +um mehrere Bibliotheken mit einem einzelnen Argument abzugleichen +(andernfalls benötigen Sie mehrere \fB\-e\fP). +.TP +\fB\-l\fP\fIVerzeichnis\fP +Stellt \fIVerzeichnis\fP 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 \fBLD_LIBRARY_PATH\fP zu setzen, +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\-Kompilieren problematisch werden. +.TP +\fB\-I\fP\fIDateiname\fP +Verwendet \fIDateiname\fP als Referenzdatei, um die Symboldatei zu erstellen, +die dann im Paket selbst integriert wird. +.TP +\fB\-O\fP[\fIDateiname\fP] +Die erstellte Symbols\-Datei auf die Standardausgabe oder nach \fIDateiname\fP, +falls angegeben, ausgeben statt in \fBdebian/tmp/DEBIAN/symbols\fP (oder +\fIPaket\-Bauverzeichnis\fP\fB/DEBIAN/symbols\fP, falls \fB\-P\fP verwandt +wurde). Falls \fIDateiname\fP 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. +.TP +\fB\-t\fP +Schreibt die Symboldatei im Vorlagenmodus statt im zu \fBdeb\-symbols\fP(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 +entfernten Kennzeichnungen im Kompatibilitätsmodus. Desweiteren könnten +einige Symbole beim Schreiben einer Standard\-\fBdeb\-symbols\fP(5)\-Datei +entfernt werden (gemäß der Verarbeitungsregeln für Kennzeichen), während in +der Symboldateivorlage immer alle Symbole geschrieben werden. +.TP +\fB\-c\fP\fI[0\-4]\fP +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 fehl, 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 \fBDPKG_GENSYMBOLS_CHECK_LEVEL\fP +außer Kraft gesetzt werden. +.TP +\fB\-q\fP +Ruhig verhalten und nie einen Diff zwischen der erstellten Symboldatei und +der als Startpunkt verwandten Vorlagendatei erstellen oder keine Warnungen +bezüglich neuer/verschwundener Bibliotheken oder neuer/verschwundener +Symbole ausgeben. Diese Option deaktiviert nur die informative Ausgabe, aber +nicht die Prüfungen selbst (sehen Sie hierzu die Option \fB\-c\fP). +.TP +\fB\-a\fP\fIArchitektur\fP +Nimmt \fIArch\fP 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. +.TP +\fB\-d\fP +Debug\-Modus aktivieren. Eine Vielzahl von Meldungen wird angezeigt, um zu +erklären, was \fBdpkg\-gensymbols\fP durchführt. +.TP +\fB\-V\fP +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. +.TP +\fB\-?\fP, \fB\-\-help\fP +Zeigt einen Hinweis zum Aufruf und beendet das Programm. +.TP +\fB\-\-version\fP +Gibt die Version aus und beendet das Programm. +. +.SH UMGEBUNG +.TP +\fBDPKG_GENSYMBOLS_CHECK_LEVEL\fP +Setzt die Befehlsüberprüfungsstufe außer Kraft, selbst wenn das +Befehlszeilenargument \fB\-c\fP übergeben wurde (beachten Sie, dass dies der +üblichen Konvention widerspricht, demnach Befehlszeilenargumente Vorrang +gegenüber Umgebungsvariablen haben). +.TP +\fBDPKG_COLORS\fP +Setzt den Farbmodus (seit Dpkg 1.18.5). Die derzeit unterstützten Werte +sind: \fBauto\fP (Vorgabe), \fBalways\fP und \fBnever\fP. +.TP +\fBDPKG_NLS\fP +Falls dies gesetzt ist, wird es zur Entscheidung, ob Native Language +Support, auch als Unterstützung für Internationalisierung (oder i18n) +bekannt, aktiviert wird (seit Dpkg 1.19.0). Die akzeptierten Werte sind: +\fB0\fP und \fB1\fP (Vorgabe). +. +.SH "SIEHE AUCH" +\fBhttps://people.redhat.com/drepper/symbol\-versioning\fP +.br +\fBhttps://people.redhat.com/drepper/goodpractice.pdf\fP +.br +\fBhttps://people.redhat.com/drepper/dsohowto.pdf\fP +.br +\fBdeb\-symbols\fP(5), \fBdpkg\-shlibdeps\fP(1). +.SH ÜBERSETZUNG +Die deutsche Übersetzung wurde 2004, 2006-2020 von Helge Kreutzmann +<debian@helgefjell.de>, 2007 von Florian Rehnisch <eixman@gmx.de>, +2008 von Sven Joachim <svenjoac@gmx.de> und 2019,2020 von Mario +Blättermann <mario.blaettermann@gmail.com> +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. |