table of contents
dpkg-gensymbols(1) | dpkg-Hilfsprogramme | dpkg-gensymbols(1) |
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
SYMBOLDATEIEN PFLEGEN¶
Die Symboldateien sind nur wirklich nützlich, falls sie die Entwicklung eines Paketes über mehrere Veröffentlichungen hinweg wiedergeben. Daher muss der Betreuer sie immer aktualisieren, wenn eine neues Symbol hinzugefügt wird, so dass die zugeordnete minimale Version der Realität entspricht. Um dies vernünftig durchzuführen, kann er Diffs aus den Bauprotokolle verwenden. Meistens kann der Diff direkt auf die Datei debian/ Paket.symbols angewandt werden. Allerdings werden normalerweise weitere Anpassungen notwendig: es wird beispielsweise empfohlen, die Debian-Revision von der minimalen Version zu entfernen, so dass Backports mit einer niedrigeren Versionsnummer aber der gleichen Version der Originalautoren immer noch die erstellten Abhängigkeiten erfüllen. Falls die Debian-Revision nicht entfernt werden kann, da das Symbol wirklich von der Debian-spezifischen Änderung hinzugefügt wurde, dann sollte der Version »~« angehängt werden. Bevor irgendein Patch auf die Symboldatei angewendet wird, sollte der Betreuer zweimal prüfen, dass der Patch vernünftig ist. Öffentliche Symbole sollten nicht verschwinden, daher sollte der Patch idealerweise nur neue Zeilen hinzufügen. Beachten Sie, dass Sie in Symboldateien Kommentare einfügen können: jede Zeile, die mit »#« als ersten Zeichen beginnt, ist ein Kommentare, falls sie nicht mit »#include« beginnt (siehe Abschnitt Includes verwenden). Zeilen, die mit »#MISSING:« anfangen, sind besondere Kommentare, die verschwundene Symbole dokumentieren.Verwendung der #PACKAGE#-Ersetzung¶
In einigen seltenen Fällen unterscheidet sich der Name der Bibliothek auf verschiedenen Architekturen. Um zu vermeiden, dass der Paketname in der Symboldatei fest kodiert wird, können Sie die Markierung #PACKAGE# verwenden. Während der Installation der Symboldatei wird sie durch den echten Paketnamen ersetzt. Anders als die Markierung #MINVER# wird #PACKAGE# nie in der Symboldatei innerhalb eines Binärpakets auftauchen.Verwendung von Symbolkennzeichnungen¶
Symbolkennzeichnungen sind nützlich, um Symbole zu markieren, die in irgendeiner Weise besonders sind. Jedes Symbol kann eine beliebige Anzahl zugeordneter Kennzeichnungen besitzen. Während alle Kennzeichnungen ausgewertet und gespeichert werden, werden nur einige von dpkg-gensymbols verstanden und lösen eine Spezialbehandlung der Symbole aus. Lesen Sie den Unterabschnit Standardsymbolkennzeichnungen für eine Referenz dieser Kennzeichnungen. Kennzeichnungsspezifikationen kommen direkt vor dem Symbolnamen (dazwischen sind keine Leerzeichen erlaubt). Sie beginnen immer mit einer öffnenden Klammer (, enden mit einer schließenden Klammer ) und müssen mindestens eine Kennzeichnung enthalten. Mehrere Kennzeichnungen werden durch das Zeichen | getrennt. Jede Kennzeichnungen kann optional einen Wert enthalten, der von der Kennzeichnung durch das Zeichen = getrennt wird. Kennzeichennamen und -werte können beliebige Zeichenketten sein, sie dürfen allerdings keine der der besonderen Zeichen ) | = enthalten. Symbolnamen, die einer Kennzeichnungsspezifikation folgen, können optional mit den Zeichen ' oder " zitiert werden, um Leerzeichen darin zu erlauben. Falls keine Kennzeichnungen für das Symbol spezifiziert sind, werden Zitatzeichen als Teil des Symbolnamens behandelt, der bis zum ersten Leerzeichen geht.(Kennz1=bin markiert|Name mit Leerraum)"zitiertes gekennz Symbol"@Base 1.0
(optional)gekennzeichnet_unzitiertes_Symbol@Base 1.0 1
ungekennzeichnetes_Symbol@Base 1.0 Das erste Symbol im Beispiel heißt zitiertes gekennz Symbol und hat zwei Kennzeichnungen: Kennz1 mit dem Wert bin markiert und Name mit Leerraum ohne Wert. Das zweite Symbol heißt gekennzeichnet_unzitiertes_Symbol und ist nur mit dem Kennzeichen namens optional gekennzeichnet. Das letzte Symbol ist ein Beispiel eines normalen, nicht gekennzeichneten Symbols. Da Symbolkennzeichnungen eine Erweiterung des Formats deb-symbols(5) sind, können sie nur Teil der in Quellpaketen verwandten Symboldateien sein (diese Dateien sollten dann als Vorlagen zum Bau der Symboldateien, die in Binärpakete eingebettet werden, gesehen werden). Wenn dpkg-gensymbols ohne die Option -t aufgerufen wird, wird es alle Symbole ausgeben, die zum Format deb-symbols(5) kompatibel sind: Es verarbeitet die Symbole entsprechend der Anforderungen ihrer Standardkennzeichnungen und entfernt alle Kennzeichnungen aus der Ausgabe. Im Gegensatz dazu werden alle Symbole und ihre Kennzeichnungen (sowohl die Standardkennzeichnungen als auch die unbekannten) im Vorlagenmodus ( -t) in der Ausgabe beibehalten und in ihrer Originalform wie sie geladen wurden auch geschrieben.
Standard-Symbolkennzeichnungen¶
- optional
- Ein als »optional« gekennzeichnetes Symbol kann
jederzeit von der Bibliothek verschwinden und wird nie zum Fehlschlag von
dpkg-gensymbols führen. Verschwundene optionale Symbole werden
kontinuierlich als MISSING (Fehlend) in dem Diff in jeder neuen
Paketversion auftauchen. Dieses Verhalten dient als Erinnerung für
den Betreuer, dass so ein Symbol aus der Symboldatei entfernt oder wieder
der Bibliothek hinzugefügt werden muss. Wenn das optionale Symbol,
dass bisher als MISSING bezeichnet gewesen war, plötzlich in der
nächsten Version wieder auftaucht, wird es wieder auf den Status
»existing« (existierend) gebracht, wobei die minimale Version
unverändert bleibt.
- arch=Architekturliste
- Die Markierung erlaubt es, den Satz an Architekturen
einzugrenzen, auf denen das Symbol existieren sollte. Wenn die Symbolliste
mit den in der Bibliothek entdeckten Symbolen aktualisiert wird, werden
alle architekturspezifischen Symbole, die nicht auf die aktuelle
Host-Architektur passen, so behandelt, als ob sie nicht existierten. Falls
ein architekturspezifisches Symbol, das auf die aktuelle Host-Architektur
passt, in der Bibliothek nicht existiert, werden die normalen Regeln
für fehlende Symbole angewandt und dpkg-gensymbols könnte
dadurch fehlschlagen. Auf der anderen Seite, falls das
architekturspezifische Symbol gefunden wurde, wenn es nicht existieren
sollte (da die aktuelle Host-Architektur nicht in der Markierung
aufgeführt ist), wird sie architekturneutral gemacht (d.h. die
Architekturmarkierung wird entfernt und das Symbol wird im Diff aufgrund
dieser Änderung auftauchen), aber es wird nicht als neu betrachtet.
(arch=alpha any-amd64 ia64)a_64bit_specific_symbol@Base 1.0
(arch=linux-any)linux_specific_symbol@Base 1.0
(arch=!armel)symbol_armel_does_not_have@Base 1.0
- ignore-blacklist
- dpkg-gensymbols verfügt über eine interne Ausschußliste (»blacklist«) von Symbolen, die nicht in Symboldateien auftauchen sollten, da sie normalerweise nur Seiteneffekte von Implementierungsdetails in der Werkzeugkette darstellen. Falls Sie aus irgendeinem Grund wollen, dass diese Symbole in der Symboldatei aufgenommen werden, sollten Sie das Symbol mit ignore-blacklist kennzeichnen. Dies kann für einige grundlegende Bibliotheken der Werkzeugkette wie libgcc notwendig sein.
- c++
- Gibt c++-Symbolmuster an. Lesen Sie den Unterabschnitt Verwendung von Symbolmuster unten.
- symver
- Gibt symver (Symbolversion)-Symbolmuster an. Lesen Sie den Unterabschnitt Verwendung von Symbolmuster unten.
- regex
- Gibt regex-Symbolmuster an. Lesen Sie den Unterabschnitt Verwendung von Symbolmuster unten.
Verwendung von Symbolmustern¶
Anders als die Standardsymbolspezifikation kann ein Muster mehrere reale Symbole aus der Bibliothek abdecken. dpkg-gensymbols wird versuchen, jedes Muster auf jedes reale Symbol, für das kein spezifisches Symbolgegenstück in der Symboldatei definiert ist, zu passen. Wann immer das erste passende Muster gefunden wurde, werden alle Kennzeichnungen und Eigenschaften als Basisspezifikation des Symbols verwandt. Falls keines der Muster passt, wird das Symbol als neu betrachtet.- 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.
[?]
(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.
(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
(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.
(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:
- •
- Die Include-Direktive kann auch wie jedes Symbol
gekennzeichnet werden:
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
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).
OPTIONEN¶
- -PPaketbauverzeichnis
- Suche nach Paketbauverzeichnis statt nach debian/tmp.
- -pPaket
- Definiert den Paketnamen. Benötigt, falls mehr als ein binäres Paket in debian/control aufgeführt ist (oder falls es keine Datei debian/control gibt).
- -vVersion
- Definiert die Paketversion. Standardmäßig wird eie Version aus debian/changelog ausgelesen. Benötigt, falls der Aufruf außerhalb des Quellpaketbaums erfolgt.
- -eBibliotheksdatei
- Nur die explizit aufgeführten Bibliotheken untersuchen statt alle öffentlichen Bibliotheken zu finden. Sie können Shell-Muster, die zur Expansion von Pfadnamen verwandt werden (siehe die Handbuchseite File::Glob für weitere Details) in Bibliotheksdatei verwenden, um mehrere Bibliotheken mit einem einzelnen Argument zu passen (andernfalls benötigen Sie mehrere -e).
- -IDateiname
- Verwende Dateiname als Referenzdatei, um die Symboldatei zu erstellen, die dann im Paket selbst integriert wird.
- -O
- Gebe die erstellte Symboldatei in die Standardausgabe aus statt sie im Paketbaubaum zu speichern.
- -ODateiname
- Speichere die erstellte Symboldatei unter Dateiname. Falls Dateiname bereits existiert, wird deren Inhalt als Grundlage für die erstellte Symboldatei verwandt. Sie können diese Funktionalität benutzen, um eine Symboldatei zu aktualisieren, so dass sie zu einer neueren Version der Originalautoren Ihrer Bibliothek passt.
- -t
- Schreibe die Symboldatei im Vorlagenmodus statt im zu deb-symbols(5) kompatiblen Format. Der Hauptunterschied besteht darin, dass im Vorlagenmodus die Symbolnamen und Kennzeichnungen in ihrer Originalform geschrieben werden, im Gegensatz zu den verarbeiteten Symbolnamen mit entfernen Kennzeichnungen im Kompatibilitätsmodus. Desweiteren könnten einige Symbole beim Schreiben einer Standard deb-symbols(5)-Datei entfernt werden (gemäß der Verarbeitungsregeln für Kennzeichen), während in der Symboldateivorlage immer alle Symbole geschrieben werden.
- -c[0-4]
- Definiert die Prüfungen, die beim Vergleich der
erstellten Symboldatei mit der Vorlagendatei als Startpunkt erfolgen
sollen. Standardardstufe ist 1. Zunehmende Stufen führen mehr
Prüfungen durch und enthalten alle Prüfungen der niedrigeren
Stufen. Stufe 0 schlägt nie fehl. Stufe 1 schlägt fehl, wenn
einige Symbole verschwunden sind. Stufe 2 schlägt fehlt, falls einige
neue Symbole eingeführt wurden. Stufe 3 schlägt fehl, falls
einige Bibliotheken verschwunden sind. Stufe 4 schlägt fehl, falls
einige Bibliotheken hinzugekommen sind.
- -q
- Ruhig verhalten und nie einen Diff zwischen der erstellten Symboldatei und der als Startpunkt verwandten Vorlagendatei erstellen oder keine Warnungen bezüglich neuer/verlorender Bibliotheken oder neuer/verlorender Symbole ausgeben. Diese Option deaktiviert nur die informative Ausgabe aber nicht die Prüfungen selbst (sehen Sie hierzu die Option -c).
- -aArchitektur
- Nehme Arch als Host-Architektur beim Verarbeiten der Symboldateien an. Verwenden Sie diese Option, um Symboldateien oder Diffs für beliebige Architekturen zu erstellen, vorausgesetzt, die Binärprogramme sind bereits verfügbar.
- -d
- Debug-Modus aktivieren. Eine Vielzahl von Nachrichten wird angezeigt, um zu erklären, was dpkg-gensymbols durchführt.
- -V
- Ausführlichen Modus aktivieren. Die erstellte Symboldatei enthält veraltete Symbole als Kommentare. Im Vorlagenmodus werden Mustersymbole desweiteren von Kommentaren gefolgt, die die echten Symbole aufführen, die auf dieses Muster passen.
- -?, --help
- Zeige den Bedienungshinweis und beende.
- --version
- Gebe die Version aus und beende sich.
ÜBERSETZUNG¶
Die deutsche Übersetzung wurde 2004, 2006-2015 von Helge Kreutzmann <debian@helgefjell.de>, 2007 von Florian Rehnisch <eixman@gmx.de> und 2008 von Sven Joachim <svenjoac@gmx.de> angefertigt. Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 2 oder neuer für die Kopierbedingungen. Es gibt KEINE HAFTUNG.SIEHE AUCH¶
http://people.redhat.com/drepper/symbol-versioning2012-04-22 | Debian-Projekt |