ubuntuusers.de

Grundlagen der Paketerstellung

Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:


Du möchtest den Artikel für eine weitere Ubuntu-Version testen? Mitarbeit im Wiki ist immer willkommen! Dazu sind die Hinweise zum Testen von Artikeln zu beachten.

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-Service möglich, selbsterstellte Pakete öffentlich anzubieten. Aber auch das lokale Erstellen von Paketen für noch nicht paketisierte 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.

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 eines Quellpaketes fortgefahren werden.

Vorbereitung

Um alle wichtigen Programme zum Paketbau herunterzuladen, kann einfach das Paket packaging-dev installiert [1] werden.

Für diese Einführung werden folgende Pakete mit ihren Abhängigkeiten benötigt:

  • build-essential

  • debhelper

  • dh-make

  • quilt

  • devscripts

Befehl zum Installieren der Pakete:

sudo apt-get install build-essential debhelper dh-make quilt devscripts 

Oder mit apturl installieren, Link: apt://build-essential,debhelper,dh-make,quilt,devscripts

Herstellen einer Arbeitsumgebung

Bevor der eigentliche Paketbau eines Programmes 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 des Verzeichnis gewechselt:

mkdir gnu-hello
cd gnu-hello 

Nun wird das Quellarchiv des Programmes heruntergeladen und entpackt:

wget http://ftp.gnu.org/gnu/hello/hello-2.7.tar.gz
tar -xvzf hello-2.7.tar.gz 

Erstellen der Debian-Dateien

Die Debian-Dateien, welche zum Paketieren nötig sind, werden nun mit dem Programm dh_make erstellt.

Hinweis:

Um sich die Arbeit des Eingebens von E-Mail-Adresse und Maintainername zu sparen, können diese als lokale Umgebungsvariablen deklariert werden:

export DEBFULLNAME="VORNAME NACHNAME"
export DEBEMAIL="EMAIL@ADRESSE" 

Diese Angaben können z.B. in der Datei ~/.profile dauerhaft gespeichert werden.

Es wird nun in das Verzeichnis des entpackten Quellarchivs, also des Quellcodes, gewechselt:

cd hello-2.7/ 

Dort werden nun mit dh_make die Vorlagedateien angelegt.

dh_make -f ../hello-2.7.tar.gz 

Hinweis:

Hier können noch mehr Optionen, wie z.B. Emailadresse, Lizenz oder Art des Paketes übergeben werden. Siehe dazu die Manpage von dh_make.

Nach dem Ausführen des Befehls werden nun einige Fragen gestellt:

Type of package: single binary, indep binary, multiple binary, library, kernel module, kernel patch?
 [s/i/m/l/k/n]

Es wird also gefragt, ob ein einzelnes Binär-Paket, ein architekturunabhängiges Paket, mehrere Binär-Pakete, eine Bibliothek, ein Kernelmodul oder ein Kernelpatch paketiert werden soll. Da es sich bei GNU hello um ein einzelnes Programm mit nur einer Binär-Datei handelt, wird die Frage mit dem Drücken der S -Taste beantwortet.

Abschließend werden einige Informationen zum Ersteller und dem Paket angezeigt:

Maintainer name : VORNAME NACHNAME
Email-Address   : EMAIL@ADRESSE
Date            : DATUM UHRZEIT +/-UTC-DIFFERENZ
Package Name    : PAKETNAME
Version         : PAKETVERSION
License         : LIZENZ
Type of Package : PAKETTYP
Hit <enter> to confirm:

Nach einer Bestätigung mit werden die Steuerungsdateivorlagen unter debian/ erstellt und das Quellarchiv an die für das Quellformat nötige Stelle ../hello_2.7.orig.tar.gz kopiert.

Bearbeiten der Debian-Dateien

Nachdem die Steuerungsdaten nun im Unterordner debian/ erstellt wurden, liegen diese auf die Gesamtstrukutur bezogen unter gnu-hello/hello-2.7/debian. In diesen Ordner wird nun gewechselt:

cd debian/ 

Dort befinden sich einige Dateien und ein Ordner source/:

gnu-hello/hello-2.7/debian$ ls
changelog           emacsen-startup.ex  manpage.sgml.ex  README.Debian
compat              hello.cron.d.ex     manpage.xml.ex   README.source
control             hello.default.ex    menu.ex          rules
copyright           hello.doc-base.EX   postinst.ex      source
docs                info                postrm.ex        watch.ex
emacsen-install.ex  init.d.ex           preinst.ex
emacsen-remove.ex   manpage.1.ex        prerm.ex
gnu-hello/hello-2.7/debian$ dir source/
format

