[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ weiter ]
Nun sollten Sie soweit sein, das Paket zu "bauen".
Wechseln Sie nun in das Verzeichnis des Programms und führen Sie das folgende Kommando aus:
dpkg-buildpackage -rfakeroot
Das wird alles für Sie erledigen. In Einzelnen:
Aufräumen des Quell-Verzeichnisbaumes (debian/rules clean), mittels
fakeroot,
Bauen des Quell-Pakets (dpkg-source -b),
Bauen des Programms (debian/rules build,)
Bauen des Binär-Pakets (debian/rules binary), mittels fakeroot,
signieren der Quell-Datei `*.dsc', mittels gnupg,
erstellen und signieren der Upload-Datei `.changes', mittels
dpkg-genchanges und gnupg.
Sie müssen nur zweimal Ihr Passwort für den GPG-Schlüssel eingeben.
Nachdem das erledigt ist, werden Sie folgende Dateien im darüberliegenden
Verzeichnis (~/gentoo/) vorfinden:
gentoo_0.9.12.orig.tar.gz
Dies ist der ursprüngliche Quellcode-Tarball, lediglich umbenannt, um dem Debian-Standard zu genügen.
gentoo_0.9.12-1.dsc
Dies ist eine Zusammenfassung des Inhalts des Quellcode-Pakets. Sie wird aus
Ihrer Datei `control' generiert und für das Entpacken des Quellcodes mittels
dpkg-source(1) benötigt. Diese Datei ist mit GPG signiert, somit
können sich die Leute vergewissern, dass sie von ihnen kommt.
gentoo_0.9.12-1.diff.gz
Diese komprimierte Datei enthält alle Zusätze und Änderungen, die Sie mit
dem ursprünglichen Quellcode gemacht haben, im Format, das als "unified
diff" bekannt ist. Die Datei wird erstellt und benutzt von
dpkg-source(1). Wenn Sie den originalen Tarball nicht
`paketname_version.orig.tar.gz' genannt haben, wird dpkg-source
bei der Generierung der Datei `*.diff.gz' scheitern!
Wenn jemand Ihr Paket von Grund auf neu bauen will, kann er die drei o.g. Dateien dazu verwenden. Das Verfahren ist trivial: kopieren Sie einfach die drei Dateien in ein Verzeichnis und starten Sie `dpkg-source -x gentoo_0.9.12-1.dsc`.
gentoo_0.9.12-1_i386.deb
Das ist Ihr fertiges Binär-Paket. Sie können es mit dpkg
installieren und wieder entfernen wie jedes andere Paket auch.
gentoo_0.9.12-1_i386.changes
Diese Datei beschreibt die Änderungen in dieser Paket-Revision. Die Verwaltungsprogramme für Debians FTP-Archive benötigen diese Datei zur Installation der Binär- und Quellcode-Pakete ins FTP-Archiv. Sie wird zum Teil aus den Dateien `changelog' und `*.dsc' generiert. Diese Datei ist GPG-signiert, so dass man sicher sein kann, dass sie wirklich von Ihnen ist.
Wenn Sie weiter an dem Paket arbeiten, wird sich das Verhalten ändern und Sie werden neue Funktionen hinzufügen. Leute, die Ihr Paket herunterladen, können sich die Datei ansehen und feststellen, was sich geändert hat. Das Debian-Archiv-Verwaltungsprogramm wird den Inhalt dieser Datei auch an die debian-devel-changes Mailingliste schicken.
Die langen Zahlenreihen in den Dateien `*.dsc' und `.changes' sind
MD5-Prüfsummen dieser Dateien. Jemand, der Ihr Paket herunterlädt, kann die
enthaltenen Dateien mit md5sum(1) testen und wenn die Zahlen nicht
übereinstimmen, weiß er, die geprüfte Datei ist beschädigt oder
manipuliert.
Debian supports many ports with the autobuilder network
running buildd daemons on many different architecture computers.
Although you do not need to do this by yourself, you should be aware of what
will happen on your packages. Let's look into roughly how your packages are
rebuild for many different architectures by them. [33]
For "Architecture: any" packages, the autobuilder system rebuild them. It ensures to install
the build-essential package, and
packages listed in the Build-Depends field (see Die Datei control, Abschnitt
4.1).
Then it issues the following command in the source directory:
$ dpkg-buildpackage -B
This will do everything to make architecture dependent binary packages on another architecture. It will:
clean the source tree ("debian/rules clean")
build the program ("debian/rules build")
build architecture dependent binary packages ("fakeroot debian/rules binary-arch")
sign the source .dsc file, using gpg
create and sign the upload .changes file, using
dpkg-genchanges and gpg
This is why you see your package for other architectures.
Although packages listed in the Build-Depends-indep field are
required to be installed for the normal packaging by us (see Kompletter Neubau, Abschnitt 6.1), they are not
required to be installed for the autobuilder system since it build only
architecture dependent binary packages. [34] This difference between normal packaging and autobuilder
situation dictates whether you record such required packages in the
Build-Depends or Build-Depends-indep fields of the
debian/control file (see Die
Datei control, Abschnitt 4.1).
Bei einem großen Paket wollen Sie bestimmt nicht alles nach jeder kleiner
Änderung in debian/rules neu kompilieren. Für Testzwecke
können Sie ein .deb erstellen, ohne alle Schritte durchzumachen, z.B. so:
fakeroot debian/rules binary
Wenn Sie mit Ihren Anpassungen fertig sind, vergessen Sie nicht, nach der kompletten Prozedur das Paket endgültig zu bauen. Sie werden Pakete, die auf diese Weise gebaut sind, nicht korrekt hochladen können.
debuild
Sie können das Paketbauen in Zukunft mit dem Kommando debuild
automatisieren. (siehe debuild(1))
Das Kommando debuild kann in den Dateien
/etc/devscripts.conf oder ~/.devscripts
benutzerbezogen angepasst werden. Die folgenden Einträge sind mindestens
empfohlen:
DEBSIGN_KEYID="Ihre_GPG_Schlüssel_ID"
DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -ICVS -I.svn"
Damit werden Ihre gebauten Pakete immer mit Ihrem GPG-Schlüssel signiert und es werden unerwünschte Dateien und Verzeichnisse im Paket verhindert. (Das ist auch für Sponsoren geeignet.) Beispielsweise ist das Säubern des Quellverzeichnisses und Neubauen des Pakets als Benutzer so einfach, wie:
debuild clean
debuild
dpatch-System
Die einfach zu nutzenden Kommandos dh_make und
dpkg-buildpackage erstellen eine große Datei
*.diff.gz, die alle Dateien für die Paketbetreuung in
debian/ und Patch-Dateien für den Quellcode enthält. So ein
Paket ist sehr mühselig zu kontrollieren und jede Änderung des Quellcodes ist
später schwer zu verstehen. Das ist nicht so schön. [35]
Verschiedene Möglichkeiten der Betreuung von Patch-Sets wurden vorgeschlagen
und werden in Debian verwendet. Das dpatch-System ist eines der
einfachsten. Andere sind dbs, cdbs, etc.
Ein Paket, das ordentlich mit dem dpatch-System erstellt wurde,
enthält die Änderungen des Quellcodes klar dokumentiert als Patch-Set-Dateien
in debian/patches/ und der Quellcode außerhalb des Verzeichnisses
debian/ bleibt unberührt. Wenn Sie Ihren Sponsor bitten, Ihr
Paket hochzuladen, ist diese klare Trennung und Dokumentation Ihrer Änderungen
für die zügige Überprüfung des Pakets durch Ihren Sponsor sehr wichtig.
Der Umgang mit dpatch wird in dpatch(1) erklärt.
Wenn Ihnen jemand (einschließlich Ihnen selbst) später einen Patch für den
Quellcode zur Verfügung stellt, ist die Anpassung des Pakets mit
dpatch recht einfach:
Patch anpassen, zu einem "-p1"-Patch zum Quellcode machen.
Kopfzeilen mit dem Kommando dpatch patch-template hinzufügen.
Im Verzeichnis debian/patches ablegen.
Den Dateinamen in die debian/patches/00list schreiben.
dpatch bietet auch die Möglichkeit, Patches durch das CPP-Macro
architekturabhängig zu machen.
*.orig.tar.gz beim Hochladen
Wenn Sie das Paket zum ersten Mal in das Archiv hochladen, müssen Sie die
Original-Quellen *.orig.tar.gz einbeziehen. Wenn die Paketversion
nicht eine -0 oder -1 als Debian-Revisionsnummer hat,
müssen Sie dem Kommando dpkg-buildpackage die Option
"-sa" mitgeben. Dem gegenüber erzwingt die Option
"-sd" den Ausschluss der Original-Quellen
*.orig.tar.gz.
[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ weiter ]
Anleitung für zukünftige Debian-Betreuer
Diese Übersetzung wird derzeit aktualisiert. Teile beruhen auf Version 1.2.3 vom 18. Januar 2005, die aktuelle Version ist 1.2.25, 2010-12-22 12:44:34 UTCjoy-mg@debian.orgtoddy@debian.orgmail@erikschanze.deblade@debian.org