# 6. Optimale Vorgehensweise beim Paketieren

Debians Qualität ist größtenteils den Debian-Richtlinien zu verdanken, die explizit grundlegende Anforderungen definieren, die alle Debian-Pakete erfüllen müssen. Außerdem stehen gemeinsame Erfahrungen im Paketieren aus der Vergangenheit hinter den Debian-Richtlinien. Viele sehr talentierte Leute haben großartige Werkzeuge geschaffen, Werkzeuge, die Ihnen als Debian-Betreuer helfen, ausgezeichnete Pakete zu erstellen und zu pflegen.

Dieses Kapitel stellt einige optimale Vorgehensweisen für Debian-Entwickler vor. Das alles sind lediglich Empfehlungen und keine Anforderungen oder feste Regeln. Es sind nur subjektive Hinweise, Ratschläge und Fingerzeige, die von Debian-Entwicklern gesammelt wurden. Suchen Sie sich einfach das heraus, was Ihnen am meisten zusagt.

## 6.1. Optimale Vorgehensweisen für `debian/rules`

Die folgenden Empfehlungen gelten für die Datei `debian/rules`. Da `debian/rules` den Build-Prozess steuert und die Dateien auswählt, die in das Paket gelangen (direkt oder indirekt), ist es normerweise die Datei, der die Betreuer die meiste Zeit widmen.

### 6.1.1. Helferskripte

Der Grund für die Benutzung von Helferskripten in `debian/rules` ist, dass sie den Betreuern eine gemeinsame allgemeine Logik inmitten vieler Pakete ermöglichen. Nehmen Sie zum Beispiel die Frage, wie Menü-Einträge installiert werden: Sie müssen die Datei in `/usr/share/menu` (oder `/usr/lib/menu` für ausführbare binäre Menü-Dateien, wenn nötig) ablegen und den Betreuerskripten Befehle hinzufügen, um Menü-Einträge zu registrieren bzw. ihre Registrierung zu entfernen. Dies ist eine sehr häufige Tätigkeit für Pakete. Warum sollte daher jeder Betreuer all dies für sich selbst neu schreiben und dabei möglicherweise Fehler verursachen? Außerdem, gesetzt den Fall, das Menü-Verzeichnis würde sich ändern, müsste dann jedes Paket geändert werden.

Helferskripte kümmern sich um diese Probleme. Angenommen, Sie erfüllen alle Gepflogenheiten, die das Helferskript erwartet, dann kümmert sich das Helferskript um alle Einzelheiten. Änderungen an den Richtlinien können im Helferskript erledigt werden. Dann müssen Pakete nur mit der neuen Version des Helferskripts erstellt und sonst nicht geändert werden.

Überblick über die Werkzeuge der Debian-Betreuer enthält ein paar verschiedene Helferskripte. Das gängigste und beste Helfersystem (nach Meinung von Debian) ist `debhelper`. Frühere Helfersysteme wie `debmake` waren monolithisch. Man konnte nicht einen Teil des Helferskripts herausgreifen und verwenden, den man nützlich fand, sondern musste den Helfer für alles benutzen. `debhelper` besteht jedoch aus mehreren getrennten kleinen `dh_*`-Programmen. `dh_installman` installiert und komprimiert zum Beispiel Handbuchseiten, `dh_installmenu` installiert Menü-Dateien und so weiter. Daher bietet es eine ausreichende Flexibilität, die kleinen Helferskripte dort zu benutzen, wo sie nützlich sind, in Verbindung mit handgemachten Befehlen in `debian/rules`.

Sie können mit `debhelper` beginnen, indem Sie debhelper(7) lesen und sich die Beispiele ansehen, die dem Paket beigefügt sind. `dh_make` aus dem Paket `dh-make` (siehe dh-make) kann benutzt werden, um ein einfaches Quellpaket in ein mit `debhelper` bearbeitetes Paket umzuwandeln. Gleichwohl sollte diese Kurzform Sie jedoch nicht davon überzeugen, dass Sie sich nicht plagen müssen, um die einzelnen `dh_*`-Helfer zu verstehen. Falls Sie einen Helfer benutzen möchten, müssen Sie sich die Zeit nehmen zu lernen, wie dieser Helfer benutzt wird, um zu verstehen, was er erwartet und wie er sich verhält.

### 6.1.2. Pakete mit mehreren Binärdateien

Ein einzelnes Quellpaket erstellt häufig mehrere Binärpakete, entweder um mehrere Varianten derselben Software bereitzustellen ( siehe z. B. das `vim`-Quellpaket) oder um mehrere kleine Pakete anstelle eines großem zu erstellen (z. B. damit der Benutzer sich nur die benötigte Teilmenge an Paketen installieren kann die der er benötigt, und dadurch auch Speicherplatz spart siehe z. B. das Quellpaket `libxml2`).

Der zweite Fall kann einfach in `debian/rules` verwaltet werden. Sie müssen nur die entsprechenden Dateien aus dem Build-Verzeichnis in die entsprechenden temporären Baumstrukturen des Pakets verschieben. Dies können Sie mit `install` oder `dh_install` aus `debhelper` erledigen. Sorgen Sie dafür, dass Sie die unterschiedlichen Umsetzungen der verschiedenen Pakete prüfen, um sicherzustellen, dass Sie die wechselseitigen Abhängigkeiten in `debian/control` richtig gesetzt haben.

Der erste Fall ist etwas schwieriger, da er mehrmaliges Neukompilieren der selben Software einschließt, aber mit unterschiedlichen Konfigurationsoptionen. Das `vim`-Quellpaket ist ein Beispiel dafür, wie dies mit einer handgemachten `debian/rules`-Datei gemacht wird.

## 6.2. Optimale Vorgehensweisen für `debian/control`

Die folgenden Vorgehensweisen sind maßgeblich für die Datei `debian/control`. Sie ergänzen die Richtlinien für Paketbeschreibungen.

Die Beschreibung des Pakets, wie es durch das entsprechende Feld in der Datei `control` definiert wird, enthält sowohl die Paketübersicht als auch die ausführliche Beschreibung des Pakets. Allgemeine Leitlinien für Paketbeschreibungen beschreibt übliche Richtlinien für beide Teile der Paketbeschreibung. Diesen folgend stellt Die Paketübersicht oder Kurzbeschreibung Richtlinien speziell für die Übersicht bereit und Die ausführliche Beschreibung enthält spezielle Richtlinien für die Beschreibung.

### 6.2.1. Der Paketname

Der Paketname:

- Muss mit weitreichend etablierten Konventionen übereinstimmen, z.B.

  - C- und C++-Bibliotheken enthalten typischerweise den Präfix lib

  - Paketnamen für viele weitere Sprachen beginnen oder enden mit dem Namen der Sprache (die konkrete Konvention hängt von der Sprache ab).

- Sollte kein verbreitetes, ungeeignetes Wort sein. Insbesondere Wörter, die eine ganze Klasse von Applications repräsentieren (z.B. reader, browser) sollten für virtuelle Pakete reserviert sein.

- Sollte im Idealfall mindestens 4 Zeichen lang sein, außer der Upstream Name ist kürzer und das Projekt ist bereits weitgehend bekannt unter dem Namen (z.B. fzf).

### 6.2.2. Allgemeine Leitlinien für Paketbeschreibungen

Die Paketbeschreibung sollte für den erwarteten Durchschnittsanwender geschrieben werden, der Durchschnittsperson, die das Paket benutzt und davon profitiert. Entwicklungspakete sind beispielsweise für Entwickler und können in einer technischen Sprache verfasst werden. Anwendungen für allgemeinere Zwecke, wie Editoren, sollten für Anwender mit weniger technischem Verständnis geschrieben werden.

Die Durchsicht der Paketbeschreibungen mündet in der Schlussfolgerung, dass die meisten Paketbeschreibungen technischer Natur sind, also nicht so geschrieben, dass sie für Anwender ohne technischen Hintergrund einen Sinn ergeben. Sofern Ihr Paket nicht wirklich für technikkundige Anwender gedacht ist, ist dies ein Problem.

Wie können sie für nicht technikkundige Anwender schreiben? Vermeiden Sie Fachsprache. Vermeiden Sie, sich auf Anwendungen und Rahmenwerke zu beziehen, mit denen der Anwender möglicherweise nicht vertraut ist – GNOME oder KDE sind in Ordnung, da Anwender wahrscheinlich mit diesen Begriffen vertraut sind, aber GTK vermutlich nicht. Versuchen Sie nicht irgendein Wissen vorauszusetzen, geben Sie eine Einführung.

Seien Sie objektiv. Paketbeschreibungen sind nicht der richtige Ort, um Ihr Paket anzupreisen, egal wie sehr Sie es mögen. Denken Sie daran, dass der Leser nicht die gleichen Dinge als wichtig ansieht wie Sie.

Bezüge zu Namen anderer Softwarepakete, Protokollnamen, Standards oder Spezifikationen sollten, falls sie existiert, in ihrer vorschriftsmäßigen Form verwandt werden. Benutzen Sie zum Beispiel X Window System, X11 oder X, nicht X Windows, X-Windows, or X Window. Benutzen Sie GTK, nicht GTK+ oder gtk. Benutzen Sie GNOME, nicht Gnome. Benutzen Sie PostScript, nicht Postscript oder postscript.

Falls Sie Probleme beim Verfassen Ihrer Beschreibung haben, könnten Sie sie an `debian-l10n-english@lists.debian.org` senden und um Rückmeldung ersuchen.

### 6.2.3. Die Paketübersicht oder Kurzbeschreibung

Die Richtlinie legt fest, dass die Übersichtszeile (die Kurzbeschreibung) kurz sein muss, den Paketnamen nicht wiederholen darf, aber trotzdem informativ sein muss.

Die Übersichtsfunktionen sind ein Ausdruck, der das Paket beschreibt, kein kompletter Satz, daher ist Zeichensetzung unangebracht: Es wird weder eine besondere Großschreibung noch ein abschließender Punkt benötigt. Außerdem sollten jegliche bestimmten und unbestimmten Artikel am Anfang weggelassen werden – "a", "an" oder "the". Deshalb zum Beispiel:

    Package: libeg0
    Description: exemplification support library

Technisch gesehen ist dies eine Nominalphrase im Gegensatz zu einer Verbalphrase. Eine gute Entscheidungsregel ist, dass es möglich sein sollte, den Paket-Namen und die Übersicht in diesem Schema zu ersetzen:

Das Paket Name stellt {ein,eine,den,einige} Übersicht zur Verfügung.

