Paketbau/SUSE-Paketkonventionen/Änderungsprotokolle

aus openSUSE, der freien Wissensdatenbank

11. Änderungsprotokolle

Dieses Kapitel beschreibt die openSUSE-Richtlinie für RPM-Änderungsprotokolle (Changelogs). Die originalen Änderungsprotokolle, die im Originalquellcode enthalten sind, sind von dieser Richtlinie nicht betroffen.

Allgemein: Denken Sie daran, dass nicht nur "gut informierte Entwickler", sondern auch "normale Endnutzer mit etwas technischen Verstand" ein RPM-Änderungeprotokoll lesen und verstehen können - auch noch in ein oder zwei Jahren. Und es sollte dann noch möglich sein, die ursprüngliche spec-Datei zu rekonsturieren/wiederherzustellen (ausgenommen gelöschte Patches).

Einträge im Änderungsprotokoll müssen in chronologischer Reihenfolge sein. Fass ein Paket in autobuild "eingechecked" wurde, sind keine Änderungen mehr an vorhergehenden Protokolleinträgen erlaubt.

11.1 Fehlernummern in Änderungsprotokollen

Während der Betreuung einer Distribution muss jede Änderung mit der korrekten Fehlernummer markiert werden. Normalerweise sollte dies eine Nummer von https://bugzilla.novell.com/ sein. Das Hinzufügen eines Eintrags mit Bugzilla-Nummer sollte eine Kurzbeschreibung der Fehlerzusammenfassung und die Fehlernummer ergeben. Zum Beispiel:

- Removed invalid desktop Category "Application" (bnc#254654).
- Symlink icon to pixmaps dir (bnc#152108)
- Added gnome-ui-properties to control-center (bnc#118960#c11).

Um Verwirrungen und doppelte Arbeit zu vermeiden, ist es erlaubt, sich auch auf andere Bugzillas zu beziehen. Hier sind einige Abkürzungen für oft genutzte Bugzillas, die vor dem "#" der Bugzilla-Nummer hinzugefügt werden sollten:

Für andere Bugzilla-Nummern verwenden Sie bitte die komplette URL zum zugehörigen Bugzilla. Zum Beispiel:

• http://developer.berlios.de/bugs/?func=detailbug&bug_id=12707&group_id=769

11.2 CVE-Nummern in Änderungsprotokollen

Es gilt das gleiche wie für Bugzilla-Nummern: Fügen Sie dem Protokolleintrag eine Kurzbeschreibung (in der Regen sollte die CVE-Zusammenfassung ausreichen), die Bugzilla-Nummer und die CVE-Nummer hinzu. Beispiel:

- Add gdk-pixbuf-226710.patch (#226710, and CVE-2007-0010).
- More XPM fixes: CVE-2005-2975 xpm too many colors DoS (#129642)
- fix ~/.dmrc symlink attack (#180704, CVE-2006-2449)

11.3 Bestimmte Änderungen

Seien Sie so präzise wie möglich! Dies ist vor allem dann wichtig, wenn Sie etwas aus der spec-Datei entfernen.

• Das Entfernen des Originalquellcodes muss in der spec-Datei mit einem Kommentar deklariert werden ("usefull for FreeBSD only" zum Beispiel) - es ist nicht notwendig, den Kommentar in der spec-Datei zu wiederholen.
• Zusätzliche Kommandos (zum Beispiel während %install) können in der spec-Datei mit einem kurzen Kommentar angezeigt werden - dieser Kommentar sollte auch der spec-Datei hinzugefügt werden.
• Hinzufügen/Entfernen von Paketen aus Requires/Provides muss im Änderungsprotokoll angegeben werden.

11.4 Änderungen im Quellcode

Wiederholen Sie während einer Versionsaktualisierung die wichtigsten Änderungen.

• Werfen Sie einen Blick ins Änderungsprotokoll des Quellcodes und picken Sie sich die wichtigsten Änderunge für die Distribution heraus (Änderungen für andere Betriebssysteme sind nicht wichtig).
• Fügen Sie die Originaländerungen unterhalb der Information über die Versionsaktualisierung ein. Beispiel:

 - Update to 1.3.2:
   + fixes memory leak in import function
   + new API command: unlock_client()
   + the following bugs are closed by this new upstream release:
   ++ ............ [MGN:332]
   ++ .............[MGN:337]
 - split of devel package