Die Dateien werden in zwei Klassen unterteilt: Optionale Dateien, die nur unter bestimmten Umständen nötig sind, sie besitzen die Endung .ex bzw. .EX. Die übrigen Dateien sind idR. zwingend erforderlich, um ein Quellpaket erstellen zu können.

Hinweis:

In diesem Beispiel wurden von dh_make im Quellverzeichnis die Dateien ChangeLog.O und doc/hello.info als zusätzlicher Changelog bzw. als Infoseite erkannt und deswegen im Debianverzeichnis die Datei docs und info angelegt. Diese Dateien sind aber nicht allgemein zwingend erforderlich.

Bei den meisten Programmen wird ein Großteil der optionalen Dateien nicht benötigt. Eine kurze Übersicht erfolgt unter Weitere (optionale) Konfigurationsdateien. Eine ausführlichere Erklärung und Hinweise zur Benutzung finden sich unter Kapitel 5. Andere Dateien im Verzeichnis debian 🇩🇪 🇬🇧 des Leitfadens für neue Debian-Betreuer 🇩🇪 🇬🇧 oder auf der entsprechenden Manpage der debhelper-Skripte.

Hinweis:

Es ist auch hilfreich, sich ein Programm anzuschauen, das diese Dateien verwendet, bevor man selbst ein solches Programm paketieren möchte. Kurz gesagt kann man mit ihnen Shell-Skripte ausführen, entweder vor der Installation, nach der Installation oder auch vor oder nach dem Deinstallieren eines Debian-Paketes. Man kann einen 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:

rm *.ex *.EX README.Debian README.source 

Danach sollten nur noch diese Dateien übrig bleiben:

gnu-hello/hello-2.7/debian$ dir
changelog  compat  control  copyright  docs  info  rules  source

Die wichtigen Dateien, die mit einem Texteditor [3] generell angepasst werden müssen, sind: changelog, compat, control, copyright, rules und source/format, wobei meist die Standardvorgabe von compat und 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 Kapitel 4. Benötigte Dateien im Verzeichnis debian 🇩🇪 🇬🇧 im Leitfaden für neue Debian-Betreuer 🇩🇪 🇬🇧.

changelog

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

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 hier.

Die changelog-Datei ist in der folgenden Form:

1
2
3
4
5
hello (2.7-1) unstable; 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. An dieser Stelle ist der Artikel Versionsnummern von Ubuntu-Paketen empfehlenswert.

  • 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 unstable. Dies kann man mit der Version von Ubuntu ersetzen für die das Paket erstellt werden soll. Solange das Paket noch nicht fertiggestellt ist, sollte hier der Wert UNRELEASED stehen.

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

Ein Beispiel kann also wie folgt aussehen:

1
2
3
4
5
hello (1:2.7-1~0ubuntu1) precise; urgency=low

  * Erster Paketbau.

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

Leerzeichen und Leerzeilen sind entsprechend dem Beispiel zu setzen.

Hinweis:

Es ist darauf zu achten, dass sich zwischen Email-Adresse und Datum exakt 2 Leerzeichen befinden.

Die Mail-Adresse wird von den Zeichen "<" und ">" eingerahmt.

compat

Die compat-Datei bestimmt den debhelper-Kompatibilitätsmodus, also bestimmte Funktionalitäten der debhelper-Skripte beim Erstellen der Pakete. Zur Zeit liegt die neuste abgeschlossene Version bei v13. Diese ist allerdings nicht in allen Ubuntuversionen aufgrund einer niedrigeren Version von debhelper verfügbar. Als Vorlage wird von dh_make jeweils die Version genommen, welche zum Erscheinungszeitpunkt der momentan genutzten Ubuntuversion die aktuellste Abgeschlossene war. Um den Kompatibilitätsmodus manuell festzulegen, wird die jeweilige Versionsnummer als alleinstehende Zahl in die Datei compat geschrieben.

Informationen zu den verschiedenen auf dem aktuellen System verfügbaren Kompatibilitätsmodi finden sich in der Übersichts-Manpage des Paketes debhelper.

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
Source: hello
Section: unknown
Priority: extra
Maintainer: VORNAME NACHNAME <EMAIL@ADRESSE>
Build-Depends: debhelper (>= 8.0.0), autotools-dev
Standards-Version: 3.9.5
Homepage: <insert the upstream URL, if relevant>
#Vcs-Git: git://git.debian.org/collab-maint/hello.git
#Vcs-Browser: http://git.debian.org/?p=collab-maint/hello.git;a=summary

Package: hello
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: <insert up to 60 chars description>
 <insert long description, indented with spaces>

Die Felder besitzen folgende Bedeutung.

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

Hinweis:

