diff options
author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-27 09:40:31 +0000 |
---|---|---|
committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-27 09:40:31 +0000 |
commit | b86570f63e533abcbcb97c2572e0e5732a96307b (patch) | |
tree | cabc83be691530ae685c45a8bc7620ccc0e1ebdf /man/de/deb-src-symbols.pod | |
parent | Initial commit. (diff) | |
download | dpkg-b86570f63e533abcbcb97c2572e0e5732a96307b.tar.xz dpkg-b86570f63e533abcbcb97c2572e0e5732a96307b.zip |
Adding upstream version 1.20.13.upstream/1.20.13upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'man/de/deb-src-symbols.pod')
-rw-r--r-- | man/de/deb-src-symbols.pod | 419 |
1 files changed, 419 insertions, 0 deletions
diff --git a/man/de/deb-src-symbols.pod b/man/de/deb-src-symbols.pod new file mode 100644 index 0000000..b6d32f7 --- /dev/null +++ b/man/de/deb-src-symbols.pod @@ -0,0 +1,419 @@ + + ***************************************************** + * GENERATED FILE, DO NOT EDIT * + * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION * + ***************************************************** + +This file was generated by po4a(7). Do not store it (in VCS, for example), +but store the PO file used as source file by po4a-translate. + +In fact, consider this as a binary, and the PO file as a regular .c file: +If the PO get lost, keeping this translation up-to-date will be harder. + +=encoding UTF-8 + +=head1 BEZEICHNUNG + +deb-symbols - Debians erweiterte Vorlagendatei für Laufzeitbibliotheken + +=head1 ÜBERSICHT + +B<debian/>I<Paket>B<.symbols.>I<Arch>, B<debian/symbols.>I<Arch>, +B<debian/>I<Paket>B<.symbols>, B<debian/symbols> + +=head1 BESCHREIBUNG + +Die Symboldateivorlagen werden in Debian-Quellpaketen ausgeliefert. Deren +Format ist eine Obermenge der in Binärpaketen ausgelieferten Symboldateien, +siehe L<deb-symbols(5)>. + +=head2 Kommentare + +In Symboldateien werden Kommentare unterstützt. Jede Zeile, die mit ‚#’ als +erstem Zeichen beginnt, ist ein Kommentar, falls sie nicht mit ‚#include’ +beginnt (siehe Abschnitt B<Includes verwenden>). Zeilen, die mit ‚#MISSING:’ +anfangen, sind besondere Kommentare, die verschwundene Symbole +dokumentieren. + +=head2 Verwendung der #PACKAGE#-Ersetzung + +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 I<#PACKAGE#> verwenden. Während +der Installation der Symboldatei wird sie durch den echten Paketnamen +ersetzt. Anders als die Markierung I<#MINVER#> wird I<#PACKAGE#> nie in der +Symboldatei innerhalb eines Binärpakets auftauchen. + +=head2 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 B<dpkg-gensymbols> +verstanden und lösen eine Spezialbehandlung der Symbole aus. Lesen Sie den +Unterabschnitt B<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 B<(>, enden mit einer schließenden Klammer B<)> und müssen +mindestens eine Kennzeichnung enthalten. Mehrere Kennzeichnungen werden +durch das Zeichen B<|> getrennt. Jede der Kennzeichnungen kann optional +einen Wert enthalten, der von der Kennzeichnung durch das Zeichen B<=> +getrennt wird. Kennzeichennamen und -werte können beliebige Zeichenketten +sein, sie dürfen allerdings keine der der besonderen Zeichen B<)> B<|> B<=> +enthalten. Symbolnamen, die einer Kennzeichnungsspezifikation folgen, können +optional mit den Zeichen B<'> oder B<"> 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. + + (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 I<zitiertes gekennz Symbol> und hat zwei +Kennzeichnungen: I<Kennz1> mit dem Wert I<bin markiert> und I<Name mit +Leerraum> ohne Wert. Das zweite Symbol heißt +I<gekennzeichnet_unzitiertes_Symbol> und ist nur mit dem Kennzeichen namens +I<optional> gekennzeichnet. Das letzte Symbol ist ein Beispiel eines +normalen, nicht gekennzeichneten Symbols. + +Da Symbolkennzeichnungen eine Erweiterung des Formats B<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 B<dpkg-gensymbols> +ohne die Option B<-t> aufgerufen wird, wird es alle Symbole ausgeben, die +zum Format B<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 (B<-t>) in der Ausgabe beibehalten und in +ihrer Originalform, wie sie geladen wurden, auch geschrieben. + +=head2 Standard-Symbolkennzeichnungen + +=over + +=item B<optional> + +Ein als „optional“ gekennzeichnetes Symbol kann jederzeit von der Bibliothek +verschwinden und wird nie zum Fehlschlag von B<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, 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. + +=item B<arch=>I<Architekturliste> + +=item B<arch-bits=>I<Architektur-Bits> + +=item B<arch-endian=>I<Architektur-Bytereihenfolge> + +Diese Markierungen erlauben es, den Satz an Architekturen einzugrenzen, auf +denen das Symbol existieren sollte. Die Markierungen B<arch-bits> und +B<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 B<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 Bytereihenfolge und Bits +passt), wird sie architekturneutral gemacht (d.h. die Architektur-, +Architektur-Bits- und Architektur-Bytereihenfolgemarkierungen 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 I<Architekturliste> ist das gleiche wie das des Feldes +B<Build-Depends> in I<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 auf Linux-Architekturen, während das dritte überall außer auf Armel +betrachtet wird. + + (arch=alpha any-amd64 ia64)64_Bit_spezifisches_Symbol@Base 1.0 + (arch=linux-any)Linux_spezifisches_Symbol@Base 1.0 + (arch=!armel)Symbol_das_Armel_nicht_hat@Base 1.0 + +I<Architektur-Bits> ist entweder B<32> oder B<64>. + + (arch-bits=32)32_Bit_spezifisches_Symbol@Base 1.0 + (arch-bits=64)64_Bit_spezifisches_Symbol@Base 1.0 + +I<Architektur-Bytereihenfolge> ist entweder B<little> oder B<big>. + + (arch-endian=little)Little_Endian_spezifisches_Symbol@Base 1.0 + (arch-endian=big)Big_Endian_spezifisches_Symbol@Base 1.0 + +Mehrere Einschränkungen können aneinandergehängt werden. + + (arch-bits=32|arch-endian=little)32_Bit_Le_Symbol@Base 1.0 + +=item B<allow-internal> + +dpkg-gensymbols verfügt über eine interne Liste von Symbolen, die nicht in +Symboldateien auftauchen sollten, da sie normalerweise nur Nebeneffekte von +Implementierungsdetails in der Werkzeugkette darstellen (seit Dpkg +1.20.1). Falls Sie aus irgendeinem Grund wollen, dass diese Symbole in der +Symboldatei aufgenommen werden, sollten Sie das Symbol mit B<allow-internal> +kennzeichnen. Dies kann für einige grundlegende Bibliotheken der +Werkzeugkette wie „libgcc“ notwendig sein. + +=item B<ignore-blacklist> + +Ein veralteter Alias für B<allow-internal> (seit Dpkg 1.20.1, unterstützt +seit Dpkg 1.15.3). + +=item B<c++> + +Gibt I<c++>-Symbolmuster an. Lesen Sie den nachfolgenden Unterabschnitt +B<Verwendung von Symbolmustern>. + +=item B<symver> + +Gibt I<symver> (Symbolversion)-Symbolmuster an. Lesen Sie den nachfolgenden +Unterabschnitt B<Verwendung von Symbolmustern>. + +=item B<regex> + +Gibt I<regex>-Symbolmuster an. Lesen Sie den nachfolgenden Unterabschnitt +B<Verwendung von Symbolmustern>. + +=back + +=head2 Verwendung von Symbolmustern + +Anders als die Standardsymbolspezifikation kann ein Muster mehrere reale +Symbole aus der Bibliothek abdecken. B<dpkg-gensymbols> wird versuchen, +jedes Muster auf jedes reale Symbol, für das I<kein> 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 +B<dpkg-gensymbols> in der Stufe B<-c1> oder höher auslösen. Falls der +Fehlschlag allerdings unerwünscht ist, kann das Muster mit der Kennzeichnung +I<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 I<arch> +beschränkt werden. Bitte lesen Sie den Unterabschnitt +B<Standard-Symbolkennzeichnungen> oben für weitere Informationen. + +Muster sind eine Erweiterung des Formats B<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 +I<Name@Version> eines realen Symbols abgeglichen wird. Um zwischen den +verschiedenen Mustertypen zu unterscheiden, wird es typischerweise mit einer +speziellen Kennzeichnung gekennzeichnet. + +Derzeit unterstützt B<dpkg-gensymbols> drei grundlegene Mustertypen: + +=over + +=item B<c++> + +Dieses Muster wird durch die Kennzeichnung I<c++> verzeichnet. Es passt nur +auf die entworrenen („demangled“) Symbolnamen (wie sie vom Hilfswerkzeug +B<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 I<non-virtual thunks>, 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 I<c++>-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. + +=item B<symver> + +Dieses Muster wird durch die Kennzeichnung I<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 I<symver>-Muster verwenden, +das auf jedes zu einer spezifizierten Version zugehörige Symbol +passt. 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. + +=item B<regex> + +Muster mit regulären Ausdrücken werden durch die Kennzeichnung I<regex> +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 I<^> zu beginnen, +da er ansonsten auf jeden Teil der Zeichenkette des realen Symbols +I<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. passen auf das erste Muster, 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 I<optional> vom Muster. + +=back + +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“ 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\dEi@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 I<c++>- und I<symver>-Muster) und generische Muster (I<regex> +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 +I<c++>, dann I<symver>) 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 B<dpkg-gensymbols> Diffs +basierend auf der alphanumerischen Reihenfolge ihrer Namen erstellt. + +=head2 Includes verwenden + +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: + +=over + +=item * + +Sie können den gemeinsamen Teil in eine externe Datei auslagern und diese +Datei dann in Ihre I<Paket>.symbols.I<Arch>-Datei mit einer +include-Direktive wie folgt einbinden: + + #include "I<Pakete>.symbols.common" + +=item * + +Die Include-Direktive kann auch wie jedes Symbol gekennzeichnet werden: + + (Kennzeichen|…|KennzeichenN)#include "einzubindende-Datei" + +Als Ergebnis werden alle Symbole aus der I<einzubindende-Datei> +standardmäßig als mit I<Kennzeichen> … I<KennzeichenN> gekennzeichnet +betrachtet. Sie können diese Funktionalität benutzen, um eine gemeinsame +Datei I<Paket>.symbols zu erstellen, die architekturspezifische +Symboldateien einbindet: + + gemeinsames_Symbol1@Base 1.0 + (arch=amd64 ia64 alpha)#include "Paket.symbols.64bit" + (arch=!amd64 !ia64 !alpha)#include "Paket.symbols.32bit" + gemeinsames_Symbol2@Base 1.0 + +=back + +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. + +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: + + #include "libirgendwas1.symbols.common" + arch_spezifisches_Symbol@Base 1.0 + +=head1 SIEHE AUCH + +B<deb-symbols>(5), B<dpkg-shlibdeps>(1), B<dpkg-gensymbols>(1). + + +=head1 ÜBERSETZUNG + +Die deutsche Übersetzung wurde 2004, 2006-2020 von Helge Kreutzmann +<debian@helgefjell.de>, 2007 von Florian Rehnisch <eixman@gmx.de> und +2008 von Sven Joachim <svenjoac@gmx.de> +angefertigt. Diese Übersetzung ist Freie Dokumentation; lesen Sie die +GNU General Public License Version 2 oder neuer für die Kopierbedingungen. +Es gibt KEINE HAFTUNG. |