Zusammenstellungen verwandter Pakete können ein alternatives Schema benutzen, das die Übersicht in zwei Teile unterteilt, als erstes eine Beschreibung der ganzen Suite und als zweites eine Zusammenfassung der Rolle, die das Paket darin spielt:

    Package: eg-tools
    Description: simple exemplification system (utilities)

    Package: eg-doc
    Description: simple exemplification system - documentation

Diese Übersicht folgt einem geänderten Schema. Wo ein Paket "Name" die Übersicht "Suite (Rolle)" oder "Suite - Rolle" hat, sollten die Elemente so ausgedrückt werden, dass sie in dieses Schema passen:

Das Paket Name stellt {ein,eine,die} Rolle für die Suite zur Verfügung.

### 6.2.4. Die ausführliche Beschreibung

Die ausführliche Beschreibung ist die wichtigste für den Benutzer verfügbare Information über ein Paket, bevor er es installiert. Sie sollte alle nötigen Informationen bereitstellen, damit der Anwender entscheiden kann, ob er das Paket installieren möchte. Es ist anzunehmen, dass der Benutzer bereits die Paketübersicht gelesen hat.

Die ausführliche Beschreibung sollte aus vollständigen Sätzen bestehen.

Der erste Absatz der ausführlichen Beschreibung sollte die folgenden Fragen beantworten: Was tut das Paket? Bei welchen Aufgaben hilft es dem Anwender? Es ist wichtig, dies auf eine nicht technische Weise zu beschreiben, sogar dann, wenn die Zielgruppe des Pakets notwendigerweise einen technischen Hintergrund hat.

Lange Beschreibungen verwandter Pakete, die beispielsweise aus derselben Quelle erstellt wurden, können Absätze gemeinsam nutzen, um die Konsistenz zu erhöhen und den Arbeitsaufwand für Übersetzer zu verringern. Sie benötigen jedoch mindestens einen separaten Absatz, der die spezifische Rolle des Pakets beschreibt.

Die folgenden Absätze sollten die folgenden Fragen beantworten: Warum benötige ich als Benutzer dieses Paket? Welche anderen Funktionen bietet das Paket? Welche herausragenden Funktionen und Mängel gibt es im Vergleich zu anderen Paketen (z.B. falls Sie X benötigen, benutzen Sie Y)? Steht das Paket in einem Zusammenhang mit anderen Paketen, die nicht vom Paketmanager gehandhabt werden (z.B. ist dies der Client für den Foo-Server)?

Seien Sie vorsichtig, um Rechtschreib- und Grammatikfehler zu vermeiden. Sorgen Sie für eine Rechtschreibprüfung. Sowohl `ispell` als auch `aspell` haben spezielle Modi zur Prüfung von `debian/control`-Dateien:

    ispell -d american -g debian/control

    aspell -d en -D -c debian/control

Anwender erwarten normalerweise, dass diese Fragen in der Paketbeschreibung beantwortet werden:

- Was tut das Paket? Falls es eine Erweiterung eines anderen Pakets ist, dann sollte eines Kurzbeschreibung des Pakets, das es erweitert, hier eingefügt werden.

- Warum sollte ich dieses Paket wollen? Dies bezieht sich auf das vorhergehende, aber nicht das gleiche (dies ist ein Mail-Client. Er ist toll, schnell, hat Schnittstellen zu PGP, LDAP und IMAP, hat die Funktionen X, Y und Z).

- Falls dieses Paket nicht direkt installiert werden sollte, sondern von einem anderen Paket mitinstalliert wird, sollte dies erwähnt werden.

- Falls das Paket `experimental` ist oder es andere Gründe gibt, weshalb es nicht benutzt werden sollte und wenn es andere Pakete gibt, die stattdessen benutzt werden sollen, sollte dies auch hier stehen.

- Was unterscheidet dieses Paket von der Konkurrenz? Ist es eine bessere Implementierung? Mehr Funktionen? Andere Funktionen? Warum sollte die Wahl auf dieses Paket fallen?

### 6.2.5. Homepage der Originalautoren

Es wird empfohlen, dass Sie die URL der Homepage des Pakets in das Feld `Homepage` im Abschnitt `Source` von `debian/control` hinzufügen. Diese Information in die Paketbeschreibung selbst einzutragen, wird als nicht erwünscht angesehen.

### 6.2.6. Ort des Versionsverwaltungssystems

Es gibt zusätzliche Felder für den Ort des Versionsverwaltungssystems in `debian/control`.

#### 6.2.6.1. Vcs-Browser

Der Wert dieses Feldes sollte eine `https://`-URL sein, die auf eine via Webbrowser zu durchsuchende Kopie des Versionsverwaltungssystem-Repositorys verweist, das benutzt wird, um das angegebene Paket zu verwalten, falls verfügbar.

Die Information ist dazu gedacht, dem Endanwender zu helfen, diese Ressource aufzurufen um die letzte am Paket geleistete Arbeit durchstöbern zu können (z.B. wenn nach einem Patch gesucht wird, der einen Fehler behebt, der in der Fehlerdatenbank als `pending` gekennzeichnet ist).

#### 6.2.6.2. Vcs-*

Der Wert dieses Feldes sollte eine Zeichenkette sein, die den Ort des Versionsverwaltungssystem-Repositorys eindeutig identifiziert, das zur Verwaltung des angegebenen Pakets benutzt wird, falls verfügbar. `*` identifiziert das Versionsverwaltungssystem. Aktuell werden vom Paketverfolgungssystem die folgenden Typen unterstützt: `arch`, `bzr` (Bazaar), `cvs`, `darcs`, `git`, `hg` (Mercurial), `mtn` (Monotone) und `svn` (Subversion).

Die Information ist für Benutzer bestimmt, die im gegebenen Versionsverwaltungssystem sachkundig sind und bereit, die aktuelle Version des Pakets aus den VCS-Quellen zu erstellen. Andere Nutzungen dieser Information könnten das automatische Erstellen der letzten VCS-Version des Pakets umfassen. Dazu sollte der vom Feld angegebene Ort versionsunabhängig sein und auf den Hauptzweig (main branch) zeigen (bei Versionsverwaltungssystemen, die dieses Konzept unterstützen). Außerdem sollte der Endanwender auf den Ort zugreifen können, auf den verwiesen wird. Die Erfüllung dieser Anforderungen könnte einen anonymen Zugriff voraussetzen, statt auf eine Version mit SSH-Zugriff zu verweisen.

Im folgendem Beispiel wird eine Instanz des Felds für ein Git-Repository des `vim`-Pakets angezeigt. Beachten Sie, dass die URL das `https://`- Schema (anstelle von `ssh://`) benutzt. Die Verwendung der Felder `Vcs-Browser` und `Homepage` wird ebenfalls gezeigt, wie oben beschrieben.

    Source: vim
    <snip>
    Vcs-Git: https://salsa.debian.org/vim-team/vim.git
    Vcs-Browser: https://salsa.debian.org/vim-team/vim
    Homepage: https://www.vim.org

Das Verwalten der Paketierung in einem Versionskontrollsystem und das Festlegen eines Vcs-*-Headers ist eine bewährte Vorgehensweise und erleichtert anderen das Einbringen von Änderungen.

Fast alle Pakete in Debian, die ein Versionskontrollsystem verwenden, verwenden Git. Wenn Sie ein neues Paket erstellen, ist die Verwendung von Git eine gute Idee, einfach weil es das System ist, mit dem die Mitwirkenden vertraut sind.

DEP-14 definiert ein allgemein gültiges Layout für Debian Pakete.

## 6.3. Optimale Vorgehensweisen für `debian/changelog`

Die folgenden Vorgehensweisen ergänzen die Richtlinien für Änderungsprotokolldateien.

### 6.3.1. Verfassen nützlicher Änderungsprotokolleinträge

Der Änderungsprotokolleintrag (Changelog) einer Paketüberarbeitung dokumentiert Änderungen der aktuellen Version, und nur diese. Der Schwerpunkt liegt auf der Beschreibung bedeutender und für den Anwender sichtbarer Änderungen, die seit der letzten Version vorgenommen wurden.

Der Fokus liegt darauf, was geändert wurde – wer, wie und wann ist normalerweise nicht so wichtig. Erinnern Sie gleichwohl höflich an die Leute, die merklich Hilfe beim Erstellen des Pakets geleistet haben (die z.B. Patches gesandt haben).

Es ist nicht nötig, belanglose und offensichtliche Änderungen näher auszuführen. Sie können außerdem mehrere Änderungen in einem Eintrag zusammenfassen. Fassen Sie sich andererseits nicht zu kurz, falls Sie eine größere Änderung vorgenommen haben. Stellen Sie insbesondere klar, falls es Änderungen gibt, die das Verhalten des Programms ändern. Benutzen Sie für weitere Erklärungen die Datei `README.Debian`.

Benutzen Sie geläufiges Englisch, so dass die Mehrheit der Leser es begreifen kann. Vermeiden Sie Abkürzungen, technische Begriffe und Fachsprache, wenn Sie Änderungen erklären, die Fehlerberichte schließen, insbesondere bei Fehlern die von Anwendern eingereicht wurden, die Ihnen als technisch unerfahren aufgefallen sind. Seien Sie höflich, fluchen Sie nicht.

Manchmal ist es wünschenswert, den Änderungsprotokolleinträgen die Namen der Dateien voranstellen, die geändert wurden. Es ist jedoch nicht nötig, explizit jede einzelne geänderte Datei aufzuführen, insbesondere dann nicht, wenn die Änderung klein oder wiederholend war. Sie können Platzhalter verwenden.

Treffen Sie keine Annahmen wenn Sie sich auf Fehler beziehen. Sagen Sie welches Problem vorlag, wie es behoben wurde und hängen Sie die Zeichenkette "closes: #nnnnn" an. Weitere Informationen erhalten Sie unter Wann Fehler durch neue Uploads geschlossen werden.

### 6.3.2. Auswahl Dringlichkeit des Uploads

Das Release-Team hat angegeben, dass sie erwarten, dass die meisten Uploads nach `unstable` die Dringlichkeit urgency=medium verwenden. Deshalb sollten Sie urgency=medium benutzen, es sei denn, es gibt spezielle Gründe, dass der Upload schneller oder langsamer nach `testing` migrieren soll (Siehe auch:ref:testing-unstable). Beispielsweise können Sie urgency=low nehmen, falls die Änderungen seit dem letzten Upload sehr umfangreiche oder disruptive, unerwartete Änderungen enthalten.

Die Verzögerungen betragen derzeit je nach Dringlichkeit (hoch, mittel oder niedrig) 2, 5 oder 10 Tage. Die tatsächlichen Zahlen werden durch die „Britney-Konfiguration <https://release.debian.org/britney/britney.conf>“__ gesteuert, die auch beschleunigte Migrationen umfasst, wenn der Autopkgtest erfolgreich ist.