Unter https://packages.ubuntu.com/jammy/ 🇬🇧 kann am Beispiel der Ubuntuversion Jammy 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.
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:

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.

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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
Source: hello
Section: misc
Priority: optional
Maintainer: VORNAME NACHNAME <EMAIL@ADRESSE>
Build-Depends: debhelper (>= 8.0.0), autotools-dev
Standards-Version: 3.9.5

Package: hello
Architecture: any
Depends: ${shlibs:Depends}, ${misc: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).

In die copyright-Datei gehören die Lizenzbestimmungen des Programms. Mit 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.

Folgendes Beispiel ist nun anzupassen:

 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
Format: http://dep.debian.net/deps/dep5
Upstream-Name: hello
Source: <url://example.com>

Files: *
Copyright: <years> <put author's name and email here>
           <years> <likewise for another author>
License: <special license>
 <Put the license of the package here indented by 1 space>
 <This follows the format of Description: lines in control file>
 .
 <Including paragraphs>

# If you want to use GPL v2 or later for the /debian/* files use 
# the following clauses, or change it to suit. Delete these two lines
Files: debian/*
Copyright: JAHR VORNAME NACHNAME <EMAIL@ADRESSE>
License: GPL-2+
 This package is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
 the Free Software Foundation; either version 2 of the License, or
 (at your option) any later version.
 .
 This package is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.
 .
 You should have received a copy of the GNU General Public License
 along with this program. If not, see <http://www.gnu.org/licenses/>
 .
 On Debian systems, the complete text of the GNU General
 Public License version 2 can be found in "/usr/share/common-licenses/GPL-2".

# Please also look if there are files or directories which have a
# different copyright/license attached and list them here.

Nach Anpassung wird daraus der Inhalt folgender Form:

 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
Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: hello
Source: http://ftp.gnu.org/gnu/hello/hello-2.7.tar.gz

Files: *
Copyright: 1992-2011 Free Software Foundation, Inc.
License: GPL-3+

Files: debian/*
Copyright: JAHR VORNAME NACHNAME <EMAIL@ADRESSE>
License: GPL-3+

License: GPL-3+
 This package is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
 the Free Software Foundation; either version 2 of the License, or
 (at your option) any later version.
 .
 This package is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.
 .
 You should have received a copy of the GNU General Public License
 along with this program. If not, see <http://www.gnu.org/licenses/>
 .
 On Debian systems, the complete text of the GNU General
 Public License version 3 can be found in "/usr/share/common-licenses/GPL-3".

rules

Die rules-Datei ist ein Makefile, 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 dh_make erstellte Vorlage hat den selben nicht auskommentierten Inhalt:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
#!/usr/bin/make -f
# -*- makefile -*-
# Sample debian/rules that uses debhelper.
# This file was originally written by Joey Hess and Craig Small.
# As a special exception, when this file is copied by dh-make into a
# dh-make output file, you may use that output file without restriction.
# This special exception was added by Craig Small in version 0.37 of dh-make.

# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1

%:
	dh $@

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_*
debhelper-Skript Befehl im Quellcode sofern Ziel und Makefile bzw. configure-Skript existieren
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 $@

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.

Hinweis:

Kompilieroptionen wie Compiler-Flags oder Makeoptionen können wie in einem Makefile gesetzt werden. Eine ausführliche Dokumentation findet sich im GNU make manual 🇬🇧.

Experten-Info:

Lokale Buildflags können für alle lokalen Paketerstellungen in der Datei ~/.config/dpkg/buildflags.conf festgelegt werden, systemweite unter /etc/dpkg/buildflags.conf.

In dem gezeigten Beispiel, muss die rules-Datei nicht angepasst werden.

Eine detaillierte Erklärung findet man unter 4.4. rules 🇩🇪 🇬🇧 im Leitfaden für neue Debian-Betreuer 🇩🇪 🇬🇧.

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:

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

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)

dh_make 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.

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.

Patchen

Im Folgenden wird beschrieben, einen Patch mit quilt am Beispiel GNU hello zu erstellen.

Damit das Paket am Ende so "sauber" wie möglich ist, dh. keine Policy-Verletzungen oder Programmfehler aufweist, muss das Paket gepatcht werden, sofern diese Änderungen nicht vom Ursprung des Quellcodes (Upstream) geändert werden.

Wird folgender Patch von Santiago Vila nicht angewandt, tritt eine Richtlinenverletzung auf, da durch das Makefile relativ zur Quellcodewurzel unter doc/Makefile eine Datei /usr/share/info/dir.gz angelegt wird. Diese soll aber automatisch während der Installation angelegt werden.

Also ist das Makefile zu bearbeiten. Das Arbeitsverzeichnis sollte nun eine Ebene über dem debian/-Verzeichnis, also das Quellcodeverzeichnis selbst sein (der Prompt sieht in etwa wie gnu-hello/hello-2.7 $ aus).

Die aktuelle Version von quilt (Ubuntu 15.10) legt den Ordner Patches nicht unter debian/patches an sondern im Source-Verzeichnis. Da dies aber bei der Verwendung von dpkg-buildpackage (siehe unten) zusätzliche Konfigurationen nach sich ziehen würde, wird stattdessen eine Alias-Befehl mit zusätzlichen Optionen angelegt, die den Standard-Pfad wieder korrekt setzten. Da die Option vielleicht nicht dauerhaft das Verhalten von quilt beeinflussen soll, wird der alias "uquilt" gewählt.

1. Editieren der Datei ~/.bashrc mit einem Editor dabei sind die folgenden Zeile einzufügen:

alias uquilt="quilt --quiltrc=${HOME}/.quiltrc-dpkg"
complete -F _quilt_completion $_quilt_complete_opt uquilt 

Diese Option legt fest, dass uquilt die Konfigurationen aus ~/.quiltrc-dpkg verwendet.

2. Mit einem Editor die Datei ~/.quiltrc-dpkg anlegen und folgenden Inhalt einfügen:

d=. ; while [ ! -d $d/debian -a `readlink -e $d` != / ]; do d=$d/..; done
if [ -d $d/debian ] && [ -z $QUILT_PATCHES ]; then
    # falls in Debian-Paketbaum mit ungesetztem $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"
    if ! [ -d $d/debian/patches ]; then mkdir $d/debian/patches; fi
fi

Nun wird, sofern der Ordner debian existiert, der Ordner patches dort angelegt.

Um quilt den Namen des neuen Patches mitzuteilen, wird folgender Befehl verwendet:

uquilt new 01-no-usr-share-info-dir-gz 

Anschließend wird die Datei doc/Makefile.in als Vorlagedatei des fehlerhaften Makefiles als zu bearbeitende Datei hinzugefügt:

uquilt add doc/Makefile.in 

Nun wurde eine Kopie der Datei unter .pc/01-no-usr-share-info-dir-gz/doc/Makefile.in angelegt (Sicherungskopie). Die Datei doc/Makefile.in kann nun bearbeitet werden ohne dass der Inhalt der ursprünglichen Datei verlorgen geht.

Nach den Änderungen an der Datei kann der Patch so gespeichert werden:

uquilt refresh 

Übernommen werden kann der Patch mit:

uquilt push -a 

Damit wird das Makefile auf den ursprünglichen Stand zurückversetzt und die Änderung nur im Patch gespeichert. Die Vorbereitung zur Paketierung wurde für das Beispiel GNU hello abgeschlossen und es kann nun ein Binärpaket erstellt 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.

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 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 Kapitel 3. Den Quellcode verändern 🇩🇪 🇬🇧 aus dem Leitfaden für neue Debian-Betreuer 🇩🇪 🇬🇧 werden einige konkrete Anwendungsfälle betrachtet.

Erstellung des Quellpaketes

Im Quellcodeverzeichnis wird folgender Befehl zum Bau des Quellpakets angewandt:

dpkg-buildpackage -S -us -uc 

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, sollten diese beiden Optionen nicht genutzt werden, sodass eine Signierung erfolgt.

Im übergeordneten Verzeichnis wurden nun beide Quelldateien, sowie bei einem nicht-nativen Quellformat ein Archiv mit den Debian-Änderungen angelegt. Die Datei der Endung sources.changes 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.

Überprüfen des Paketes

Die verschiedenen Paketdateien 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_source.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.

Erstellung des Binärpaketes

Ähnlich wie beim Quellpaket wird dazu das Perlskript dpkg-buildpackage genutzt:

dpkg-buildpackage -us -uc 

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 gpg [4]):

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 - 

Hinweis:

Soll das Paket nicht nur für die lokale Verwendung erstellt werden, empfiehlt sich die Paketerstellung mit pbuilder-dist.

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:

fakeroot debian/rules binary 

Experten-Info:

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 debian/rules auslesen lassen, allerdings haben sich folgende vier durchgesetzt: nocheck, noopt, nostrip, parallel=n (siehe dazu in der Ubuntu-Policy unter 4.9.1 debian/rules and DEB_BUILD_OPTIONS 🇬🇧)

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:

export DEB_BUILD_OPTIONS="parallel=6" 

Alternativ kann dies mit der Option -j direkt dem Programm dpkg-buildpackage übergeben werden:

dpkg-buildpackage -j6 

Angegebene, aber nicht unterstützte Build-Optionen werden ignoriert.

Intern

Extern

Diese Revision wurde am 7. September 2023 16:56 von karzer erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: Paketbau, Programmierung