openSUSE:Paketbau Richtlinien für Patches
Inhaltsverzeichnis
Patch markup (ebenso als "Tagging patches" bezeichnet)
Um leichter automatische Werkzeuge zu verwenden -- und zukünftigen Paketbauern zu helfen -- sind wir überein gekommen, folgende Kategorien für unsere Patches zu verwenden:
- Fixes: Das sind normale Fehlerbereinigungen und sind in zwei Kategorien geteilt:
- Fixes für openSUSE-spezifische Sachen, woran Upstream-Maintainer nicht interessiert sind.
- Fixes für SLE-spezifische Sachen, woran Upstream-Maintainer nicht interessiert sind und die in openSUSE nicht benötigt werden.
- Fixes für die Upstream-Quellen sollten weiter gereicht werden.
- Features: Neue Funktionen, die zu den Paketen hinzugefügt werden, sind ebenso in zwei Kategorien unterteilt:
- Funktionen für openSUSE-spezifische Sachen (AppArmor Integration, zum Beispiel) ohne Interesse für Upstream-Maintainer.
- Funktionen für SLE-spezifische Sachen ohne Interesse für Upstream-Maintainer oder openSUSE.
- Funktionen sollten weitergereicht werden. Wenn immer wir diese Art von neuer Funktion schreiben, ist es wichtig das mit den Upstream-Maintainer zu koordinieren. Auf diese Weise können wir etwas entwickeln, das ohne Änderungen akzeptiert wird. Wenn eine Funktion fertig ist, ist es eine Menge Arbeit sie so zu überarbeiten, dass sie für den Upstream-Maintainer akzeptabel ist. Darum ist es besser, von Anfang an zu wissen, was die Upstream-Maintainer erwarten würden.
Um unsere Patches zu kennzeichnen, um dieser Übereinkunft zu folgen, kamen wir mit einem Standard, um sie in der .spec Datei zu kennzeichnen, folgen Sie dem unteren Format:
# PATCH-FIX-OPENSUSE fix-for-opensuse-specific-things.patch [bnc#123456] Patch1: fix-for-opensuse-specific-things.patch # PATCH-FIX-SLE fix-for-sle-specific-things.patch [bnc#123456] Patch2: fix-for-sle-specific-things.patch # PATCH-FIX-UPSTREAM fix-for-upstream-sources.patch [bnc#123456] Patch3: fix-for-upstream-sources.patch # PATCH-FEATURE-OPENSUSE feature-for-opensuse-specific-things.patch [bnc#123456] Patch4: feature-for-opensuse-specific-things.patch # PATCH-FEATURE-SLE feature-for-sle-specific-things.patch [bnc#123456] Patch5: feature-for-sle-specific-things.patch # PATCH-FEATURE-UPSTREAM feature-for-upstream.patch [bnc#123456] Patch6: feature-for-upstream.patch
Spezialfall: Wir haben oft Patches, die zeitweise auskommentiert werden, weil sie die neuesten Quellen nicht anwenden konnten und die Patches mussten umgebaut werden. Kommentieren Sie die patch’s Erklärung nicht aus, sondern ihre Anwendung. Wenn ein Patch gekennzeichnet ist, dass es umgebeut werden muss, ist es eine gute Idee seine alte Markierung (Tag) zu behalten.
# PATCH-NEEDS-REBASE old-patch.patch [bnc#123456] -- Does something old. Was: PATCH-FEATURE-OPENSUSE Patch7: old-patch.patch [...] # %patch7
Schließlich fügen wir eine e-Mailadresse hinzu, so dass es leichter ist, heraus zu bekommen, wer schrieb einen Patch, wenn wir später Fragen dazu haben, ebenso Kommentare im freien Format nach "--".
Das ist:
# PATCH-{FIX|FEATURE}-{OPENSUSE|SLE|UPSTREAM} name-of-file.patch bnc#[0-9]* you@example.com -- dieses Patch macht die Sachen total fantastisch
Wenn es darauf bezogene Fehler unter Novell oder anderen Bugzillas gibt, fügen sie diese bitte hinzu. Es wird uns helfen, genauere Informationen zu erhalten. Wenn es zwei oder mehr gibt, dann ist es vorteilhaft beide (oder mehr) aufzulisten.
Sie können den momentanen Satz an Abkürzungen am Ende dieses Dokumentes finden. Wir können später mehr Abkürzungen definieren, wenn sie sich als notwendig erweisen.
Einige Patches beheben Fehler, über die nicht irgendwo explizit berichtet wird. In diesem Fall, die richtigen Sachen zu machen erfordert etwas Urteilsvermögen seitens des Paketbauers. Aber es gibt da ein paar Hinweise:
- Wenn ein Release bevorsteht, erzeuge einen Fehler dafür. Das ist gewöhnlich eine Anforderung, und wenn es das nicht wäre, ist es noch das Richtige zu tun.
- Wenn ein Release noch weit weg ist und ein Fehler wurde bereits upstream behoben, notieren Sie es im Kommentar, dass er bereits in SVN behoben ist (oder wo auch immer) und der Patch wird beseitigt, wenn wir die nächste Aktualisierung machen.
Patch-Bezeichnung
Alle neuen Patches sollten mit der Erweiterung '.patch' enden.
Ob die Bezeichnung eines Patches mit dem Namen des Paketes für das es gilt beginnen sollte ist eine Sache der Beratung oder des Stils. Wenn Sie unsicher sind, folgen Sie den Regeln, die im Paket verwendet werden, dass Sie bearbeiten.
Verwenden Sie NICHT das %{version} Makro in der Patch: Zeile. Spezifizieren Sie die Version per Hand. Die Verwendung des Makros:
- verursacht eine Menge Umbenennungen bei der Versionsaktualisierung
- macht es leichter Patches zu übersehen, die nicht mehr länger benötigt werden
- macht es schwerer zu bestimmen, wann der Patch das letzte mal angefasst wurde
- macht es leichter herauszufinden, wann der Patch zusammenbrach (Paket-Archäologie)
Es gibt eine Ausnahme: Patches, die Warnungen beheben, die der Compiler ausgibt, aufgrund falscher Kode, regelmäßig als 'abuild.patch' bezeichnet werden.
Der bevorzugte Patchlevel ist -p1, da es das Importieren benötigter Werkzeuge wie quilt unkomplizierter macht.
Momentaner Satz Abkürzungen
Um Verwirrungen und doppelte Arbeit zu vermeiden, ist der Bezug auf andere Bugzillas erlaubt. Hier einige Abkürzungen für oft verwendete Bugzillas, die vor dem '#' der Bugzilla-Nummer hinzugestzt werden sollten. Beachten Sie, dass es kein Leerzeichen zwischen der Abkürzung und der Bugzilla-Nummer gibt.
| Abkürzung | Bugzilla-URL | Beispiel |
|---|---|---|
| Boost | https://svn.boost.org/trac/boost/report | (boost#123456) |
| CVE Einträge (Bitte fügen Sie die Zahl hinzu, auch wenn es dafür ein zusätzliches Bugzilla gibt) | http://cve.mitre.org | (CVE-2009-0067) |
| CPAN Öffentlicher Bug Tracker | http://rt.cpan.org/Public/ | (RT#123456) |
| Debian | http://bugs.debian.org/ | (deb#123456) |
| Fate (Funktion Track-Werkzeug) | https://features.opensuse.org/ | (Fate#123456) |
| freedesktop.org | http://bugs.freedesktop.org/ | (fdo#123456) |
| GCC | http://gcc.gnu.org/bugzilla/ | (GCC#123456) |
| GNOME | http://bugzilla.gnome.org/ | (bgo#123456) |
| ICCULUS | http://bugzilla.icculus.org/ | (bio#123456) |
| Jenkins CI | https://issues.jenkins-ci.org | (jenk#123456) |
| KDE | http://bugs.kde.org/ | (kde#123456) |
| Kernel oder K | http://bugzilla.kernel.org/ | (Kernel#123456) or (K#123456) or (bko#123456) |
| Launchpad (Ubuntu) | https://bugs.launchpad.net/ | (lp#123456) or (bln#123456) |
| Linux Foundation | http://developerbugs.linux-foundation.org/ | (lf#1234) |
| MeeGo | http://bugs.meego.com | (MeeGo#123456) |
| Mono | http://bugzilla.ximian.com/ | (Mono#123456) |
| Mozilla | http://bugzilla.mozilla.org/ | (bmo#123456) |
| Novell | https://bugzilla.novell.com/ | (bnc#123456) |
| OpenLDAP | http://www.openldap.org/its/ | (ITS#123456) |
| OpenOffice.org (Issuezilla) | http://qa.openoffice.org/issues/ | (i#123456) |
| OpenOffice.org Novell (veraltet) | https://bugzilla.novell.com/ | (n#123456) |
| openSUSE-Education | http://devzilla.novell.com/education/ | (os-edu#123456) |
| RedHat | https://bugzilla.redhat.com/ | (rh#123456) |
| Samba | https://bugzilla.samba.org/ | (bso#123456) |
| Sourceforge | http://sf.net/support/tracker.php?aid=1234567 | (sf#1234567); Zahl ist im "aid=" Teil des URL |
| SourceWare | http://sourceware.org/bugzilla/ | (swo#1234567) |
| Ximian | http://bugzilla.ximian.com/ | (Ximian#4321) |
| XFCE | https://bugzilla.xfce.org/ | (bxo#123456) |
Für andere Bugzilla-Kennziffern verwenden Sie bitte den kompletten URL des dazu gehörenden Bugzilla am Anfang der Patchdatei. Zum Beispiel:
Abkürzungensuche-Bookmarklet
Ein Bookmarklet zur Suche unter bugzilla.novell.com mit dem Präfix bnc# kann man hier finden.