### 6.3.3. Häufige Missverständnisse über Änderungsprotokolleinträge

Die Änderungsprotokolleinträge sollten keine allgemeinen Paketierungsthemen dokumentieren (Hey, falls Sie die Foo.conf suchen, die ist in /etc/blah/.), da von Administratoren und Anwendern angenommen wird, dass sie zumindest entfernt damit vertraut sind, wie solche Dinge im Allgemeinen auf Debian-Systemen eingerichtet sind. Erwähnen Sie jedoch, wenn Sie den Ort einer Konfigurationsdatei ändern.

Die einzigen Fehler, die mit einem Änderungsprotokolleintrag geschlossen werden, sollten Fehler sein, die tatsächlich in der gleichen Überarbeitung des Pakets behoben werden. Das Schließen von Fehlern ohne Bezug dazu, ist eine falsche Vorgehensweise. Siehe Wann Fehler durch neue Uploads geschlossen werden.

Die Änderungsprotokolleinträge sollten nicht für zufällige Diskussionen mit Leuten, die Fehler melden (Ich kann keine Schutzverletzungen sehen, wenn ich Foo mit der Option Bar starte. Senden Sie weitere Informationen.), allgemeine Äußerungen über das Leben, das Universum und alles mögliche (Entschuldigung, dass der Upload so lange brauchte, aber ich hatte die Grippe.) oder Hilfeersuchen (Die Fehlerliste für dieses Paket ist riesig, bitte packen Sie mit an) benutzt werden. Solche Dinge werden normalerweise nicht von Ihrer Zielgruppe bemerkt, könnten aber viele Leute stören, die Informationen über tatsächliche Änderungen am Paket lesen möchten. Weitere Informationen über die Benutzung der Fehlerdatenbank finden Sie unter Auf Fehler antworten.

Es ist ein alter Brauch, im ersten regulären Upload des Paketbetreuers das Beheben von Fehlern durch Non-Maintainer-Uploads zu bestätigen. Da Debian nun über eine Versionsverwaltung verfügt, reicht es aus, die NMU-Änderungsprotokolleinträge zu erhalten und diese Tatsache nur in Ihrem eigenen Änderungsprotokolleintrag zu erwähnen.

### 6.3.4. Häufige Fehler in Änderungsprotokolleinträgen

Die folgenden Beispiele demonstrieren einige häufige Fehler oder Beispiele für schlechten Stil in Änderungsprotokolleinträgen.

    * Fixed all outstanding bugs.

Dies teilt den Lesern offensichtlich nichts Nützliches mit.

    * Applied patch from Jane Random.

Was war das für ein Patch?

    * Late night install target overhaul.

Welche Korrektur wurde ausgeführt? Soll die Erwähnung der späten Nacht daran erinnern, dass man dem Code nicht trauen sollte?

    * Fix vsync fw glitch w/ ancient CRTs.

Hier werden zu viele Akronyme benutzt! Was bedeuted "fw", eventuell "firmware"? Und es ist nicht allzu klar, worum es bei dem Fehler tatsächlich ging oder wie er behoben wurde.

    * This is not a bug, closes: #nnnnnn.

Erst einmal ist es absolut unnötig, das Paket hochzuladen, um diese Information zu übermitteln. Benutzen Sie stattdessen die Fehlerdatenbank. Zweitens fehlt die Erklärung, warum dieser Bericht kein Fehler ist.

    * Has been fixed for ages, but I forgot to close; closes: #54321.

Falls Sie aus irgend einem Grund die Fehlernummer in einem früheren Änderungsprotokolleintrag nicht erwähnt haben, ist das kein Problem. Schließen Sie den Fehler einfach im BTS. Es ist nicht nötig, die Änderungsprotokolldatei anzufassen, vorausgesetzt, die Beschreibung der Fehlerbehebung ist bereits darin enthalten (dies gilt auch für Korrekturen durch die Originalautoren/-Betreuer. Sie müssen keine Fehler verfolgen, die diese bereits vor Jahren in Ihrem Änderungsprotokoll behoben haben).

    * Closes: #12345, #12346, #15432

Wo ist die Beschreibung? Falls Ihnen keine aussagekräftige Nachricht einfällt, beginnen Sie damit, die Titel der verschiedenen Fehler einzufügen.

### 6.3.5. Änderungsprotokolle mit `NEWS.Debian`-Dateien ergänzen

Wichtige Nachrichten über Änderungen in einem Paket können auch in die `NEWS.Debian`-Dateien geschrieben werden. Die Nachrichten werden durch Werkzeuge wie `apt-listchanges` vor dem ganzen Rest des Änderungsprotokolls angezeigt. Dies ist das bevorzugte Mittel, dem Anwender bedeutende Änderungen in einem Paket mitzuteilen. Es ist besser, als `debconf`-Notizen zu benutzen, da es weniger stört und der Anwender nach der Installation zurückgehen und in der `NEWS.Debian`-Datei nachschlagen kann. Es ist auch besser, als die Hauptänderungen in `README.Debian` aufzuführen, da der Anwender solche Notizen leicht übersehen kann.

Das Dateiformat entspricht dem des Änderungsprotokolls, die Sternchen werden allerdings weggelassen und jedes Nachrichtenelement wird, wenn nötig, mit einem vollständigen Satz beschrieben, statt der kurz gefassten Zusammenfassungen, die in ein Änderungsprotokoll einfließen. Sie sind gut beraten, Ihre Datei durch `dpkg-parsechangelog` laufen zu lassen, um die Formatierung zu prüfen, da sie nicht automatisch während des Builds getestet wird, so wie dies beim Änderungsprotokoll geschieht. Hier nun ein Beispiel einer echten `NEWS.Debian`-Datei:

    cron (3.0pl1-74) unstable; urgency=low

        The checksecurity script is no longer included with the cron package:
        it now has its own package, checksecurity. If you liked the
        functionality provided with that script, please install the new
        package.

     -- Steve Greenland <stevegr@debian.org>  Sat,  6 Sep 2003 17:15:03 -0500

Die Datei `NEWS.Debian` wird als `/usr/share/doc/`Paket`/NEWS.Debian.gz` installiert. Sie ist komprimiert und hat immer diesen Namen, auch in nativen Debian-Paketen. Falls Sie `debhelper` benutzen, wird `dh_installchangelogs` die `debian/NEWS`-Dateien für Sie installieren.

Anders als Änderungsprotokolldateien müssen Sie die `debian/NEWS`-Dateien nicht bei jeder Veröffentlichung aktualisieren. Aktualisieren Sie diese nur, wenn Sie etwas besonders berichtenswertes haben, worüber der Anwender Bescheid wissen sollte. Falls Sie überhaupt keine Nachrichten haben, ist es nicht nötig, Ihrem Paket eine `debian/NEWS`-Datei mitzugeben. Keine Nachricht ist eine gute Nachricht!

## 6.4. Optimale Vorgehensweisen rund um Sicherheit

Wenn ein Upstream-Projekt eine kryptografische Signatur für jedes neue Release veröffentlicht, sollten Sie `uscan` zur automatischen Verifizierung der Signatur einrichten. Für Details lesen Sie den Abschnitt über `Update source location: "debian/watch"` in dem Debian Policy Manual.

https://wiki.debian.org/Hardening enthält Vorschläge wie ein ausführbares Programm gebaut werden kann, so dass es in Bezug auf Sicherheit gehärtet ist.

## 6.5. Optimale Vorgehensweisen für Betreuerskripte

Zu den Betreuerskripten gehören die Dateien `debian/postinst`, `debian/preinst`, `debian/prerm` und `debian/postrm`. Diese Skripte kümmern sich um die Paketeinrichtung bei jeder Installation oder Deinstallation des Pakets, bei dem es nicht ausreicht, nur die Dateien und Verzeichnisse zu erstellen oder zu entfernen. Die folgenden Anweisungen ergänzen die Debian Policy.

Betreuerskripte müssen idempotent sein. Das bedeutet, dass Sie sicherstellen müssen, dass nichts Schlimmes passiert, wenn das Skript zweimal aufgerufen wird, während es normalerweise nur einmal aufgerufen würde.

Standardein- und -ausgabe könnten zu Protokollierungszwecken umgeleitet werden (z.B. in Pipes), verlassen Sie sich daher nicht darauf, dass dies auf einem Terminal ausgegeben werden.

Jegliche Bedienerführung oder interaktive Konfiguration sollte so gering wie möglich gehalten werden. Wenn es nötig ist, sollten Sie das Paket `debconf` für die Schnittstelle benutzen. Denken Sie daran, dass diese Bedienerführung nur in der `configure`-Stufe des `postinst`-Skripts stattfinden kann.

Halten Sie die Betreuerskripte so einfach wie möglich. Es wird empfohlen, nur reine POSIX-Shell-Skripte zu benutzen. Falls Sie irgendwelche Bash-Funktionen benötigen, vergessen Sie nicht, dass das Betreuerskript eine Shebang-Zeile haben muss. POSIX-Shell oder Bash werden für Perl bevorzugt, da sie `debhelper` ermöglichen, den Skripten einfach Teile hinzuzufügen.

Falls Sie Ihre Betreuerskripte ändern, stellen Sie sicher, dass Sie das Entfernen des Pakets, die mehrmalige Installation und das vollständige Entfernen testen. Vergewissern Sie sich, dass nach dem vollständigen Entfernen des Pakets alles komplett gelöscht ist, sprich es muss jede Datei entfernt sein, die direkt oder indirekt in irgendeinem Betreuerskript erstellt wurde.

Falls Sie prüfen möchten, ob ein Befehl existiert, sollten Sie z.B. so etwas benutzen

    if command -v install-docs > /dev/null; then ...

Sie können diese Funktion benutzen, um `$PATH` nach einem Befehlsnamen zu durchsuchen, der als Argument übergeben wird. Sie gibt "true" (null) zurück, falls der Befehl gefunden wurde und "false" falls nicht. Dies ist wirklich die am ehesten portierbare Möglichkeit, da `command -v` ein Shell-Builtin für viele Shells ist und im POSIX-Standard definiert ist.

Das Benutzen von `which` ist eine akzeptable Alternative da es im erforderlichen Paket `debianutils` enthalten ist.

## 6.6. Konfigurationsverwaltung mit `debconf`

`Debconf` ist ein Konfigurationsverwaltungssystem, das von allerlei Paketierungsskripten (hauptsächlich `postinst`) benutzt werden kann, um Rückmeldungen von Anwendern betreffend der Paketkonfiguration abzufragen. Direkte Benutzer-Interaktion muss nun zugunsten der Interaktion mit `debconf` vermieden werden, damit in Zukunft nicht interaktive Installationen möglich sind.

