openSUSE:Paketbau Richtlinien für Patches

Wechseln zu: Navigation, Suche
Paketbauer haben es mit einer Vielzahl von Paketen und ebenso mit einer Menge Patches innerhalb dieser Pakete zu tun. Das muss in den Spezifikationsdateien mit einem bekannten Format gekennzeichnet werden, um es zu ermöglichen, automatisierte Werkzeuge einzusetzen, um Berichte zu generieren, Patchzähler oder andere interessierende Informationen. Sie alle müssen konsequent bezeichnet werden.

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.