[[Vorlage(Getestet, jammy, noble)]] {{{#!vorlage Wissen [:Pakete_installieren: Installation von Programmen] [:Packprogramme: Archive entpacken] [:Editor: Dateien editieren] [:GnuPG: GnuPG-Schlüssel erstellen und verwalten] [:Makefile:Programme bauen mit `make`] }}} [[Inhaltsverzeichnis()]] Dieser Artikel vermittelt das Grundlagenwissen, welches für die Erstellung von Debian-Paketen notwendig ist. Mit dem Erstellen eigener Debian-Quellpakete ist es über den [:Launchpad/PPA:Launchpad]-Service möglich, selbsterstellte Pakete öffentlich anzubieten. Aber auch das lokale Erstellen von Paketen für noch nicht paketierte Software ermöglicht eine reibungslose Integration in die Ubuntu-Installation. Der Artikel beschreibt am Beispiel des Programms GNU hello, welches das klassische "Hello World"-Programm darstellt, eine einfache Paketerstellung. Diese wird mit Hilfe der `debhelper`-Skripte durchgeführt. {{{#!vorlage Hinweis Dieser Artikel geht davon aus, dass das entsprechende Programm zum ersten Mal paketiert wird. Wurde das Programm bereits paketiert, müssen die Dateien im Debian-Ordner nicht neu erstellt, sondern nur ggf. an die eigenen Bedürfnisse angepasst werden. Ist dort alles korrekt, kann z.B. direkt mit der [#Erstellung-des-Quellpaketes Erstellung eines Quellpaketes] fortgefahren werden. }}} = Vorbereitung = Um alle wichtigen Programme zum Paketbau herunterzuladen, kann einfach das Paket [packages:packaging-dev:] zzgl. [packages:debmake:] oder [packages:dh_make:] installiert [1] werden. Für diese Einführung werden folgende Pakete benötigt ([packages:quilt:] nur für das [#mittels-quilt manuelle Patchen]): {{{#!vorlage Paketinstallation build-essential debhelper debmake, universe quilt, universe }}} == `quilt` einrichten == `quilt` – nur für das [#mittels-quilt manuelle Patchen] benötigt – legt den Ordner '''patches''' nicht unter '''debian/patches''' an, sondern direkt im Quellcode-Verzeichnis. Da dies aber bei der Verwendung von `dpkg-buildpackage` (siehe unten) zusätzliche Konfigurationen nach sich ziehen würde, wird stattdessen, falls nicht schon vorhanden, ein [https://www.debian.org/doc/manuals/debmake-doc/ch04.de.html#quilt-setup Alias-Befehl mit zusätzlichen Optionen] {de} angelegt, der den Standard-Pfad wieder korrekt setzt. Da die Abwandlung vielleicht nicht dauerhaft das Verhalten von `quilt` beeinflussen soll, wird der Alias `dquilt` gewählt. Dazu wird die Datei '''~/.bash_aliases''' mit einem Editor ggf. angelegt, editiert und darin folgendes hinzugefügt: {{{#!code bash alias dquilt="quilt --quiltrc=${HOME}/.quiltrc-dpkg" . /usr/share/bash-completion/completions/quilt complete -F _quilt_completion $_quilt_complete_opt dquilt }}} Die Befehlsfolge – die alternativ auch im Terminal eingegeben werden kann (sonst muss sie mit `source ~/.bash_aliases` im aktuellen Terminal einmalig aktiviert werden) – legt fest, dass `dquilt` die Konfiguration aus '''~/.quiltrc-dpkg''' verwendet, welche nun ebenfalls mit einem Editor angelegt und mit folgendem Inhalt gefüllt werden muss: {{{#!code bash d=. while [ ! -d $d/debian -a `readlink -e $d` != / ]; do d=$d/..; done if [ -d $d/debian ] && [ -z $QUILT_PATCHES ]; then # if in Debian packaging tree with unset $QUILT_PATCHES QUILT_PATCHES="debian/patches" QUILT_PATCH_OPTS="--reject-format=unified" QUILT_DIFF_ARGS="-p ab --no-timestamps --no-index --color=auto" QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index" QUILT_COLORS="diff_hdr=1;32:diff_add=1;34:diff_rem=1;31:diff_hunk=1;33:" QUILT_COLORS="${QUILT_COLORS}diff_ctx=35:diff_cctx=33" mkdir -p $d/debian/patches fi }}} Nun wird, sofern der Ordner '''debian''' existiert, der Ordner '''patches''' darin angelegt. = Herstellen einer Arbeitsumgebung = Bevor der eigentliche Bau eines DEBIAN-Pakets beginnt, sollte zuerst eine Arbeitsumgebung eingerichtet werden. Die Arbeitsumgebung stellt in diesem Fall ein leeres Verzeichnis dar, welches ausschließlich zum Bauen dieses einen Debian-Paketes genutzt wird. Dazu wird ein Ordner erstellt, der wie das zu erstellende Programmpaket bezeichnet wird. Anschließend wird in dessen Verzeichnis gewechselt: {{{#!vorlage Befehl mkdir gnu-hello cd gnu-hello }}} Für den Paketbau muss der Quellcode als "[:tar:Tarball]" vorliegen und zusätzlich in das dazu passend benannte Quellverzeichnis entpackt werden. Für das Beispiel GNU hello wird deshalb das Quellarchiv des originalen Programms heruntergeladen und entpackt: {{{#!vorlage Befehl wget http://ftp.gnu.org/gnu/hello/hello-2.7.tar.gz tar -xvzf hello-2.7.tar.gz }}} Nun sollte das Programm zunächst getestet werden, um mögliche Probleme zu identifizieren. Da ein '''Makefile.am''' existiert, nutzt das Programm `make` als Build-System [5]. Hierbei zeigt sich, dass die eingebauten Tests (`make check`) nicht funktionieren, was den Paketbau verhindert. Darauf wird weiter unten eingegangen. = Erstellen der Debian-Dateien = Die Debian-Dateien, welche zum Paketieren nötig sind, werden nun mit einem Hilfsprogramm erstellt. Der alte Leitfaden nutzt dazu `dh_make` ([packages:dh_make:]), in der überholten Version wird das in Python geschriebene `debmake` empfohlen, das auch in diesem Artikel zum Einsatz kommt. Mehr zu `dh_make` lässt sich im alten [https://www.debian.org/doc/manuals/maint-guide/first.de.html#dh-make Leitfaden für neue Debian-Betreuer] {de} {en} bzw. der [:man:Manpage] nachlesen. Um sich die Arbeit des Eingebens von E-Mail-Adresse und Maintainername zu sparen, werden diese als lokale [:Umgebungsvariablen:] deklariert: {{{#!vorlage Befehl export DEBFULLNAME="VORNAME NACHNAME" export DEBEMAIL="EMAIL@ADRESSE" }}} Diese Angaben können z.B. in der Datei '''~/.profile''' [:Umgebungsvariable/Dateien/#Environment-einzelner-Dienste:dauerhaft gespeichert] werden. Es wird nun in das Verzeichnis des entpackten Quellarchivs, also des Quellcodes, gewechselt: {{{#!vorlage Befehl cd hello-2.7/ }}} Dort werden nun mit `debmake` die Vorlagedateien angelegt. {{{#!vorlage Befehl debmake -x1 }}} Die mit der Option `-x` übergebene Zahl bestimmt, wie viele Vorlagen-Dateien erstellt werden. Empfohlen ist mindestens ''3''; der Einfachheit halber und weil es sich hierbei um ein einzelnes Binärpaket handelt, wird ''1'' gewählt. `debmake` erkennt das automatisch und wählt daher als Pakettyp `bin`, also [wikipedia:Executable_and_Linking_Format:ELF]-Binärprogramm. {{{#!vorlage Hinweis Hier können noch mehr Optionen, wie z.B. Email-Adresse, Lizenz oder Art des Paketes übergeben werden. Siehe dazu die [:man:Manpage] von `debmake`. }}} Nun werden die Steuerungsdateivorlagen unter '''debian/''' erstellt und das Quellarchiv an die für das [#source-format Quellformat] nötige Stelle '''../hello_2.7.orig.tar.gz''' kopiert. = Bearbeiten der Debian-Dateien = Die Steuerungsdateien liegen nun unter '''gnu-hello/hello-2.7/debian'''. In diesen Ordner wird gewechselt: {{{#!vorlage Befehl cd debian/ }}} Dort befinden sich einige Dateien und Ordner: {{{ debian/ ├── changelog ├── control ├── copyright ├── patches │   └── series ├── README.Debian ├── rules ├── salsa-ci.yml ├── source │   ├── format │   ├── local-options │   ├── options │   └── patch-header ├── tests │   └── control ├── upstream │   └── metadata └── watch }}} Die Dateien werden in zwei Klassen unterteilt: Optionale Dateien, die nur unter bestimmten Umständen nötig sind, sie besitzen die Endung '''.ex'''. Die übrigen Dateien sind i.d.R. zwingend erforderlich, um ein Quellpaket erstellen zu können, oder gebräuchlich. Hier wurden nur die wichtigsten Dateien angelegt, mehr Vorlagen erhält man bei der Wahl der Zahlen ''2-4'' für die `debmake`-Option `-x`. Bei den meisten Programmen wird ein Großteil der optionalen Dateien nicht benötigt. Eine kurze Übersicht erfolgt unter [#Weitere-optionale-Konfigurationsdateien Weitere (optionale) Konfigurationsdateien]. Eine ausführlichere Erklärung und Hinweise zur Benutzung finden sich unter [http://www.debian.org/doc/manuals/maint-guide/dother.de.html Kapitel 5. Andere Dateien im Verzeichnis debian] {de} {en} des [http://www.debian.org/doc/manuals/maint-guide/index.de.html Debian-Leitfadens für neue Paketbetreuer] {de} {en} oder auf der entsprechenden [:man:Manpage] der debhelper-Skripte. {{{#!vorlage Hinweis Es ist auch hilfreich, sich ein Programm anzuschauen, das diese Dateien verwendet, bevor man selbst ein solches Programm paketieren möchte. Unter anderem kann man mit ihnen Shell-Skripte ausführen, entweder vor oder nach der Installation oder nach dem Deinstallieren eines Debian-Paketes. Man kann einen [:Cron:Cronjob] bei der Installation eines Paketes erstellen oder einen Menüeintrag im Anwendungsmenü. }}} Für dieses Beispiel werden alle nicht benötigten Dateien gelöscht: {{{#!vorlage Befehl rm -r README.Debian tests salsa-ci.yml upstream watch }}} Danach sollten noch diese Dateien und Ordner übrig bleiben: {{{ changelog control copyright patches rules source }}} Die wichtigen Dateien, die mit einem Texteditor [3] generell angepasst werden müssen, sind: '''[#changelog changelog]''', '''[#control control]''', '''[#copyright copyright]''', '''[#rules rules]''', '''[#source-format source/format]''' und ehemals '''[#compat compat]''', wobei meist die Standardvorgabe von '''source/format''' ausreicht. Des Weiteren ist bei vielen Programmen das Makefile im Quellcode ebenfalls ausreichend, sodass das Debian-Makefile in der Datei '''rules''' nicht weiter angepasst werden muss. Eine umfangreiche Erklärung zu diesen Dateien findet sich in [https://www.debian.org/doc/manuals/debmake-doc/ch06.de.html Kapitel 6. Basics for packaging] {de} {en} im [https://www.debian.org/doc/manuals/debmake-doc/ Leitfaden für Debian-Betreuer] {de} {en}. == changelog == In dieser Datei werden Veränderungen zwischen den einzelnen Paketversionen (changes) dokumentiert. Die '''changelog'''-Datei ist in der folgenden Form: {{{#!code hello (2.7-1) UNRELEASED; urgency=low * Initial release. Closes: #nnnn -- VORNAME NACHNAME DATUM UHRZEIT +/-UTC-DIFFERENZ }}} In der erste Zeile steht am Anfang das Programm und die Version. {{{#!vorlage Hinweis Soll eine gepatchte Version eines Paketes, das schon in den Ubuntu-Paketquellen vorhanden ist, erstellt werden, so ist es empfehlenswert, nur eine geringfügig höhere Versionsnummer zu verwenden, damit im Fall einer Sicherheitslücke auf das Paket aus den Ubuntu-Paketquellen aktualisiert wird. Die dazugepatchten Funktionen fehlen anschließend, aber es ist keine bekannte Sicherheitslücke mehr vorhanden. Besitzt beispielsweise das Ubuntu-Paket die Version ''2.2.1-1ubuntu4.2'', wäre ein Heraufsetzen auf ''2.2.1-1ubuntu4.2+patched1'' sinnvoll. Das nächste Ubuntu-Paket hätte dann entweder ''2.2.2-…'' oder ''2.2.1-1ubuntu4.3'' als Versionsnummer. Beide sind höher als die des lokal gepatchten Pakets, es wird also das Ubuntu-Paket beim Erscheinen einer neuen Version installiert werden. Anschließend muss dieses neue Paket bei Bedarf wieder gepatcht werden. Mehr zum Thema Versionsnummern findet man im Artikel [:Versionsnummern von Ubuntu-Paketen:]. }}} * Für das Beispiel wird nun die Version des Paketes von `2.7-1` zu `1:2.7-1~0ubuntu1` geändert. Die Epoch-Nummer wird gesetzt, da das Paket '''hello''' bereits in den Ubuntuquellen vorhanden ist und je nach Ubuntuversion schon in neuerer Version vorliegt, das selbsterstellte Paket aber installiert bleiben soll. * Als nächstes steht in der ersten Zeile das Wort `UNRELEASED`. Dies kann man mit dem Codenamen der Ubuntu-Version ersetzt werden, für die das Paket erstellt werden soll. * `urgency=WICHTIGKEIT` gibt mit dem Wert `WICHTIGKEIT` an, wie groß die Veränderungen sind, die vorgenommen wurden. Normalerweise muss der Standardwert `low` nicht angepasst werden. Folgende Werte sind möglich: `low`, `medium`, `high`, `emergency`, `critical` * In der nächsten Zeile werden die Änderungen beschrieben, also was am Paket im Vergleich zu vorherigen Paketen verändert wurde. Dies umfasst auch die Nummer des angefertigten ITP (''Intent To Package'') Fehlerberichtes. * In der letzten Zeile muss der Name und die Email-Adresse des Paketbetreuers eingetragen werden, bzw. wurde durch entsprechend übergebene Parameter an dh_make schon eingetragen. Grundsätzliche sollte diese Datei mit dem Befehl `dch` berabeitet werden: {{{#!vorlage Befehl dch --edit # Steuerungsdateien anpassen dch --release }}} Für jede neue Version kann `dch` auch mit den Optionen `--append` bzw. `--increment` aufgerufen werden. Mehr dazu in der [:man:Manpage] von `dch`. Ein Beispiel kann also wie folgt aussehen: {{{#!code hello (1:2.7-1~0ubuntu1) noble; urgency=low * Initial packaging. -- VORNAME NACHNAME DATUM UHRZEIT +/-UTC-DIFFERENZ }}} Leerzeichen und Leerzeilen sind entsprechend dem Beispiel zu setzen. {{{#!vorlage Hinweis Es ist darauf zu achten, dass sich zwischen Email-Adresse und Datum exakt 2 Leerzeichen befinden. Die Email-Adresse wird von den Zeichen "<" und ">" eingerahmt. }}} == control == Die '''control'''-Datei stellt bei einem fertigen Debianpaket die Kontrollinformationen bereit und wurde in diesem Beispiel mit folgendem Vorlageninhalt erstellt: {{{#!code control Source: hello Section: unknown Priority: optional Maintainer: VORNAME NACHNAME Build-Depends: debhelper-compat (= 13), dh-autoreconf Standards-Version: 4.6.1 Homepage: Rules-Requires-Root: no #Vcs-Git: https://salsa.debian.org/debian/hello.git #Vcs-Browser: https://salsa.debian.org/debian/hello Package: hello Architecture: any Multi-Arch: foreign Depends: ${misc:Depends}, ${shlibs:Depends} Description: auto-generated package by debmake This Debian binary package was auto-generated by the debmake(1) command provided by the debmake package. }}} Die wichtigsten Felder besitzen folgende Bedeutung. Alle weiteren lassen sich im [https://www.debian.org/doc/debian-policy/ch-controlfields.html#debian-source-package-template-control-files-debian-control Debian Policy Manual, "Debian source package template control files"] {en} nachlesen. {{{#!vorlage Tabelle Zeile Bedeutung +++ `Section` Dies ist der Bereich, in dem das Paket in der Debian-Paketstruktur erscheint. Hier kann einer der folgenden Werte stehen: `admin`, `cli-mono`, `comm`, `database`, `devel`, `debug`, `doc`, `editors`, `electronics`, `embedded`, `fonts`, `games`, `gnome`, `graphics`, `gnu-r`, `gnustep`, `hamradio`, `haskell`, `httpd`, `interpreters`, `java`, `kde`, `kernel`, `libs`, `libdevel`, `lisp`, `localization`, `mail`, `math`, `metapackages`, `misc`, `net`, `news`, `ocaml`, `oldlibs`, `otherosfs`, `perl`, `php`, `python`, `ruby`, `science`, `shells`, `sound`, `tex`, `text`, `utils`, `vcs`, `video`, `web`, `x11`, `xfce`, `zope` [[Vorlage (Hinweis, "Unter [https://packages.ubuntu.com/noble/] {en} kann am Beispiel der Ubuntuversion [:24.04:] verglichen werden, welche Pakete welchem Abschnitt zugeteilt sind.")]] +++ `Priority` Hier kann bestimmt werden, ob auf das Paket verzichtet werden kann (optional) oder ob das Paket zwingend notwendig für das System ist. Für Priority können folgende Werte verwendet werden: `required`, `important`, `standard`, `optional`, `extra`. +++ `Maintainer` Diese Zeile enthält den Namen und die E-Mail-Adresse des Paketbetreuers; diese Angaben sind in der gezeigten Schreibweise anzugeben. +++ `Build-Depends` Hier werden sämtliche Pakete angegeben, die zum Kompilieren des Quellcodes nötig sind. Außerdem wird hierüber der Kompatibilitätsmodus für `debhelper` [:Grundlagen_der_Paketerstellung/Optionale_Konfigurationsdateien#compat-historisch:gewählt]. +++ `Rules-Requires-Root` Ob der Bau des Paketes lt. [#rules '''rules'''] [:Root-Rechte:] benötigt. +++ `Architecture` Gibt an, für welche Architekturen das Paket verwendet werden kann. Das Schlüsselwort `any` besagt, dass das Paket für alle Architekturen erstellt werden kann. Wird `all` angegeben, bedeutet dies, das sich ein und dasselbe Paket auf allen Architekturen verwenden lässt. +++ `Depends` Sind die Pakete, die zusätzlich installiert werden. Falls die Abhängigkeiten mit "ODER" angegeben werden sollen, kann ein senkrechter Strich `|` als Trenner zwischen den Paketnamen verwendet werdet. +++ `Description` Diese Zeile enthält in einer Zeile eine kurze Beschreibung des Pakets. Alle weiteren Zeilen müssen mit einem Leerzeichen beginnen, Absätze durch einen Punkt markiert sein und beschreiben das Paket ausführlich. Diese Texte sollten in englischer Sprache verfasst werden. }}} Weitere optionale Zeilen sind unter anderem: {{{#!vorlage Tabelle Zeile Bedeutung +++ `Conflicts` Die hier angegebenen Pakete werden deinstalliert. +++ `Replaces` Pakete die ersetzt werden. +++ `Recommends` Pakete die empfohlen werden. +++ `Suggests` Pakete die nützlich sein können. }}} {{{#!vorlage Hinweis In der kurzen Beschreibung sollte der Name des Pakets nicht erwähnt werden. }}} Für das Beispiel sieht eine vollständige '''control'''-Datei folgendermaßen aus: {{{#!code control Source: hello Section: misc Priority: optional Maintainer: VORNAME NACHNAME Build-Depends: debhelper-compat (= 13), dh-autoreconf Standards-Version: 4.6.1 Rules-Requires-Root: no Package: hello Architecture: any Multi-Arch: foreign Depends: ${misc:Depends}, ${shlibs:Depends} Description: The classic greeting and a package build example The GNU hello program produces a familiar, friendly greeting. It allows non-programmers to use a classic computer science tool which would otherwise be unavailable to them. . Seriously, though: this is an example of how to do a Debian package. It is the Debian version of the GNU Project's `hello world' program (which is itself an example for the GNU Project). }}} == copyright == In die '''copyright'''-Datei gehören die Lizenzbestimmungen des Programms. Mit dem [https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Debian Copyright Format 1.0] {en} (ehemals DEP 5) existiert ein Standard, der es erlaubt die Copyright-Informationen auch maschinell auszuwerten. Neue Pakete sollten diesen Standard verwenden. Damit gebräuchliche Lizenzen, die in mehreren hundert installieten Paketen verwendet werden, nicht in jedem Paket enthalten sein müssen und somit aufsummiert sehr viel Speicherplatz für gleichen Inhalt verbrauchen würden, liegt in Debian-Systemen unter '''/usr/share/common-licenses/''' eine Kopie dieser Lizenzen. Im Paket-Copyright reicht also meist ein einfacher Verweis auf dieses Verzeichnis aus. Bei diesem Paket wurden die Lizenzen für die Quelldateien bereits erkannt und eingetragen. Es fehlt noch die Lizenzierung der Dateien unter '''debian/'''. Nach Anpassung wird daraus der Inhalt folgender Form: {{{#!code Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: hello Upstream-Contact: ENTSPRECHENDER NAME Source: http://ftp.gnu.org/gnu/hello/hello-2.7.tar.gz Files: debian/* Copyright: JAHR VORNAME NACHNAME License: GPL-3+ ... }}} == rules == Die '''rules'''-Datei ist ein Makefile [5], in welchem alle Aufgaben zum Paketbau eingetragen sein müssen. Hier wird z.B. der eventuelle Kompiliervorgang gesteuert. Sie ist sozusagen das "Herzstück" eines Quellpaketes. Mithilfe der [https://www.debian.org/doc/manuals/debmake-doc/ch06.de.html#debhelper `debhelper`-Skripte] {en} {de} ist die Erstellung meist ziemlich einfach, denn es reicht meist schon folgender Inhalt: {{{#!code make #!/usr/bin/make -f %: dh $@ }}} Die durch `debmake` erstellte Vorlage hat den selben nicht auskommentierten Inhalt (inkl. `autoreconf` für Neubau der automatisch generierten Dateien des Bau-Systems, z.B. '''configure'''): {{{#!code make #!/usr/bin/make -f # You must remove unused comment lines for the released package. #export DH_VERBOSE = 1 #export DEB_BUILD_MAINT_OPTIONS = hardening=+all #export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic #export DEB_LDFLAGS_MAINT_APPEND = -Wl,-O1 %: dh $@ --with autoreconf #override_dh_install: # dh_install --list-missing -X.la -X.pyc -X.pyo }}} Dies bedeutet, dass alle debhelper-Skripte der Reihe nach ausgeführt werden. Ausgeschrieben, sieht das Makefile in grober Struktur und je nach Version und installierten Zusatzpaketen, sowie genutzten Optionen, folgendermaßen aus: {{{#!code make #!/usr/bin/make -f clean: dh_testdir dh_auto_clean dh_clean build: dh_testdir dh_auto_configure dh_auto_build dh_auto_test build-arch: dh_testdir -a dh_auto_configure -a dh_auto_build -a dh_auto_test -a build-indep: dh_testdir -i dh_auto_configure -i dh_auto_build -i dh_auto_test -i install: build dh_testroot dh_prep dh_installdirs dh_auto_install dh_install dh_installdocs dh_installchangelogs dh_installexamples dh_installman dh_installcatalogs dh_installcron dh_installdebconf dh_installemacsen dh_installifupdown dh_installinfo dh_installinit dh_installmenu dh_installmime dh_installmodules dh_installlogcheck dh_installlogrotate dh_installpam dh_installppp dh_installudev dh_installwm dh_installxfonts dh_installgsettings dh_bugfiles dh_ucf dh_lintian dh_gconf dh_icons dh_perl dh_usrlocal dh_link dh_compress dh_fixperms install-arch: build-arch dh_testroot -a dh_prep -a dh_installdirs -a dh_auto_install -a dh_install -a dh_installdocs -a dh_installchangelogs -a dh_installexamples -a dh_installman -a dh_installcatalogs -a dh_installcron -a dh_installdebconf -a dh_installemacsen -a dh_installifupdown -a dh_installinfo -a dh_installinit -a dh_installmenu -a dh_installmime -a dh_installmodules -a dh_installlogcheck -a -a dh_installlogrotate -a dh_installpam -a dh_installppp -a dh_installudev -a dh_installwm -a dh_installxfonts -a dh_installgsettings -a dh_bugfiles -a dh_ucf -a dh_lintian -a dh_gconf -a dh_icons -a dh_perl -a dh_usrlocal -a dh_link -a dh_compress -a dh_fixperms -a install-indep: build-indep dh_testroot -i dh_prep -i dh_installdirs -i dh_auto_install -i dh_install -i dh_installdocs -i dh_installchangelogs -i dh_installexamples -i dh_installman -i dh_installcatalogs -i dh_installcron -i dh_installdebconf -i dh_installemacsen -i dh_installifupdown -i dh_installinfo -i dh_installinit -i dh_installmenu -i dh_installmime -i dh_installmodules -i dh_installlogcheck -a -i dh_installlogrotate -i dh_installpam -i dh_installppp -i dh_installudev -i dh_installwm -i dh_installxfonts -i dh_installgsettings -i dh_bugfiles -i dh_ucf -i dh_lintian -i dh_gconf -i dh_icons -i dh_perl -i dh_usrlocal -i dh_link -i dh_compress -i dh_fixperms -i binary: install dh_strip dh_makeshlibs dh_shlibdeps dh_installdeb dh_gencontrol dh_md5sums dh_builddeb binary-arch: install-arch dh_strip -a dh_makeshlibs -a dh_shlibdeps -a dh_installdeb -a dh_gencontrol -a dh_md5sums -a dh_builddeb -a binary-indep: install-indep dh_installdeb -i dh_gencontrol -i dh_md5sums -i dh_builddeb -i .PHONY: binary binary-arch binary-indep install install-arch install-indep build build-arch build-indep clean }}} Die `dh_auto_*`-Skripte sollen hier kurz vorgestellt werden: {{{#!vorlage Tabelle <-4 rowclass="titel"> dh_auto_* +++ debhelper-Skript Befehl im Quellcode sofern Ziel und Makefile bzw. configure-Skript existieren +++ [[Vorlage (Befehl, "dh_auto_clean")]] [[Vorlage (Befehl, "make distclean")]] +++ [[Vorlage (Befehl, "dh_auto_configure")]] [[Vorlage (Befehl, "./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var")]] +++ [[Vorlage (Befehl, "dh_auto_build")]] [[Vorlage (Befehl, "make")]] +++ [[Vorlage (Befehl, "dh_auto_test")]] [[Vorlage (Befehl, "make test")]] +++ [[Vorlage (Befehl, "dh_auto_install")]] [[Vorlage (Befehl, "make install DESTDIR=/PFAD/ZU/PAKET_VERSION/debian/PAKET")]] }}} Sollen einzelne debhelper-Skripte um einen Befehl erweitert werden, so kann die Schreibweise `override_dh_*` verwendet werden. Folgendes Beispiel zeigt eine solche Verwendung am Beispiel `dh_auto_clean`: {{{#!code make #!/usr/bin/make -f %: dh $@ --with-autoreconf override_dh_auto_clean: dh_auto_clean rm -f junk }}} Hier wird zusätzlich zu `dh_auto_clean` noch mittels des Löschbefehls [:rm:] die Datei '''junk''' entfernt. {{{#!vorlage Hinweis Kompilieroptionen wie Compiler-Flags oder Makeoptionen können wie in einem Makefile [5] gesetzt werden. Eine ausführliche Dokumentation findet sich im [https://www.gnu.org/software/make/manual/make.html GNU make manual] {en}. }}} {{{#!vorlage Experten Lokale Buildflags können für alle lokalen Paketerstellungen in der Datei '''~/.config/dpkg/buildflags.conf''' festgelegt werden, systemweite unter '''/etc/dpkg/buildflags.conf'''. }}} Da die Bau-Prozedur nicht von der [:Programme_kompilieren/#Allgemeines-Vorgehen:standardmäßigen] abweicht, die bereits durch die vorgefertigten Skripte ausgeführt wird, muss die '''rules'''-Datei nicht angepasst werden. Eine detaillierte Erklärung findet man unter [http://www.debian.org/doc/manuals/maint-guide/dreq.de.html#rules 4.4. rules] {de} {en} im [http://www.debian.org/doc/manuals/maint-guide/index.de.html alten Leitfaden] {de} {en}. === Build-Systeme === Normalerweise kann `debhelper` aus den Dateinamen im Quellcode feststellen, welches Build-System verwendet werden muss. Manchmal ist das aber nicht möglich. Bei einem [:Qt:]-Projekt beispielsweise kann debhelper nicht unterscheiden, ob Qt4 oder Qt5 verwendet wird und wählt die neuere Qt-Version. Im Fall eines Qt4-Projektes muss man deshalb das Build-System explizit angeben: {{{#!code make #!/usr/bin/make -f %: dh $@ --buildsystem=qmake_qt4 }}} Um herauszufinden, welche Build-Systeme unterstützt werden und welches von debhelper automatisch gewählt wird, kann man folgenden Befehl verwenden: {{{#!vorlage Befehl dh_auto_build -l }}} == source/format == In der Datei '''source/format''' wird das Quellformat für dpkg-source festgelegt. Je nach Version wird beim Entpacken und Anwenden der Patches bzw. beim Bauen unterschiedlich vorgegangen. Die gebräuchlichen Formate sind zur Zeit "3.0 (quilt)" und "3.0 (native)", während "1.0" als veraltet gilt (aber trotzdem funktioniert). Die ungepatchte Quelle besteht beim nativen Quellformat aus einem einzigen Archiv, wozu im Gegensatz beim Format "3.0 (quilt)" mindestens noch ein weiteres Archiv vorhanden ist, welches den Debianordner beinhaltet. Soll nun das quilt-3.0-Format verwendet werden, lautet der Eintrag in die '''source/format''': {{{#!code text 3.0 (quilt) }}} `debmake` erstellt automatisch das empfohlene quilt-3.0-Format, diese Datei muss am Beispiel GNU hello also nicht angepasst werden. == Weitere (optionale) Konfigurationsdateien == Auch die weiteren Dateien können beim Beispiel GNU hello ignoriert werden. Eine knappe Darstellung der optionalen Konfigurationsdateien findet sich unter [:Grundlagen_der_Paketerstellung/Optionale_Konfigurationsdateien: Optionale Konfigurationsdateien]. Empfehlenswert ist beispielsweise die Konfiguration des Werkzeugs `uscan` in [:Grundlagen_der_Paketerstellung/Optionale_Konfigurationsdateien/#watch:'''watch'''], was den Aufwand für die Aktualisierung des Paketes auf eine neuere Version verringert. = Erstellung eines Menüeintrages = Wie ein Icon im GNOME-, KDE-, Xfce-Menü für die Anwendung im erstellten Debian-Paket erscheint, ist im Artikel: [:Grundlagen der Paketerstellung/Menüeintrag:] beschrieben. Für das Beispiel GNU hello ist dies nicht unbedingt notwendig, da es sich hierbei um ein reines Kommandozeilenprogramm handelt. = Paketbau = Die Vorbereitung zur Paketierung für das Beispiel GNU `hello` ist nun abgeschlossen. Hierzu nutzt man das Programm [https://www.debian.org/doc/manuals/debmake-doc/ch05.de.html#what-debuild `debuild`] {en} {de}, das ein Wrapper-Programm für das Perl-Skript `dpkg-buildpackage` ist und nach dem Paketbau standardmäßig `lintian` aufruft. Beim Bau eines Binärpakets wird immer ein [debian:Packaging/SourcePackage:Quellpaket] {en} erstellt, man muss jedoch nicht den Umweg darüber gehen. Dieses benötigt man auch, wenn man den Paketbau in einer `chroot`-Umgebung tätigen will. Der Befehl `debuild` hat folgende allgemeine Syntax: {{{#!vorlage Befehl debuild [debuild-Optionen] [dpkg-buildpackage-Optionen] [--lintian-opts lintian-Optionen] }}} == Überprüfen des Paketes == Die Metadaten des Binärpaketes (Dateiendung ''.changes'', erst ''nach'' dem Bau des Binärpaketes verfügbar) sollten mit `lintian` überprüft werden. Dieses Programm dient dazu, bekannte Richtlinenverstöße und typische Rechtschreibfehler anzuzeigen. Damit kann das Paket vor seiner Veröffentlichung auf vermeidbare Fehler geprüft werden. Folgender Befehl ruft `lintian` mit umfangreichsten Prüfungen auf: {{{#!vorlage Befehl lintian -EvI --pedantic --show-overrides --color=auto PAKET_VERSION.changes }}} Sollen zusätzlich hilfreiche Informationen zu den bemängelten Fehlern angegeben werden, kann die Option `-i` genutzt werden. Die Optionen können auch in der systemweiten Konfigurationsdatei unter '''/etc/lintianrc''', bzw. im Benutzerverzeichnis unter '''~/.lintianrc''' gepspeichert werden. Im Folgenden wird `lintian` durch `debuild` aufgerufen. == Erstellung des Quellpaketes == Im Quellcodeverzeichnis wird folgender Befehl zum Bau des [debian:Packaging/SourcePackage:Quellpakets] angewandt: {{{#!vorlage Befehl debuild -S -us -uc --lintian-opts }}} Dabei wird automatisch (sofern installiert) fakeroot verwendet, um Rootrechte vorzutäuschen. Die Optionen `-us` und `-uc` überspringen die Schritte des (automatischen) Signierens [4] der Quellkontrolldatei (Endung '''.dsc''') und der Debian-Steuerdatei zum Hochladen (Endung '''.changes'''). Ist man im Besitz eines GnuPG-Schlüssels [4], sollten diese beiden Optionen nicht genutzt werden, sodass eine Signierung erfolgt (Schlüssel-ID über `--sign-keyid` mitgeben). Zum Quellpaket gehören nun folgende Dateien im übergeordneten Verzeichnis: * '''hello-2.7.tar.gz''' - der originale Paket-Tarball * '''hello_2.7.orig.tar.gz''' - Symlink zum Original-Paket * '''hello_2.7-1~0ubuntu1.debian.tar.xz''' - bei einem nicht-nativen Quellformat das Archiv mit den Debian-Änderungen * '''hello_2.7-1~0ubuntu1.dsc''' - Quellkontrolldatei, Metadaten des Quellpaketes * '''hello_2.7-1~0ubuntu1_source.changes''' - Debian-Steuerdatei zum Hochladen. Sie kann nun lokal mit [:pbuilder-dist:] für den Bauprozess von Binär-Debian-Paketen verwendet werden. Alternativ kann diese, sofern sie signiert wurde, zum Hochladen in ein [:Launchpad/PPA:] genutzt werden. Die Datei '''hello_2.7-1~0ubuntu1_source.buildinfo''' enthält Informationen zur Bau-Umgebung und den erstellten Artefakten, '''hello_2.7-1~0ubuntu1_source.build''' ist die Log-Datei des Paketbaus. == Erstellung des Binärpaketes == {{{#!vorlage Hinweis Soll das Paket nicht nur für die lokale Verwendung erstellt werden, empfiehlt sich die Paketerstellung mit [:pbuilder-dist:]. }}} {{{#!vorlage Hinweis Spätestens beim Ausführen des folgenden Befehls werden wir feststellen, dass der Bau des vorliegenden alten '''GNU `hello`'''-Pakets fehlschlägt. Also müssen die Ursache gefunden und nötige Änderungen gemäß dem Kapitel [#Patchen Patchen] eingebaut werden. Danach muss der [#Paketbau gesamte Paketbau] wiederholt werden. }}} Das geschieht durch folgenden Befehl: {{{#!vorlage Befehl debuild -us -uc --lintian-opts }}} Die Optionen `-us` und `-uc` sind analog wie beim Quellpaket ggfs. zu entfernen. Falls die Bauabhängigkeiten nicht installiert sind, kann mit der Option `-d` der Bau dennoch ermöglicht werden. Dabei werden folgende Schritte nach dem Säubern von ungewollten Umgebungsvariablen, sowie dem Überprüfen nach denen in der '''[#control control]'''-Datei festgeleten Abhängigkeiten zum Paketbau durchgeführt (ohne Signieren der Quellkontroll- und Steuerungsdatei mittels GnuPG): {{{#!vorlage Befehl debian/rules clean cd .. && dpkg-source -b QUELLVERZEICHNIS/ && cd - debian/rules build fakeroot debian/rules binary dpkg-genchanges >../PAKET_VERSION_ARCHITEKTUR.changes cd .. && dpkg-source --after-build QUELLVERZEICHNIS/ && cd - }}} {{{#!vorlage Hinweis Bei größeren Paketen, bei denen ein Kompilieren einige Minuten in Anspruch nimmt, aber nur kleine Ausbesserungen in der Datei '''debian/rules''' vorgenommen werden, kann zu Testzwecken nur das Binärpaket erstellt, aber nicht das gesamte Programm kompiliert werden: [[Vorlage (Befehl "fakeroot debian/rules binary")]] }}} {{{#!vorlage Experten Mit der Umgebungsvariable "DEB_BUILD_OPTIONS" können Flags direkt dem Debian-Kompilierprozess übergeben werden. Grundsätzlich kann jeder Maintainer eigene Flags in der Makedatei '''[#rules debian/rules]''' auslesen lassen, allerdings haben sich folgende vier durchgesetzt: `nocheck`, `noopt`, `nostrip`, `parallel=n` (siehe dazu in der Ubuntu-Policy unter [http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-options 4.9.1 debian/rules and DEB_BUILD_OPTIONS] {en}) Besonderes Augenmerk gilt dem Flag "parallel=n". Sofern dieses unterstützt wird, kann es dazu genutzt werden, den Paketerstellungsvorgang zu parallelisieren, was den Vorgang in erster Linie bei kompilieraufwendigen Paketen sehr beschleunigt. Je nach Prozessor und Festplatte variiert die optimal zugewiesene Jobanzahl "n". Als Faustregel kann man hier die Rechnung "n=(Prozessorkerne-1)*2" nehmen, was bei einem 4-Kern-Prozessor einen Wert von (4-1)*2=6 ergibt. Dieser wird nach folgendem Muster als [:Umgebungsvariable:] gesetzt: [[Vorlage (Befehl, "export DEB_BUILD_OPTIONS=\"parallel=6\"")]] Alternativ kann dies mit der Option `-j` direkt dem Programm `dpkg-buildpackage` übergeben werden: [[Vorlage (Befehl, "dpkg-buildpackage -j6")]] Angegebene, aber nicht unterstützte Build-Optionen werden ignoriert. }}} Es wurden folgende Dateien erstellt: * '''hello_2.7-1~0ubuntu1_amd64.deb''' - das Binärpaket * '''hello_2.7-1~0ubuntu1_amd64.changes''' - Metadaten des Binärpaketes * '''hello-dbgsym_2.7-1~0ubuntu1_amd64.deb''' - Debugging-Informationen Das Paket kann nun direkt installiert oder über eine [:Lokale_Paketquellen/#Eigene-Paketquellen-Paketarchiv:eigene Paketquelle] zur Verfügung gestellt werden. Möchte man die gesamte Debian-basierte Community an seinem Erfolg teilhaben lassen (in diesem Fall gibt es das Paket natürlich schon in den Quellen) lädt man das Paket in das Debian-Archiv hoch; die Vorgehensweise ist im Kapitel [https://www.debian.org/doc/manuals/debmake-doc/ch06.de.html#workflow Arbeitsablauf des Paketierens] {de} {en} im offiziellen Leitfaden beschrieben. = Patchen = Falls der Bau des Paketes nicht funktioniert, das Programm gegen die [https://www.debian.org/doc/debian-policy/ ''Debian Policy''] {en} verstößt oder Fehler bei der Benutzung des Programms auftreten, und die Entwickler diese Fehler nicht selbst beheben, muss ggf. eine Modifikation am Quellcode vorgenommen werden. Diese bezeichnet man als ''patch''. Im Folgenden wird die Erstellung solcher Patches am Beispiel von GNU hello beschrieben. == ... mittels vorhandener Patch-Dateien == Wenn schon Patch-Dateien vorhanden sind, können diese einfach in das Verzeichnis '''debian/patches''' kopiert werden. Für das Beispiel von GNU hello können diese hier im nötigen [:diff#Patchdatei-erstellen:diff-Format] heruntergeladen werden: * [[Anhang(01-no-usr-share-info-dir.patch)]] {dl} Vermeidet die Richtlinenverletzung, die durch das Anlegen der Datei '''/usr/share/info/dir.gz''' relativ zur Quellcodewurzel durch das Makefile '''doc/Makefile''' entstand. * [[Anhang(02-repair-tests.patch)]] {dl} Reparatur, damit auch die eingebauten Tests funktionieren. In die Datei '''debian/patches/series''' muss dann noch folgendes eingetragen / "registriert" werden: {{{ 01-no-usr-share-info-dir.patch 02-repair-tests.patch }}} Wenn Header gemäß dem Standard [https://dep-team.pages.debian.net/deps/dep3/ "Patch Tagging Guidelines" (DEP 3)] {en} erforderlich sind, sollten diese noch in die Patch-Dateien eingefügt werden. Für ein Muster siehe unter 5. im folgenden Abschnitt. == ... mittels `quilt` == Soll die Änderung im Source-Code manuell erfolgen, können die nötigen Patch-Dateien mit Hilfe des unter [#quilt-einrichten Vorbereitung] angepassten Programms `quilt` erzeugt und registriert werden. Dies ist das gängige und empfohlene Verfahren. Das Arbeitsverzeichnis sollte nun eine Ebene über dem '''debian/'''-Verzeichnis, also das Quellcodeverzeichnis selbst sein (der [:Shell/Einführung#Der-Beginn-der-Prompt:Prompt] sieht dann in etwa so aus: `.../gnu-hello/hello-2.7$`). 1. Um `quilt` den Namen des neuen Patches mitzuteilen, wird folgender Befehl verwendet: {{{#!vorlage Befehl dquilt new 01-no-usr-share-info-dir }}} 2. Anschließend wird die Datei '''doc/Makefile.in''' als Vorlagedatei des fehlerhaften Makefiles als zu bearbeitende Datei hinzugefügt: {{{#!vorlage Befehl dquilt add doc/Makefile.in }}} Nun wurde eine Kopie der Datei unter '''.pc/01-no-usr-share-info-dir/doc/Makefile.in''' angelegt (Sicherungskopie). Die Datei '''doc/Makefile.in''' kann nun bearbeitet werden ohne dass der Inhalt der ursprünglichen Datei verloren geht. 3. Da durch das Makefile '''doc/Makefile''' relativ zur Quellcodewurzel eine Datei '''/usr/share/info/dir.gz''' angelegt wird, tritt eine Richtlinenverletzung auf. Um dies zu beheben werden nun mit einem Editor die Zeilen 942-943 in '''doc/Makefile.in''' {{{ @if (install-info --version && \ install-info --version 2>&1 | sed 1q | grep -i -v debian) >/dev/null 2>&1; then \ }}} durch folgende Zeile ersetzt: {{{ @if false; then \ }}} Alternativ kann die Datei auch mit `dquilt edit doc/Makefile.in` bearbeitet werden oder mit dem Programm [:`patch`:] unter Verwendung der im vorigen Abschnitt bereitgestellten Patch-Datei. 4. Nach den Änderungen an der Datei kann der Patch so gespeichert werden: {{{#!vorlage Befehl dquilt refresh }}} 5. Nun können, falls erforderlich, noch Metadaten in Form eines Headers zum Patch hinzugefügt werden. Dieser wird gemäß dem Standard [https://dep-team.pages.debian.net/deps/dep3/ "Patch Tagging Guidelines" (DEP 3)] {en} formatiert. Ein Header für den vorliegenden Patch könnte folgendermaßen aussehen: {{{ From: Santiago Vila Subject: Do not create /usr/share/info/dir.gz Last-Update: JJ-MM-DD * doc/Makefile.in: Disable creation of file dir.gz under /usr/share/info/ during package build }}} Mit folgendem Befehl kann man den Header manuell eintragen: {{{#!vorlage Befehl dquilt header --dep3 -e }}} 6. Mit folgendem Befehl wird das Makefile auf den ursprünglichen Stand zurückversetzt und die Änderung nur im Patch gespeichert: {{{#!vorlage Befehl dquilt pop -a }}} 7. Da auch die eingebauten Tests im Verlauf des Paketbaus nicht funktionieren, muss noch eine weiterere Anpassung vorgenommen werden: {{{#!vorlage Befehl dquilt new 02-repair-tests dquilt add tests/Makefile.am }}} Nun wird dazu in der Datei '''tests/Makefile.am''' die letzte Zeile ganz entfernt und in der vorletzten der Backslash ` \ ` am Ende. {{{#!vorlage Befehl dquilt refresh dquilt header --dep3 -e ### optional ### dquilt pop -a }}} Die Fehler im Beispiel GNU `hello` sollten nun behoben sein und es muss nun der [#Paketbau gesamte Paketbau] wiederholt werden. == `quilt`-Bedienung == quilt bietet eine einem [:Versionsverwaltung:Versionsverwaltungssystem] ähnliche Verwaltung der Patches an, welche der Reihe nach angewandt werden. Die Patches werden dabei unter '''patches''' gespeichert, die ungepatchten Dateien unter '''.pc/PATCHNAME/''' gesichert. Die von quilt registrierten Patchnamen werden in ihrer Reihenfolge in der Datei '''patches/series''' verwaltet. Siehe auch die [man:quilt:Manpage] von quilt. {{{#!vorlage Tabelle Befehl Bedeutung +++ quilt new PATCHNAME Einen neuen (leeren) Patch mit Bezeichnung "PATCHNAME" erstellen. +++ quilt add DATEI Die Datei '''DATEI''' beim aktuellen Patch als zu bearbeitende Datei vormerken. Eine Kopie der Datei wird unter '''.pc/''' erstellt. +++ quilt edit DATEI Die Datei '''DATEI''' wird mit dem Standard-Editor zur Bearbeitung geöffnet. Anschließend wird `quilt add` ausgeführt, sodass die Änderungen bereits registriert sind. +++ quilt refresh Bei Änderungen an den vom aktuellen Patch überwachten Dateien wird unter '''debian/patches/PATCHNAME''' dieser Patch aktualisiert. +++ quilt applied Eine Liste aller angewandten Patches ausgeben. +++ quilt push Der in der '''series'''-Datei nächste Patch wird angewandt. Mit der Option `-a` werden alle Patches angewendet. +++ quilt pop Der aktuelle Patch wird unangewandt, also die vorherige Version wird wiederhergestellt. Mit der Option `-a` werden alle Patches unangewandt. +++ quilt unapplied Eine Liste aller nicht angewandten Patches ausgeben. +++ quilt rename PATCHNAME Den aktuellen Patch nach "PATCHNAME" umbenennen. +++ quilt delete Der aktuelle Patch wird entfernt, falls angewandt zuvor unangewandt. Die Patchdatei befindet sich aber noch unter '''patches/PATCHNAME'''. Mit der Option `-f` kann diese direkt gelöscht werden. +++ quilt header Die Beschreibung des aktuellen Patches anzeigen oder ändern. Zur Bearbeitung der Beschreibung dient die Option `-e`. }}} In [http://www.debian.org/doc/manuals/maint-guide/modify.de.html Kapitel 3. Den Quellcode verändern] {de} {en} aus dem [http://www.debian.org/doc/manuals/maint-guide/index.de.html Leitfaden für neue Debian-Betreuer] {de} {en} werden einige konkrete Anwendungsfälle betrachtet. = Links = == Intern == * [:Grundlagen_der_Paketerstellung/Optionale_Konfigurationsdateien:Optionale Konfigurationsdateien] * [:Paketbau:] * [:Versionsnummern_von_Ubuntu-Paketen:] * [:dpkg-buildpackage:] * [:pbuilder-dist:] - [:chroot:]-Umgebung für Paketbau nutzen * [:Metapakete_erstellen:] * [:Open_Build_Service:] - Dienst zur Paketerstellung und -verwaltung == Extern == * [https://ubuntu-packaging-guide.readthedocs.io/en/latest/ubuntu-packaging-guide/ Ubuntu Packaging Guide] {en} * [https://canonical-ubuntu-packaging-guide.readthedocs-hosted.com/en/latest/ Ubuntu Packaging Guide von Canonical] {en} - wird derzeit überholt * [https://www.debian.org/doc/manuals/debmake-doc/ Leitfaden für Debian-Betreuer] {en} {de} - offizieller Leitfaden * [https://www.debian.org/doc/maint-guide/ Debian Packaging Guide] {en} {de} - alter Leitfaden * [http://debiananwenderhandbuch.de/debianpakete.html Packaging Guide im deutschen Debiananwenderbuch] {de} * [debian:DebianMentorsFaq:] {en} - Häufige Fragen und Antworten zum Paketieren für Debian-Systeme * [https://raphaelhertzog.com/2012/08/08/how-to-use-quilt-to-manage-patches-in-debian-packages/ "How to use quilt to manage patches in Debian packages"] {en} - lesenswerter Artikel zum Umgang mit `quilt` * [debian:Projects/DebSrc3.0: DebSrc3.0] {en} - Informationen zur Umstellung auf das Paketformat 3.0 * [https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Machine-readable debian/copyright file] {en} - Debian-Copyright-Format-Spezifikation # tag: Programmierung, Paketbau