Debconf ist ein großartiges Werkzeug, aber es wird oft mangelhaft benutzt. Viele alltägliche Fehler sind auf der Handbuchseite debconf-devel(7) aufgeführt. Sie sollten sie lesen, falls Sie sich entscheiden debconf zu benutzen. Außerdem werden hier ein paar optimale Vorgehensweisen vorgestellt.

Diese Leitlinien enthalten einige Empfehlungen für Schreibstil und Typografie, allgemeine Betrachtungen über die Benutzung von debconf sowie spezifischere Empfehlungen für einige Teile der Distribution (das Installationssystem beispielsweise).

### 6.6.1. Missbrauchen Sie debconf nicht

Seit debconf in Debian erschien, wurde es öfter missbraucht und viel von der Kritik, die bei der Debian-Distribution einging, rührte vom debconf-Missbrauch her und bemängelte die Notwendigkeit, ein großes Fragenbündel beantworten zu müssen, bevor eine Kleinigkeit installiert war.

Lassen Sie Hinweise zur Benutzung der Software dort wozu sie gehören: In den Dateien `NEWS.Debian` oder `README.Debian`. Benutzen Sie debconf-Meldungen nur für wichtige Anmerkungen die direkt die Benutzbarkeit des Pakets betreffen. Bedenken Sie, dass diese die Installation immer blockieren bis diese bestätigt wurden, oder Sie belästigen den Anwender per E-Mail.

Wählen Sie die Prioritäten der Fragen in Betreuerskripten sorgfältig. Einzelheiten über Prioritäten finden Sie unter debconf-devel 7. Die meisten Fragen sollten mittlere oder niedrige Prioritäten nutzen.

### 6.6.2. Allgemeine Empfehlungen für Autoren und Übersetzer

#### 6.6.2.1. Schreiben Sie korrektes Englisch

Die meisten Debian-Paketbetreuer haben nicht Englisch als Muttersprache. Daher ist es für sie nicht einfach, korrekt formulierte Vorlagen zu verfassen.

Bitte benutzen (und missbrauchen) Sie die Mailingliste `debian-l10n-english@lists.debian.org`. Lassen Sie Ihre Vorlagen dort Korrekturlesen.

Schlecht geschriebene Vorlagen werfen ein armseliges Bild auf Ihr Paket, Ihre Arbeit ... oder sogar auf Debian selbst.

Vermeiden Sie soweit möglich technische Fachsprache. Auch wenn sich einige Begriffe für Sie vertraut anhören, könnten sie für andere unverständlich sein. Falls sie sich nicht vermeiden lassen, versuchen Sie diese zu erklären (benutzen Sie die erweiterte Beschreibung). Versuchen Sie dabei, zwischen Aussagekraft und Einfachheit abzuwägen.

#### 6.6.2.2. Seien Sie freundlich zu Übersetzern

Debconf-Vorlagen können übersetzt werden. Debconf bietet zusammen mit seinem Schwesterpaket `po-debconf` ein einfaches Werkzeug, um Vorlagen durch Übersetzer-Teams oder sogar einzelne Personen übersetzen zu lassen.

Bitte benutzen Sie Gettext-basierte Vorlagen. Installieren Sie `po-debconf` auf Ihrem Entwicklungssystem und lesen Sie dessen Dokumentation (`man po-debconf` ist ein guter Anfang).

Vermeiden Sie es, Vorlagen häufig zu ändern. Das Ändern von Vorlagen führt zu Mehrarbeit für Übersetzer, deren Übersetzungen unvollständig werden. Eine unvollständige Übersetzung ist eine Zeichenkette, bei der sich seit dem Übersetzen das Original geändert hat und das daher eine Aktualisierung durch den Übersetzer benötigt. Wenn die Änderungen klein genug sind, wird die Originalübersetzung in den PO-Dateien beibehalten, jedoch mit `fuzzy` gekennzeichnet.

Falls Sie planen, Änderungen an Ihren Originalvorlagen vorzunehmen, benutzen Sie bitte das Benachrichtigungssystem namens `podebconf-report-po`, das vom Paket `po-debconf` bereitgestellt wird, um die Übersetzer zu kontaktieren. Die meisten aktiven Übersetzer sind sehr zugänglich, und deren Arbeit zusammen mit Ihren geänderten Vorlagen einzubeziehen, wird Sie vor zusätzlichen Uploads bewahren. Falls Sie Gettext-basierte Vorlagen verwenden, werden die Namen und E-Mail-Adressen der Übersetzer in den Kopfzeilen der PO-Dateien erwähnt und von `podebconf-report-po` benutzt.

Ein empfohlene Art, das Hilfswerkzeug zu benutzen ist:

    cd debian/po && podebconf-report-po --call --languageteam --withtranslators --deadline="+10 days"

Dieser Befehl wird zuerst die PO- und POT-Dateien in `debian/po` mit den in `debian/po/POTFILES.in` aufgeführten Vorlagendateien synchronisieren. Dann wird er einen Aufruf für neue Übersetzungen an die Mailingliste `debian-i18n@lists.debian.org` senden. Am Schluss wird er außerdem einen Aufruf für neue Übersetzungen an das Sprach-Team (im Feld `Language-Team` jeder PO-Datei erwähnt), sowie den letzten Übersetzer (aus `Last-Translator`) senden.

Es wird immer gewürdigt, wenn Sie den Übersetzern einen Abgabetermin nennen, so dass diese ihre Arbeit organisieren können. Bitte denken Sie daran, dass einige Übersetzer-Teams einen formalisierten Übersetzungs-/Korrekturprozess haben und eine Zeitspanne, die kürzer als zehn Tage ist, als unangemessen angesehen wird. Eine kürzere Frist übt zuviel Druck auf die Übersetzer-Teams aus und sollte nur für sehr kleine Änderungen gewählt werden.

Im Zweifelsfall können Sie auch das Übersetzer-Team für eine bestimmte Sprache (debian-l10n-xxxxx@lists.debian.org) oder die Mailingliste `debian-i18n@lists.debian.org` kontaktieren.

#### 6.6.2.3. Entfernen Sie die fuzzy-Markierungen in vollständigen Übersetzungen, wenn Sie Tipp- und Rechtschreibfehler korrigieren

Wenn der Text einer Debconf-Vorlage korrigiert wurde und Sie sicher sind, dass die Änderung keine Übersetzungen beeinflusst, seien Sie so nett zu den Übersetzern, die fuzzy-Markierungen aus deren Übersetzungen zu entfernen.

Falls Sie dies nicht tun, wird die ganze Vorlage nicht übersetzt sein, bis Ihnen ein Übersetzer eine Aktualisierung zusendet.

Um die fuzzy-Markierungen aus Übersetzungen zu entfernen, können Sie `msguntypot` benutzen (Teil des Pakets `po4a`).

1. Erzeugen Sie die POT- und PO-Dateien neu.

       debconf-updatepo

2. Erstellen Sie eine Kopie der POT-Datei.

       cp templates.pot templates.pot.orig

3. Erstellen Sie eine Kopie aller PO-Dateien.

       mkdir po_fridge; cp *.po po_fridge

4. Ändern Sie die Debconf-Vorlagedateien, um den Tippfehler zu korrigieren.

5. Erzeugen Sie die POT- und PO-Dateien (wieder) neu.

       debconf-updatepo

   An dieser Stelle markiert die Korrektur des Tippfehlers alle Übersetzungen mit "fuzzy" und diese unglückliche Änderung ist die einzige zwischen den PO-Dateien Ihres Hauptverzeichnisses und denen aus fridge. Hier nun eine Erklärung, wie das gelöst wird.

