5. An einem Paket arbeiten¶
Once you have the source package branch in a shared repository, you’ll want to create additional branches for the fixes or other work you plan to do. You’ll want to base your branch off the package source branch for the distro release that you plan to upload to. Usually this is the current development release, but it may be older releases if you’re backporting to an SRU for example.
5.1. Einen Zweig fuer eine Änderung erstellen¶
Das erste, was Du sicherstellen solltest, ist, ob das Quellpaket aktuell ist. Das wird so sein, wenn Du es gerade ausgecheckt hast, ansonsten:
$ cd tomboy.dev
$ bzr pull
Alle Aktualisierungen die das Paket vor Deinem Checkout erhalten hat, werden jetzt heruntergeladen. Es ist am Besten an diesem Branch keine Änderungen vorzunehmen. Stattdessen lohnt es sich einen neuen Branch anzulegen, der nur die Änderungen enthalten wird, die Du vornehmen möchtest. Zum Beispiel könntest Du Bug 12345 des Tomboy-Projekts beheben wollen. Wenn Du im Shared Repository bist, das Du vorher angelegt hast, kannst Du einen Bugfix-Branch folgendermaßen anlegen:
$ bzr branch tomboy.dev bug-12345
$ cd bug-12345
Jetzt kannst Du alle Arbeit im Verzeichnis bug-12345 erledigen. Du kannst dort alle nötigen Änderungen vornehmen und währenddessen committen. Es ist nicht anders als jede andere Software-Entwicklung mit Bazaar. Man kann committen so oft man möchte und wenn die Änderungen fertig sind, benutzt man einfach dch (aus dem Paket devscripts):
$ dch -i
Dies wird einen Editor öffnen um einen Eintrag in debian/changelog hinzuzufügen.
Sobald du einen Eintrag unter debian/changelog eingefügt hast, sollte eine Fehlerkennzeichen vorhanden sein, das deutlich macht welchen Fehler von Launchpad du gerade behebst. Das Format für das Kennzeichen ist stark eingeschränkt: LP: #12345. Das Leerzeichen zwischen : und dem # ist notwendig und natürlich sollte die tatsächliche Fehlernummer verwendet werden. Dein Eintrag unter debian/changelog sollte in etwa so aussehen:
tomboy (1.12.0-1ubuntu3) trusty; urgency=low
* Don't fubar the frobnicator. (LP: #12345)
-- Bob Dobbs <subgenius@example.com> Mon, 10 Sep 2013 16:10:01 -0500
Einreichen mit normal:
bzr commit
Ein Hook in bzr-builddeb wird den Eintrag aus debian/changelog in der Commit-Nachricht verwenden und ein Tag setzen, um Bug #12345 als behoben zu markieren.
Das funktioniert nur mit ‘bzr-builddeb 2.7.5’ und ‘bzr 2.4’, verwende debcommit für ältere Versionen.
5.2. Das Paket bauen¶
Währenddessen wirst deinen eigenen Zweig erstellen wollen, sodass du auch sicher gehen kannst, dass der Fehler auch behoben wurde.
Um das Paket zu bauen kann man das Kommando bzr builddeb (aus dem Paket bzr-builddeb) verwenden. Du kannst das Quellpaket folgendermaßen bauen:
$ bzr builddeb -S
(bd ist ein Alias für builddeb.) Du kannst das Paket unsigniert lassen, in dem Du -- -us -uc an das Kommando anhängst.
Es ist außerdem möglich, Deine normalen Werkzeuge zu verwenden, so lange sie nur das .bzr Verzeichnis aus dem resultierenden Paket entfernen können.
$ debuild -i -I
Falls jemals eine Fehlermeldung bezüglich dem Erstellen eines nativen Paketes ohne einen Tarball auftritt, überprüfe ob eine Datei mit dem Namen .bzr-builddeb/default.conf das Paket irrtümlich als nativ einstuft. Wenn die Version im Änderungsprotokoll einen Bindestrich enthält, dann ist es kein natives Paket und du kannst die Konfigurationsdatei entfernen. Merke dass obwohl bzr builddeb eine Option --native besitzt, ist keine Option --no-native vorhanden.
Wenn Du das Quellpaket heruntergeladen hast, kannst Du es ganz normal mit pbuilder-dist (oder pbuilder oder sbuilt) bauen.