quilt einrichten¶

quilt – nur für das 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 Alias-Befehl mit zusätzlichen Optionen 🇩🇪 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:

1
2
3

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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

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.

changelog¶

In dieser Datei werden Veränderungen zwischen den einzelnen Paketversionen (changes) dokumentiert.

Die changelog-Datei ist in der folgenden Form:

1
2
3
4
5
6

hello (2.7-1) UNRELEASED; urgency=low

  * Initial release. Closes: #nnnn
    <nnnn is the bug number of your ITP>

 -- VORNAME NACHNAME <EMAIL@ADRESSE>  DATUM UHRZEIT +/-UTC-DIFFERENZ

In der erste Zeile steht am Anfang das Programm und die Version.

• 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:

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 Manpage von dch.

Ein Beispiel kann also wie folgt aussehen:

1
2
3
4
5

hello (1:2.7-1~0ubuntu1) noble; urgency=low

  * Initial packaging.

 -- VORNAME NACHNAME <EMAIL@ADRESSE>  DATUM UHRZEIT +/-UTC-DIFFERENZ

Leerzeichen und Leerzeilen sind entsprechend dem Beispiel zu setzen.

control¶

Die control-Datei stellt bei einem fertigen Debianpaket die Kontrollinformationen bereit und wurde in diesem Beispiel mit folgendem Vorlageninhalt erstellt:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

Source: hello
Section: unknown
Priority: optional
Maintainer: VORNAME NACHNAME <EMAIL@ADRESSE>
Build-Depends: debhelper-compat (= 13), dh-autoreconf
Standards-Version: 4.6.1
Homepage: <insert the upstream URL, if relevant>
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 Debian Policy Manual, "Debian source package template control files" 🇬🇧 nachlesen.

Weitere optionale Zeilen sind unter anderem:

Für das Beispiel sieht eine vollständige control-Datei folgendermaßen aus:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

Source: hello
Section: misc
Priority: optional
Maintainer: VORNAME NACHNAME <EMAIL@ADRESSE>
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 Debian Copyright Format 1.0 🇬🇧 (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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

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 <EMAIL@ADRESSE>
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 debhelper-Skripte 🇬🇧 🇩🇪 ist die Erstellung meist ziemlich einfach, denn es reicht meist schon folgender Inhalt:

1
2
3

#!/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):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

#!/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:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167

#!/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:

dh_auto_clean 

make distclean 

dh_auto_configure 

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var 

dh_auto_build 

make 

dh_auto_test 

make test 

dh_auto_install 

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:

1
2
3
4
5
6
7

#!/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.

Da die Bau-Prozedur nicht von der 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 4.4. rules 🇩🇪 🇬🇧 im alten Leitfaden 🇩🇪 🇬🇧.

1
2
3

#!/usr/bin/make -f
%:
	dh $@ --buildsystem=qmake_qt4

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:

1

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 Optionale Konfigurationsdateien. Empfehlenswert ist beispielsweise die Konfiguration des Werkzeugs uscan in watch, was den Aufwand für die Aktualisierung des Paketes auf eine neuere Version verringert.

Ü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:

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 Quellpakets angewandt:

debuild -S -us -uc --lintian-opts <lintian-Optionen> 

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¶

Das geschieht durch folgenden Befehl:

debuild -us -uc --lintian-opts <lintian-Optionen> 

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-Datei festgeleten Abhängigkeiten zum Paketbau durchgeführt (ohne Signieren der Quellkontroll- und Steuerungsdatei mittels GnuPG):

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 - 

fakeroot debian/rules binary 

export DEB_BUILD_OPTIONS="parallel=6" 

dpkg-buildpackage -j6 

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 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 Arbeitsablauf des Paketierens 🇩🇪 🇬🇧 im offiziellen Leitfaden 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-Format heruntergeladen werden:

• 01-no-usr-share-info-dir.patch ⮷ Vermeidet die Richtlinenverletzung, die durch das Anlegen der Datei /usr/share/info/dir.gz relativ zur Quellcodewurzel durch das Makefile doc/Makefile entstand.

• 02-repair-tests.patch ⮷ 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 "Patch Tagging Guidelines" (DEP 3) 🇬🇧 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 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 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:

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:

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:

dquilt refresh 

5. Nun können, falls erforderlich, noch Metadaten in Form eines Headers zum Patch hinzugefügt werden. Dieser wird gemäß dem Standard "Patch Tagging Guidelines" (DEP 3) 🇬🇧 formatiert. Ein Header für den vorliegenden Patch könnte folgendermaßen aussehen:

From: Santiago Vila <sanvila@debian.org>
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:

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:

dquilt pop -a 

7. Da auch die eingebauten Tests im Verlauf des Paketbaus nicht funktionieren, muss noch eine weiterere Anpassung vorgenommen werden:

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.

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 gesamte Paketbau wiederholt werden.

quilt-Bedienung¶

quilt bietet eine einem 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 Manpage von quilt.

In Kapitel 3. Den Quellcode verändern 🇩🇪 🇬🇧 aus dem Leitfaden für neue Debian-Betreuer 🇩🇪 🇬🇧 werden einige konkrete Anwendungsfälle betrachtet.

Intern¶

• 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¶

• Ubuntu Packaging Guide 🇬🇧

  • Ubuntu Packaging Guide von Canonical 🇬🇧 - wird derzeit überholt

• Leitfaden für Debian-Betreuer 🇬🇧 🇩🇪 - offizieller Leitfaden

  • Debian Packaging Guide 🇬🇧 🇩🇪 - alter Leitfaden

• Packaging Guide im deutschen Debiananwenderbuch 🇩🇪

• DebianMentorsFaq 🇬🇧 - Häufige Fragen und Antworten zum Paketieren für Debian-Systeme

• "How to use quilt to manage patches in Debian packages" 🇬🇧 - lesenswerter Artikel zum Umgang mit quilt

• DebSrc3.0 🇬🇧 - Informationen zur Umstellung auf das Paketformat 3.0

• Machine-readable debian/copyright file 🇬🇧 - Debian-Copyright-Format-Spezifikation