6. Verwerfen Sie die mit "fuzzy" markierte Übersetzung und stellen Sie die aus fridge wieder her.

       cp po_fridge/*.po .

7. Führen Sie manuell die PO-Dateien mit der neuen POT-Datei zusammen, unter Berücksichtigung/Vermeidung des nutzlosen "fuzzy".

       msguntypot -o templates.pot.orig -n templates.pot *.po

8. Räumen Sie auf.

       rm -rf templates.pot.orig po_fridge

#### 6.6.2.4. Treffen Sie keine Annahmen über Schnittstellen

Vorlagentexte sollten keinen Bezug zu Steuerelementen herstellen, die zu irgendwelchen Debconf-Schnittstellen gehören. Sätze wie Wenn Sie mit Ja antworten... haben keinen Sinn für Benutzer grafischer Oberflächen, weil dort bei logischen Fragen Kontrollkästchen angehakt werden.

Zeichenkettenvorlagen sollten außerdem vermeiden, Vorgabewerte in ihrer Beschreibung zu erwähnen. Erstens sind diese zusätzlich zu den Werten, die der Anwender sieht, vorhanden. Außerdem könnten sich diese Werte von der Auswahl des Paketbetreuers unterscheiden (zum Beispiel, wenn die Debconf-Datenbank voreingestellt ist).

Versuchen Sie, allgemein ausgedrückt, Bezug auf Benutzeraktionen zu vermeiden. Geben Sie nur Tatsachen wieder.

#### 6.6.2.5. Reden Sie nicht in der ersten Person

Sie sollten vermeiden, in der ersten Person zu reden (Ich werde das tun... oder Wir empfehlen...). Der Rechner ist keine Person und die Debconf-Vorlagen sprechen nicht stellvertretend für Debian-Entwickler. Sie sollten neutrale Formulierungen benutzen. Diejenigen unter Ihnen, die bereits wissenschaftliche Publikationen verfasst haben, können ihre Vorlagen so schreiben, als würden Sie wissenschaftliche Papiere verfassen. Versuchen Sie jedoch, wenn möglich eine aktive Anrede zu verwenden, wie Aktivieren Sie dies, wenn ... anstelle von Dies kann aktiviert werden, wenn....

#### 6.6.2.6. Formulieren Sie geschlechtsneutral

Um unser Bekenntnis zu unserem Diversity Statement zu zeigen, verwenden Sie bitte in Ihren Texten geschlechtergerechte Formulierungen, indem Sie Pronomen wie "Er" oder "Sie" vermeiden, wenn Sie auf eine Aufgabenrolle (wie zum Beispiel Betreuer) Bezug nehmen.

### 6.6.3. Definition von Vorlagenfeldern

Dieser Teil stellt einige Informationen bereit, die überwiegend von der Handbuchseite debconf-devel(7) übernommen wurden.

#### 6.6.3.1. Typen

##### 6.6.3.1.1. string

Resultiert in einem Eingabefeld freier Form, in das der Benutzer jegliche Zeichenkette eingeben kann.

##### 6.6.3.1.2. password

Gibt dem Benutzer eine Eingabeaufforderung für ein Passwort aus. Benutzen Sie dies mit Vorsicht. Vergegenwärtigen Sie sich, dass das Passwort das der Benutzer eingibt in die Debconf-Datenbank geschrieben wird. Sie sollten diesen Wert möglicherweise aus der Datenbank löschen, sobald dies möglich ist.

##### 6.6.3.1.3. boolean

Eine Auswahl "wahr/falsch". Denken Sie daran: true/false, nicht yes/no ...

##### 6.6.3.1.4. select

Eine Auswahl aus mehreren Werten. Die Auswahlmöglichkeiten müssen in einem "Choices" benannten Feld angegeben werden. Trennen Sie die möglichen Werte mit Komma und Leerzeichen, wie hier: `Choices: yes, no, maybe`.

Falls Auswahlmöglichkeiten übersetzbare Zeichenketten sind, kann das Feld durch Benutzung von `__Choices` als übersetzbar gekennzeichnet werden. Der doppelte Unterstrich wird jede Auswahl in eine separate Zeichenkette heraus trennen.

Das System `po-debconf` bietet außerdem interessante Möglichkeiten, um nur einige Auswahlmöglichkeiten als übersetzbar zu kennzeichnen. Ein Beispiel:

    Template: foo/bar
    Type: Select
    #flag:translate:3
    __Choices: PAL, SECAM, Other
    _Description: TV standard:
     Please choose the TV standard used in your country.

In diesem Beispiel ist nur die Zeichenkette "Other" übersetzbar, während das andere Abkürzungen sind, die nicht übersetzt werden sollten. Obiges ermöglicht, dass nur "Other" in die POT- und PO-Dateien eingefügt wird.

Das Schaltersystem der Debconf-Vorlagen bietet viele solcher Möglichkeiten. Die Handbuchseite po-debconf(7) führt all diese Möglichkeiten auf.

##### 6.6.3.1.5. multiselect

Wie der Datentyp "select", außer dass der Benutzer eine beliebige Anzahl von Elementen aus der Auswahlliste auswählen kann (oder gar keins).

##### 6.6.3.1.6. note

Statt per se als Frage stellt dieser Datentyp einen Hinweis dar, der dem Benutzer angezeigt werden kann. Er sollte nur für wichtige Anmerkungen benutzt werden, die der Benutzer wirklich sehen sollte, weil debconf großen Aufwand betreibt, um sicherzustellen, dass der Benutzer sie wahrnimmt; die Installation wird gestoppt, bis der Benutzer eine Taste drückt, in manchen Fällen bekommt er sogar eine Benachrichtigung per E-Mail.

##### 6.6.3.1.7. text

Dieser Typ wird nun als veraltet angesehen: Benutzen Sie ihn nicht.

##### 6.6.3.1.8. error

Dieser Typ wurde für Fehlermeldungen entworfen. Er ist dem Typ "note" am ähnlichsten. Oberflächen könnten ihn unterschiedlich anzeigen (die Oberfläche von Cdebconf zeichnet beispielsweise einen roten statt des üblichen blauen Bildschirms).

Es wird empfohlen, diesen Typ für jegliche Nachricht zu verwenden, die die Aufmerksamkeit des Anwenders für irgendeine Art von Korrektur auf sich ziehen muss.

#### 6.6.3.2. Description: Kurze und erweiterte Beschreibung

Vorlagenbeschreibungen haben zwei Teile: kurz und erweitert. Die Kurzbeschreibung steht in der Zeile "Description:" der Vorlage.

Die Kurzbeschreibung sollte knapp gehalten werden (ungefähr 50 Zeichen), so dass sie in den meisten debconf-Schnittstellen untergebracht werden kann. Es hilft obendrein Übersetzern, wenn sie kurz gehalten wird, da Übersetzungen normalerweise dazu neigen, länger als das Original zu sein.

Die Kurzbeschreibung sollte für sich allein stehen können. Einige Schnittstellen zeigen die ausführliche Beschreibung standardmäßig nicht an, oder nur, wenn der Benutzer explizit danach fragt, oder eventuell wird sie gar nicht angezeigt. Vermeiden Sie so was wie "Was möchten Sie tun?"

Die Kurzbeschreibung muss nicht notwendigerweise aus einem vollständigen Satz bestehen. Dies ist Teil der Forderung nach kurzen, brauchbaren Empfehlungen.

Die erweiterte Beschreibung sollte die Kurzbeschreibung nicht Wort für Wort wiederholen. Falls Ihnen keine ausführliche Beschreibung einfällt, denken Sie zuerst etwas darüber nach. Schreiben Sie an debian-devel. Bitten Sie um Hilfe. Nehmen Sie Schreibunterricht! Diese erweiterte Beschreibung ist wichtig. Falls Sie nach allem noch immer nicht damit zurecht kommen, lassen Sie sie leer.

Die erweiterte Beschreibung sollte in ganzen Sätzen verfasst sein. Absätze sollten kurz gehalten werden, um die Leserlichkeit zu verbessern. Vermischen Sie nicht zwei Ideen in einem Absatz, sondern benutzen Sie lieber einen anderen Absatz.

Seien Sie nicht zu gesprächig. Benutzer tendieren dazu, zu ausführliche Bildschirminhalte zu ignorieren. 20 Zeilen sind erfahrungsgemäß die Grenze, die Sie nicht überschreiten sollten, da dies bedeutet, dass Anwender klassische Dialogfenster nicht scrollen müssen und viele Leute tun das einfach nicht.

Die erweiterte Beschreibung sollte keine Frage enthalten.

Um etwas über besondere Regeln zu erfahren, die vom Vorlagentyp (string, boolean etc.) abhängen, lesen Sie das Folgende.

#### 6.6.3.3. Choices

Dieses Feld sollte für "select"- und "multiselect"-Typen verwandt werden. Es enthält die Auswahlmöglichkeiten, die dem Benutzer angezeigt werden. Die Auswahlmöglichkeiten sollten durch Komma getrennt werden.

#### 6.6.3.4. Default

Dieses Feld ist optional. Es enthält die vorausgewählte Antwort für die "string"-, "select"- und "multiselect"-Vorlagen. Für "multiselect"-Vorlagen könnte es eine durch Komma getrennte Auswahlliste enthalten.

### 6.6.4. Gestaltungsrichtlinie für Vorlagenfelder

#### 6.6.4.1. Feld "Type"

Keine besondere Angabe außer: Benutzen Sie den geeigneten Typ bezogen auf den vorhergehenden Abschnitt.

#### 6.6.4.2. Feld "Description"

Es folgen spezifische Anweisungen für ordnungsgemäßes Verfassen der Beschreibung (kurz und erweitert), abhängig vom Vorlagentyp.

##### 6.6.4.2.1. "string"-/"password"-Vorlagen

- Die Kurzbeschreibung ist eine Abfrage und kein Titel. Vermeiden Sie den Fragestil (IP-Adresse?) und geben Sie offenen Abfragen (IP-Adresse:) den Vorzug. Es wird empfohlen, Doppelpunkte zu benutzen.

- Die erweiterte Beschreibung ist eine Ergänzung der Kurzbeschreibung. Im erweiterten Teil erklären Sie, was gefragt ist, anstatt die gleiche Frage in längerer Formulierung wieder zu stellen. Benutzen Sie ganze Sätze. Von knappem Schreibstil wird strikt abgeraten.

##### 6.6.4.2.2. "boolean"-Vorlagen

- Die Kurzbeschreibung sollte als Frage formuliert und kurz gehalten werden, und generell mit einem Fragezeichen enden. Kompakter Schreibstil ist erlaubt und sogar gewollt, falls die Frage eher lang ist. (Denken Sie daran, dass Übersetzungen oft länger als die Originalversionen sind.)

- Nochmals: Bitte vermeiden Sie, sich auf Schnittstellen-spezifische Dinge zu beziehen. Ein häufiger Fehler bei solchen Vorlagen ist, auf Ja-Typ-Konstruktionen zu antworten.

##### 6.6.4.2.3. "select"/"multiselect"

- Die Kurzbeschreibung ist eine Abfrage und kein Titel. Benutzen Sie keine nutzlosen "Bitte wählen Sie..."-Konstruktionen. Anwender sind klug genug, um herauszufinden, dass sie etwas auswählen sollen ... :)

- Die erweiterte Beschreibung wird die Kurzbeschreibung vervollständigen. Sie könnte sich auf die verfügbaren Auswahlmöglichkeiten beziehen. Sie könnte zudem erwähnen, dass der Anwender unter mehr als einer verfügbaren Auswahlmöglichkeit wählen kann, falls es sich um eine "multiselect"-Vorlage handelt.

##### 6.6.4.2.4. "notes"

- Die Kurzbeschreibung sollte als Titel betrachtet werden.

- Die erweiterte Beschreibung ist das, was als detaillierte Erklärung der Notiz angezeigt wird. Sätze, kein knapper Schreibstil.

- Missbrauchen Sie debconf nicht. Anmerkungen sind die häufigste Art, auf die debconf missbraucht wird. Wie steht doch in der Handbuchseite von debconf-devel(7) geschrieben: Es ist am Besten, dies nur für Warnungen über sehr ernsthafte Probleme zu benutzen. Die Dateien `NEWS.Debian` oder `README.Debian` sind für viele Notizen der passende Ort. Wenn Sie dies lesen, und darüber nachdenken, Ihre "notes" zu Einträgen in `NEWS.Debian` oder `README.Debian` umzuwandeln, bewahren Sie bitte dennoch Ihre existierenden Übersetzungen für die Zukunft auf.

#### 6.6.4.3. Das Feld "Choices"

Falls sich "Choices" zu oft ändert, sollten Sie in Betracht ziehen, zum __Choices-Trick zu greifen. Dies wird jede einzelne Auswahl in eine einzelne Zeichenkette aufteilen, was Übersetzern beträchtlich bei ihrer Arbeit helfen wird.

#### 6.6.4.4. Das Feld "Default"

Wenn der Standardwert für eine ausgewählte Vorlage wahrscheinlich von der Benutzersprache abhängt (z. B. wenn es sich bei der Auswahl um eine Sprachauswahl handelt), verwenden Sie bitte den in po-debconf 7 dokumentierten Trick _Default.

Dieses Spezialfeld ermöglicht Übersetzern, die am Besten zu ihrer Sprache passende Auswahl zu wählen. Der vom Übersetzer gewählte Standardeintrag wird verwendet, wenn deren Sprache benutzt wird, während Ihre eigene "Default"-Auswahl bei Englisch benutzt wird.

Verwenden Sie kein leeres Standardfeld. Wenn Sie keine Standardwerte verwenden möchten, verwenden Sie kein Feld "Default".

Falls Sie po-debconf benutzen (und das sollten Sie, lesen Sie Seien Sie freundlich zu Übersetzern), erwägen Sie, dieses Feld übersetzbar zu machen, wenn es nach Ihrer Meinung übersetzt werden könnte.

Ein Beispiel aus den Vorlagen des Pakets Geneweb:

    Template: geneweb/lang
    Type: select
    __Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv)
    # This is the default choice. Translators may put their own language here
    # instead of the default.
    # WARNING : you MUST use the ENGLISH NAME of your language
    # For instance, the French translator will need to put French (fr) here.
    _Default: English[ translators, please see comment in PO files]
    _Description: Geneweb default language:

Beachten Sie, dass die Benutzung von Klammern Kommentare in debconf-Feldern erlaubt. Beachten Sie außerdem, dass die Kommentare in den Dateien zu sehen sein werden, mit denen Übersetzer arbeiten.

Die Kommentare werden benötigt, da der _Default-Trick etwas verwirrend ist: Die Übersetzer können ihre eigene Wahl treffen.

## 6.7. Internationalisierung

Dieser Abschnitt enthält generelle Informationen, um Übersetzern die Arbeit zu erleichtern. Weitere Informationen für Übersetzer und Entwickler zum Thema Internationalisierung sind in der Dokumentation Internationalisierung und Lokalisierung verfügbar.

### 6.7.1. Handhabung von Debconf-Übersetzungen

Wie Portierer haben auch Übersetzer eine schwierige Aufgabe. Sie arbeiten an vielen Paketen und müssen mit vielen verschiedenen Paketbetreuern zusammenarbeiten, deren Muttersprache meist nicht Englisch ist. Sie sollten ihnen daher besondere Geduld entgegenbringen.

Das Ziel von `debconf` war die Vereinfachung der Paketkonfiguration für Betreuer und Anwender. Ursprünglich wurde die Übersetzung von Debconf-Vorlagen mit `debconf-mergetemplate` gehandhabt. Nun wird diese Technik jedoch missbilligt. Die Internationalisierung von `debconf` ist am besten mit dem Paket `po-debconf` zu erreichen. Diese Methode ist sowohl für Betreuer als auch für Übersetzer einfacher. Es werden Umwandlungsskripte bereitgestellt.

Wenn `po-debconf` benutzt wird, werden die Übersetzungen in `.po`-Dateien gespeichert (mit `gettext`-Übersetzungstechniken erstellt). Spezielle Vorlagendateien enthalten die Originalnachrichten und markieren, welche Felder übersetzbar sind. Wenn Sie den Wert eines übersetzbaren Feldes durch Aufruf von `debconf-updatepo` ändern, wird die Übersetzung für Übersetzer als aufmerksamkeitsbedürfend gekennzeichnet. Dann, während des Paketbaus, wird das Programm `dh_installdebconf` wie von Zauberhand dafür sorgen, dass alle Vorlagen zusammen mit den aktuellen Übersetzungen in die Binärpakete einfließen. Weitere Einzelheiten können Sie der Handbuchseite po-debconf(7) entnehmen.

### 6.7.2. Internationalisierte Dokumentation

Internationalisierte Dokumentation für Anwender ist wichtig, bereitet aber viel Mühe. Es gibt keine Möglichkeit, all diese Arbeit zu vermeiden, aber Sie können den Übersetzern einige Dinge erleichtern.

Falls Sie Dokumentationen in irgendwelchem Umfang betreuen, ist es für Übersetzer einfacher, wenn Sie Zugriff auf das Versionsverwaltungssystem haben. Dadurch können Übersetzer die Unterschiede zwischen zwei Versionen der Dokumentation anschauen, so dass sie beispielsweise sehen können, was neu übersetzt werden muss. Es wird empfohlen, dass die übersetzte Dokumentation eine Notiz darüber bereithält, auf welcher Revision des Quellcodes die Übersetzung basiert. Ein interessantes System wird von doc-check aus dem `debian-installer`-Paket bereitgestellt, das eine Übersicht über den Übersetzungsstatus für eine angegebene Sprache anzeigt. Dazu werden strukturierte Kommentare für die aktuelle Revision der zu übersetzenden Datei und für eine übersetzte Datei die Revision des Originals auf der die Übersetzung basiert, angezeigt. Möglicherweise möchten Sie dies anpassen und in Ihrem VCS-Bereich bereitstellen.

Falls Sie XML- oder SGML-Dokumentationen betreuen, wird dazu empfohlen, dass Sie jegliche sprach-unabhängigen Informationen isolieren und diese als Entity in einer eigenen Datei definieren, die in allen verschiedenen Übersetzungen enthalten ist. Dies macht es beispielsweise viel einfacher, URLs über mehrere Dateien hinweg aktuell zu halten.

Einige Werkzeuge (z.B. `po4a`, `poxml` oder `translate-toolkit`) sind darauf spezialisiert, übersetzbares Material aus verschiedenen Formaten zu extrahieren. Sie erstellen PO-Dateien, ein für Übersetzer übliches Format, das eine Übersicht darüber gibt, was übersetzt werden muss, wenn das übersetzte Dokument aktualisiert wurde.

## 6.8. Optimale Vorgehensweisen für `debian/patches`

Debian Pakete können Fehler aus dem Originalcode enthalten, um die Sie sich kümmern müssen. In dem Quellformat "3.0 (quilt)" werden Patches unterhalb von `debian/patches/` gespeichert. Beim Auspacken des Quellpakets werden die Patches automatisch angewendet, so wie in `debian/patches/series` gelistet.

Patches sollten nach DEP-3 dokumentiert werden.

Es gibt einige Werkzeuge um das Verwalten von Patches zu automatisieren. Wenn Sie ein Quellpaket außerhalb eines Git-Repositories pflegen, dann ist wahrscheinlich `quilt` Ihre beste Option. Ansonsten sollten Sie überlegen sich auf die eingebauten Features von Git oder die Git-Paketierungs-Helfer zu verlassen, die Sie ggf. verwenden. Insbesondere wenn Sie `git-buildpackage` für Pakete verwenden, sollten Sie die `gbp pq`-Kommandos verwenden um den Inhalt des Verzeichnisses `debian/patches/` zu verwalten.

Ein einzelner Patch kann z.B. per `git format-patch -1 d33286c` aus einem einzelnen Commit erstellt werden. Sie sollten git show nicht verwenden, da nicht der kompletter Header angezeigt wird.

Wenn die Fehlerkorrektur Upstream über mehrere Commits aufgeteilt ist, aber in Debian als einzelner Patch angewandt (und ausgeschlossen) werden soll, kann etwa der Befehl `git format-patch --stdout abc123..def456 > debian/patches/...` verwendet werden und das Feld `Bug` nur in der Commit-Message des ersten Commits im Patch hinzugefügt werden.

Wenn die Endung .patch zu der URL eines Commits oder Pull Requests bei GitHub oder eines Commits oder Merge Requests bei GitLab angehängt wird, verwendet die resultierende Patch-Datei das gleiche Format (als wäre sie mit `git format-patch` erstellt worden).

Denken Sie immer daran einen `Bug`-Header an die Patch-Beschreibung anzuhängen, so dass ein Leser dem Link folgen kann um zu sehen wo ein Fehler berichtet oder ein Patch eingereicht wurde. Wenn der Patch dafür da ist, um anhaltend von Upstream abzuweichen, hängen Sie den Header Forwarded: not-needed ans Ende der Beschreibung an.

## 6.9. Häufig vorkommende Paketierungssituationen

### 6.9.1. Pakete benutzen `autoconf`/`automake`

Die Dateien `config.sub` und `config.guess` von `autoconf` aktuell zu halten ist für Portierer kritisch, insbesondere auf eher unbeständigen Architekturen. Einige sehr gute Paketierungsvorgehensweisen für jegliche Pakete, die `autoconf` und/oder `automake` benutzen, wurden in `/usr/share/doc/autotools-dev/README.Debian.gz` aus dem Paket `autotools-dev` zusammengefasst. Es wird eindringlich geraten, diese README-Datei und die folgenden Empfehlungen zu lesen.

### 6.9.2. Bibliotheken

Das Paketieren von Bibliotheken gestaltet sich fast immer schwierig und dies aus unterschiedlichen Gründen. Die Richtlinien verhängen mehrere Beschränkungen, um ihre Pflege zu erleichtern und sicherzustellen, dass Upgrades so einfach wie möglich sind, wenn eine neue Originalversion herauskommt. Eine kaputte Bibliothek kann dazu führen, dass Dutzende davon abhängige Pakete beschädigt werden.

Gute Vorgehensweisen für das Paketieren von Bibliotheken wurden in der Anleitung zum Paketieren von Bibliotheken zusammengefasst.

### 6.9.3. Dokumentation

Achten Sie darauf, dass Sie den Richtlinien für Dokumentation folgen.

Falls Ihr Paket Dokumentation enthält, die aus XML oder SGML erstellt wurde, wird empfohlen in den Binärpaket(en) nicht die XML- oder SGML-Quellen mitzuliefern. Falls Anwender den Quellcode der Dokumentation möchten, sollten sie das Quellpaket herunterladen.

Die Richtlinie gibt an, dass die Dokumentation im HTML-Format weitergegeben werden sollte. Außerdem wird empfohlen, die Dokumentation im PDF-Format und als Klartext mitzuliefern, falls geeignet und falls die Ausgabe in einer vernünftigen Qualität möglich ist. Es ist allgemein jedoch nicht angemessen, Klartextversionen von Dokumentationen mitzuliefern, deren Quellformat HTML ist.

Bedeutende mitgelieferte Handbücher sollten sich selbst bei der Installation mit `doc-base` registrieren. Weitere Einzelheiten erhalten Sie in der Dokumentation des Pakets `doc-base`.

Die Debian-Richtlinien (Abschnitt 12.1) schreiben vor, dass Handbuchseiten jedem Programm, jedem Hilfswerkzeug und jeder Funktion beiliegen sollten und für andere Objekte, wie Konfigurationsdateien, wird dies nahegelegt. Falls die von Ihnen paketierte Arbeit nicht über eine solche Handbuchseite verfügt, dann überlegen Sie sich, eine zu schreiben, die Ihrem Paket beigefügt und an die Originalautoren gesandt wird.

Die Handbuchseiten müssen nicht direkt im Troff-Format geschrieben werden. Beliebte Quellformate sind Docbook, POD und reST, die mit `xsltproc`, `pod2man` beziehungsweise `rst2man` umgewandelt werden können. In geringerem Maße kann außerdem das Programm `help2man` benutzt werden, um die Handbuchsseite rudimentär zu erstellen.

### 6.9.4. Besondere Pakettypen

Mehrere besondere Typen von Paketen haben spezielle Unter-Richtlinien und zugehörige Paketierungsregeln und Vorgehensweisen:

- Perl zugehörige Pakete haben eine Perl-Richtlinie. Einige Beispiele für Pakete, die dieser Richtlinie folgen, sind `libdbd-pg-perl` (binäres Perl-Modul) oder `libmldbm-perl` (architekturunabhängiges Perl-Modul).

- Python zugehörige Pakete haben ihre Python-Richtlinie. Siehe `/usr/share/doc/python/python-policy.txt.gz` im Paket `python`.

- Emacs zugehörige Pakete haben die Emacs-Richtlinie.

- Java zugehörige Pakete haben ihre Java-Richtlinie.

- OCaml zugehörige Pakete haben ihre eigene Richtlinie, die Sie unter `/usr/share/doc/ocaml/ocaml_packaging_policy.gz` im Paket `ocaml` finden können. Ein gutes Beispiel ist das Quellpaket `camlzip`.

- Pakete, die XML- oder SGML-DTDs bereitstellen, sollten konform zu den Empfehlungen im Paket `sgml-base-doc` sein.

- Lisp-Pakete sollten sich selbst mit `common-lisp-controller` registrieren. Siehe dazu `/usr/share/doc/common-lisp-controller/README.packaging`.

- Rust-Paketierung wird im Debian Rust Team Book beschrieben.

- Pakete, die Services ("daemons") zur Verfügung stellen, sollten auf einem frisch installierten System funktionieren, insofern als das möglich ist ohne Sicherheit einzubüßen (z.B. sollte ein Webserver standardmäßig laufen und eine Beispielseite ausliefern, darf aber trotzdem keine unauthentifizierten sensitiven Operationen erlauben; Sie sollten überlegen, ob standardmäßig Seiten nur über das localhost Netzwerkinterface ausgeliefert werden).

- Web-Application-Pakete sollten darauf abzielen, ihre Abhängigkeiten (inklusive javascript) separat paketiert zu haben, und sollten notwendiges Setup für einen sicheren Basis-Betrieb ausführen (z.B. eine Datenbank anlegen, Konfigurationsdateien mit sicheren Standardeinstellungen ausliefern, Dateien an dem angebrachten Ort mit angebrachten Rechten installieren, etc). Als Beispiele können bestehende Pakete von Web-Applications herangezogen werden, z.B. dfsg-new-queue für Go, gitlab für ruby on rails, node-shiny-server für NPM. diaspora-installer ist ein Pseudopaket, welches diaspora herunterlädt (ebenso alle Laufzeit-Abhängigkeiten per rubygems) und es konfiguriert PostgreSQL und Nginx zu benutzen.

### 6.9.5. Architekturunabhängige Daten

Es ist unüblich größere Mengen an architekturunabhängiger Daten gemeinsam mit einem Programm zu paketieren. Als Beispiel hierzu seien Audiodateien, eine Symbolsammlung, Hintergrundmuster oder grafische Dateien genannt. Falls die Größe dieser Daten jedoch vernachlässigbar im Vergleich zum Rest des Pakets ist, ist es wahrscheinlich am besten, alles innerhalb eines einzelnen Paket zu paketieren.

Ist die Größe allerdings beachtlich, denken Sie darüber nach, sie in ein separates architekturunabhängiges Paket (`_all.deb`) auszulagern. Indem Sie dies tun, vermeiden Sie die im Prinzip unötige Vervielfältigung der gleichen Daten in zehn oder mehr .debs, eines pro Architektur! Obwohl dies einigen zusätzlichen Overhead zu den `Packages`-Dateien verursacht, spart es viel Plattenplatz auf den Debian-Spiegelservern. Das Heraus trennen architekturunabhängiger Daten vermindert auch die Ausführungszeit von `lintian` (siehe Lint-Werkzeuge für Pakete), wenn es für das ganze Debian-Archiv ausgeführt wird.

### 6.9.6. Eine bestimmte Locale wird während des Paketbaus benötigt

Falls Sie eine bestimmte Locale während des Baus benötigen, können Sie mittels dieses Tricks eine temporäre Datei erstellen:

Falls Sie `LOCPATH` auf die Entsprechung von `/usr/lib/locale` und `LC_ALL` auf den Namen der Locale setzen, die sie generieren, sollten Sie erreichen, was Sie möchten, ohne dass Sie Root sind. Etwas wie:

    LOCALE_PATH=debian/tmpdir/usr/lib/locale
    LOCALE_NAME=en_IN
    LOCALE_CHARSET=UTF-8

    mkdir -p $LOCALE_PATH
    localedef -i $LOCALE_NAME.$LOCALE_CHARSET -f $LOCALE_CHARSET $LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET

    # Using the locale
    LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date

### 6.9.7. Machen Sie Übergangspakete deborphan-konform

Deborphan ist ein Programm, das Anwendern hilft, Pakete aufzuspüren, die sicher vom System entfernt werden können, d.h. diejenigen, von denen keine Pakete abhängen. Die Standardoperation ist, nur innerhalb der Abschnitte "libs" und "oldlibs" zu suchen, um Jagd auf unbenutzte Bibliotheken zu machen. Wenn aber das richtige Argument übergeben wird, versucht es auch, andere nutzlose Pakete zu erkennen.

Mit `--guess-dummy` versucht``deborphan`` beispielsweise, alle Übergangspakete zu durchsuchen, die für ein Upgrade benötigt wurden, aber jetzt entfernt werden können. Hierzu wird derzeit in der Kurzbeschreibung nach der Zeichenkette `dummy` oder `transitional` gesucht. Es ist jedoch besser, nach beiden Zeichenketten zu suchen, da es einige Dummy- oder Übergangspakete gibt, die anderen Zwecken dienen.

Wenn Sie also solch ein Paket erstellen, achten Sie bitte darauf den Text `transitional dummy package` in der Kurzbeschreibung zu verwenden. Um nach Beispielen zu suchen, führen Sie einfach `apt-cache search .|grep dummy` oder `apt-cache search .|grep transitional` aus.

Außerdem wird empfohlen, den Abschnitt in `oldlibs` und die Priorität in `optional` zu ändern, um die Arbeit von `deborphan` zu erleichtern.

### 6.9.8. Optimale Vorgehensweisen für `.orig.tar.{gz,bz2,xz}`-Dateien

Es gibt zwei Arten von Original-Quell-Tarballs: unberührten Quellcode und neu paketierten Quellcode der Originalautoren.

#### 6.9.8.1. Unberührter Quellcode

Das charakteristische Merkmal eines unberührten Tarballs ist, dass die `.orig.tar.{gz,bz2,xz}`-Datei Byte für Byte identisch mit einem offiziell weitergegebenen Tarball des Originalautors ist. [1] Dies ermöglicht die Benutzung von Prüfsummen, um auf einfache Weise alle Änderungen zwischen Debians Version und der der Originalautoren zu prüfen, die in der Diff-Datei in Debian enthalten sind. Falls außerdem der Originalquellcode riesig ist, können Originalautoren und andere, die bereits den Original-Tarball haben, Download-Zeit sparen, falls sie Ihre Paketierung im Detail inspizieren möchten.

Es gibt keine allgemein anerkannten Leitlinien, denen Originalautoren betreffend der Verzeichnisstruktur innerhalb ihres Tarballs folgen, aber `dpkg-source` ist dennoch in der Lage, mit den meisten Tarballs von Originalautoren als unberührtem Quellcode umzugehen. Seine Strategie entspricht dem Folgenden:

1. Es entpackt den Tarball in eine leeres temporäres Verzeichnis mittels

       zcat path/to/packagename_upstream-version.orig.tar.gz | tar xf -

2. Falls das temporäre Verzeichnis danach nur ein Verzeichnis und keine anderen Dateien enthält, benennt `dpkg-source` dieses Verzeichnis in Paketname`_`Originalversion`(.orig)` um. Der Name des Verzeichnisses auf der obersten Ebene im Tarball ist ohne Bedeutung und geht verloren.

3. Andernfalls muss der Tarball der Originalautoren ohne ein sonst übliches Verzeichnis der obersten Ebene gepackt worden sein (Schande über den Originalautor!). In diesem Fall benennt `dpkg-source` das temporäre Verzeichnis selbst in Paketname`_`Originalversion`(.orig)` um.

#### 6.9.8.2. Neu paketierter Originalquellcode

Sie sollten Pakete, wenn möglich, mit einem unberührten Quell-Tarball hochladen, aber es gibt viele Gründe, warum das manchmal nicht möglich ist. Dies ist der Fall, wenn die Originalautoren den Quellcode gar nicht als Gzip-gepackte Tar-Datei weitergeben oder falls der Tarball der Originalautoren nicht-DFSG-freies Material enthält, das Sie vor den Hochladen entfernen müssen.

In diesen Fällen muss der Entwickler selbst eine geeignete `.orig.tar.{gz,bz2,xz}`-Datei bauen. Solch einen Tarball nennen wir neu paketierten Originalquellcode. Beachten Sie, dass sich neu paketierter Originalquellcode von einem nativen Debian-Paket unterscheidet. Eine neu paketierte Quelle kommt mit Debian-spezifischen Änderungen in einem separaten `.diff.gz` oder `.debian.tar.{gz,bz2,xz}` daher und hat eine Versionsnummer, die sich aus der Originalversion und der Debian-version zusammensetzt.

Es könnte Gründe geben, aus denen es wünschenswert wäre, den Quellcode neu zu paketieren, obwohl die Originalautoren ein `.tar.{gz,bz2,xz}` verteilen, dass im Prinzip in seiner unberührten Form benutzt werden könnte. Der naheliegendste Grund ist, wenn signifikante Platzersparnis durch Neukomprimierung des Tar-Archivs oder Entfernen von wirklich nutzlosem Müll aus dem Qriginalarchiv erzielt werden kann. Handeln Sie hier nach eigenem Ermessen, aber seien Sie darauf vorbereitet, Ihre Entscheidung zu verteidigen, falls Sie einen Quellcode neu paketieren, der unberührt sein könnte.

Ein neu paketiertes `.orig.tar.{gz,bz2,xz}` Archiv

1. sollte im resultierenden Quellpaket dokumentiert werden. Detaillierte Informationen darüber, wie die neu gepackte Quelle erhalten wurde und wie diese reproduziert werden kann, sollten in `debian/copyright` bereitgestellt werden, idealerweise auf eine Weise, die automatisch mit uscan durchgeführt werden kann. Wenn das wirklich nicht funktioniert, stellen Sie zumindest ein `get-orig-source` Target in Ihrer `debian/rules` Datei bereit, das den Vorgang wiederholt, auch wenn dies in der Version 4.1.4 Debian Policy als veraltet markiert worden ist.

2. sollte keine Datei enthalten, die nicht von dem/den Originalautor(en) stammt oder deren Inhalt von Ihnen geändert wurde. [2]

3. sollte außer, wenn es aus rechtlichen Gründen unmöglich ist, die ganze Erstellungs- und Portierungsinfrastruktur aufbewahren, die vom Originalautor bereitgestellt wurde. Es ist zum Beispiel kein ausreichender Grund für das Weglassen einer Datei, wenn sie nur für die Erstellung unter MS-DOS benutzt wird. Gleichermaßen sollte ein `Makefile`, das vom Originalautor bereitgestellt wurde, nicht einmal dann weggelassen werden, wenn das erste, was Ihre `debian/rules` tut, das Überschreiben durch Ausführen eines Konfigurationsskripts ist.

   (Begründung: Es ist üblich für Debian-Anwender, die Software für nicht-Debian-Plattformen erstellen möchten, den Quellcode von einem Debian-Spiegel abzurufen, anstatt den Speicherort der ordnungsgemäßen Originaldistribution zu suchen).

4. sollte das Schema Paketname`-`Upstream-Version`+dfsg` (oder ein beliebiges Attributs-Suffix, das dem Tarball-Namen hinzugefügt wird) als Name für das Verzeichnis der obersten Ebene in seinem Tarball benutzen .

5. sollte mit `xz` (oder `gzip` oderr `bzip`) und mit der maximalen Komprimierung gepackt werden.

#### 6.9.8.3. Ändern binärer Dateien

Manchmal ist es nötig, binäre Dateien zu ändern, die im Original-Tarball enthalten sind oder binäre Dateien hinzuzufügen, die nicht darin enthalten sind. Dies wird vollständig unterstützt, wenn Sie Quellpakete im Format "3.0 (quilt)" benutzen. Lesen Sie die Handbuchseite dpkg-source(1), um weitere Einzelheiten zu erfahren. Wenn Sie das ältere Format "1.0" benutzen, können binäre Dateien nicht im `.diff.gz` gespeichert werden, daher müssen Sie eine mit `uuencode` (oder ähnlichem) kodierte Version der Datei(en) speichern und zur Erstellungszeit in `debian/rules` entschlüsseln (und an ihren offiziellen Platz verschieben).

### 6.9.9. Optimale Vorgehensweisen für Debug-Pakete

Ein Debug-Paket ist ein Paket, das zusätzliche Informationen enthält, die von `gdb` verwendet werden können. Da Debian diese Zusatzinformationen in Binärdateien standardmäßig entfernt, sind Debugging-Informationen wie Funktionsnamen und Zeilennummern dann nicht mehr verfügbar, wenn `gdb` auf Debian-Binärdateien ausgeführt wird. Mit Debug-Paketen können Benutzer, die diese zusätzlichen Debugging-Informationen benötigen, diese installieren, ohne ein reguläres System mit den in der Regel recht Speicherplatz intensiven Informationen aufzublähen.

Die Debug-Pakete enthalten separate Debugging-Symbole, die `gdb` beim Debuggen eines Programms oder einer Bibliothek im laufenden Betrieb finden und laden kann. Die Konvention in Debian besteht darin, diese Symbole in `/usr/lib/debug /`path abzulegen, wobei path der Pfad zur ausführbaren Datei oder Bibliothek ist. Zum Beispiel gehen Debugging-Symbole für `/usr/bin/foo` nach `/usr/lib/debug/usr/bin/foo` und Debugging-Symbole für `/usr/lib/libfoo.so.1` gehen nach `/usr/lib/debug/usr/lib/libfoo.so.1`.

#### 6.9.9.1. Automatisch erstellte Debug-Pakete

Debug-Symbolpakete können automatisch für jedes Binärpaket, das ausführbare Binärdateien enthält, generiert werden. Mit Ausnahme von Sonderfällen sollte es nicht mehr erforderlich sein, die alten manuell generierten zu verwenden. Der Paketname für ein automatisch generiertes Debug-Symbolpaket endet mit `-dbgsym`.

Die `dbgsym`-Pakete werden nicht in die regulären Archiven installiert, sondern in dedizierte Archive. Das heißt, wenn Sie die Debug-Symbole zum Debuggen benötigen, müssen Sie diese Archive zu Ihrer apt-Konfiguration hinzufügen und dann das entsprechende `dbgsym`-Paket installieren an dem Sie interessiert sind. Bitte lesen Sie https://wiki.debian.org/HowToGetABacktrace um mehr zu diesem Thema zu erfahren.

#### 6.9.9.2. Manuelle -dbg Pakete

Vor dem Aufkommen der automatischen `dbgsym`-Pakete mussten Debug-Pakete manuell generiert werden. Der Name eines manuellen Debug-Pakets endet auf `-dbg`. Es wird empfohlen solche alten Legacy-Pakete nach Möglichkeit auf die neuen `dbgsym`-Pakete zu migrieren. Das Verfahren zum Konvertieren Ihres Pakets ist unter https://wiki.debian.org/AutomaticDebugPackages beschrieben. Im Wesentlichen wird jedoch der Schalter `--dbgsym-migration = 'pkgname-dbg (<< currentversion~)'` durch den Befehl `dh_strip` verwendet.

Manchmal ist es jedoch nicht möglich auf die neuen `dbgsym`-Pakete zu konvertieren, oder Sie werden auf die alten manuellen `-dbg`-Pakete in den Archiven stoßen, sodass Sie sich möglicherweise mit ihnen befassen müssen. Es wird nicht empfohlen, manuelle -dbg-Pakete für neue Pakete zu erstellen, es sei denn, die automatische Erstellung funktioniert aus irgendeinem Grund nicht.

Ein Grund könnte sein, dass Debug-Pakete einen ganzen speziellen Debugging-Build einer Bibliothek oder einer anderen Binärdatei enthalten. Normalerweise reicht es jedoch aus, Debugging-Informationen von den bereits erstellten Binärdateien zu trennen, dies spart zusätzlich Platz und Erstellungszeit.

Dies ist beispielsweise der Fall bei Debugging-Symbolen von Python-Erweiterungen. Derzeit ist der richtige Weg, um Python-Erweiterungs-Debug-Symbole zu verpacken, die Verwendung von `-dbg`-Paketen, wie unter https://wiki.debian.org/Python/DbgBuilds beschrieben.

Um `-dbg`-Pakete erstellen zu können müssen diese explizit in der Datei `debian/control` aufgeführt werden.

Die Debugging-Symbole können mit `objcopy --only-keep-debug` aus einer Objektdatei extrahiert werden. Dann kann die Objektdatei entfernt und `objcopy --add-gnu-debuglink` verwendet werden, um den Pfad zur Debugging-Symboldatei anzugeben. objcopy 1 erklärt ausführlich, wie das funktioniert.

Beachten Sie, dass Debug-Pakete von dem Paket abhängen sollten, für das Sie Debugging-Symbole bereitstellen und diese Abhängigkeit sollte mit einer Version versehen werden. Zum Beispiel:

    Depends: libfoo (= ${binary:Version})

Der Befehl `dh_strip` in `debhelper` unterstützt das Erstellen von Debug-Paketen und kann die Benutzung von `objcopy` übernehmen, um die Debugging-Symbole für Sie zu filtern. Wenn Ihr Paket `debhelper/9.20151219` oder neuer verwendet, müssen Sie nichts zusätzliches tun. `debhelper` generiert Debug-Symbol-Pakete (mit dem Schema Paket`-dbgsym`) für Sie ohne zusätzliche Änderungen an Ihrem Quellpaket.

### 6.9.10. Optimale Vorgehensweisen für Meta-Pakete

Ein Meta-Paket ist meist ein leeres Paket, das es vereinfacht, eine Zusammenstellung von Paketen zu installieren, die sich im Lauf der Zeit weiterentwickeln können. Dies wird erreicht, indem das Metapaket von allen Paketen der Zusammenstellung abhängt. Dank der Fähigkeiten von APT kann der Betreuer des Meta-Pakets die Abhängigkeiten anpassen und das System des Anwenders wird automatisch die zusätzlichen Pakete erhalten. Die weggelassenen Pakete, die automatisch installiert wurden, werden außerdem als Kandidaten für das Entfernen gekennzeichnet (und werden sogar durch `aptitude` automatisch entfernt). `gnome` und `linux-image-amd64` sind zwei Beispiele für Meta-Pakete (gebaut durch die Quellpakete `meta-gnome2` und `linux-latest`).

Die ausführliche Beschreibung des Meta-Pakets muss dessen Zweck klar dokumentieren, so dass die Benutzer wissen was sie verlieren, wenn sie das Paket entfernen. Es wird empfohlen, genau über die Auswirkungen zu informieren. Dies ist besonders für Meta-Pakete wichtig, die während der anfänglichen Installation installiert werden und nicht explizit durch den Benutzer installiert wurden. Diese sind oft wichtig für das reibungslose Upgrade des Systems und der Benutzer sollte davon abgehalten werden, diese zu entfernen, um mögliche Schäden zu vermeiden.

[1]

Originalautoren können nicht daran gehindert werden, den von ihnen verteilten Tarball zu ändern, ohne die Versionsnummer zu erhöhen. Daher kann nicht gewährleistet werden, dass ein unberührter Tarball mit dem identisch ist, was die Originalautoren aktuell zu irgendeinem Zeitpunkt verteilen. Alles was erwartet werden kann, ist, dass es identisch mit etwas ist, das die Originalautoren einmal verteilt haben. Falls sich später ein Unterschied ergibt (etwa, wenn die Originalautoren merken, dass sie in ihrer Verteilung des Originals keine maximale Komprimierung nutzten und es dann erneut mit `gzip` packen), ist das einfach Pech. Da es keine brauchbare Möglichkeit gibt, ein neues `.orig.tar.{gz,bz2,xz}` für die gleiche Version hochzuladen, ist es sinnlos, dies als Fehler zu behandeln.

[2]

Als besondere Ausnahme könnte, falls das Auslassen unfreier Dateien dazu führen würde, dass das Build des Quellcodes ohne Unterstützung aus dem Debian-Diff fehlschlägt, das Bearbeiten der Dateien anstelle des Weglassens unfreier Teile davon und/oder Erklären der Situation in einer `README.source`-Datei im Wurzelverzeichnis des Quelltextes angemessen sein. Drängen Sie in diesem Fall aber den Originalautor dazu, die unfreien Komponenten leichter von dem restlichen Quelltext separierbar zu machen.