Das Handbuch für Maintainer zur Portaktualisierung

Seit dem OpenBSD-Release 3.8 kann pkg_add Packages aktualisieren. Maintainer müssen sich aber eines bewusst sein: Die Aktualisierung hat keine sofortige Wirkung. Selbst wenn ein Benutzer von Release zu Release aktualisiert, so wird immer ein Package nach dem anderen aktualisiert wenn pkg_add -ui ausgeführt wird. Somit läuft, auch wenn nur für wenige Minuten, ein asynchrones System.

Grundsätzlich gibt es zwei Arten der Aktualisierung, die den Maintainern bewusst sein sollten.

• Einige Benutzer verwenden keine strukturierte Aktualisierungsmethode. Sie aktualisieren ihre Packages mit Abstand weniger Tage oder Wochen; entweder alle oder nur speziell ausgewählte Packages. Diese Methode sollte kein Problem darstellen: Dadurch sind sie evtl. gezwungen, einige bestimmte Packages zu aktualisieren oder sogar neue Packages zu installieren, aber es sollte nicht stillschweigend fehlschlagen. Mikro-Aktualisierungen sollten getestet werden. Diese Benutzer werden in der Lage sein, kleinere Änderungen wie z. B. Änderung des Programmnamens oder der Konfiguration zu bewältigen.
• Einige Benutzer aktualisieren mit einem neuen Release alle sechs Monate. Sie laden evtl. auch stabile (Sicherheits- und kritische) Aktualisierungen herunter. In diesen sechs Monaten ändert sich einiges an den Ports, aber diese Benutzer kümmern sich nicht um diese Änderungen; sie wollen einfach ein System, das funktioniert. Programmnamen zu ändern und hunderte von Konfigurationsdateien abzustimmen wird ein großes Problem für solche Benutzer. Maintainer können aber helfen, z. B. mit einfachen Pfaden nach der Aktualisierung oder guten Tipps wenn etwas Wichtiges geändert wurde.

Man sollte erwähnen, dass der Aktualisierungsprozess, gerade bei makroskopischen Veränderungen für Benutzer, die alle sechs Monate aktualisieren, noch nicht automatisiert ist. Der globale Aktualisierungsprozess ist noch in Arbeit und pkg_add wird in Zukunft mit mehr Problemen zurechtkommen. Man sollte sofort überprüfen, ob das System korrekt aktualisiert wurde - ein Port nach dem anderen - und dass der Port seine Abhängigkeiten ordnungsgemäß installiert.

Die Namen der Packages und des Aktualisierungsprozesses

Konflikte, für die Zukunft planen

Das dreckige Geschäft - Umbenennen von Zweigen

Konfigurationsdateien und Aktualisierungsprobleme

Probleme mit gemeinsamen Bibliotheken

Checkliste zur Aktualisierung

• Man muss sicherstellen, dass sich die Softwareautoren über die Verbesserungen (die nötig sind, um die Software unter OpenBSD zum Laufen zu bringen) im Klaren sind. Man muss sich anstrengen, OpenBSD-Patches in die nächsten Releases einzubinden. Falls dies nicht gelingt, muss man darauf gefasst sein, seine Patches für jedes Release neu zu schreiben.
• Es ist sicherzustellen, dass die Softwareautoren Versionsnummern richtig verstehen. Wenn die Dateien keine Versionsnummern enthalten, sollte man sich am Besten an die Autoren wenden.
• Die Workarounds sollten dokumentiert werden. Das hilft beim Aktualisierungsprozess.
• Abhängigkeiten müssen dokumentiert werden. Ganz besonders die Sachen, die man nicht benötigt. Einige Ports verwenden externe Software, die zur Zeit der Portierung für OpenBSD noch nicht verfügbar ist. Bei einer ordnungsgemäßen Dokumentation ist es dann viel einfacher den Port zu aktualisieren, wenn diese Software dann für OpenBSD zur Verfügung steht.
• Wenn der Port libtool benutzt, kopiert man am Besten das ganze Log als Basis für die SHARED_LIBS-Installation. Das wird die Aktualisierung erleichtern.
• Man sollte PLIST_DB benutzen und eine Packagesdatenbank erstellen. Das kann sehr nützlich sein, wenn man Packagenamen vergessen hat, kann aber auch zum Prüfen von Konflikten mit älteren Packages verwendet werden.
• Die Abhängigkeiten sollten nicht so eng gesetzt werden. Standardmäßig werden RUN_ und LIB_DEPENDS jede Version benutzen. Man sollte keine Version angeben, wenn man nicht wirklich dazu gezwungen ist. Wenn man hier Versionen angibt, die für ein bestimmtes Programm vorausgesetzt werden, sollte man die niedrigstmögliche Version angeben.

• Jede Portaktualisierung braucht eine Markierung, damit erkannt werden kann, dass eine Aktualisierung stattgefunden hat (im weiteren Bump genannt). Ohne Bump funktioniert der Aktualisierungsprozess nicht. Alles, was das binäre Package beeinflusst, erfordert eine neue "Bump-Markierung", z. B. HOMEPAGE, MAINTAINER oder Beschreibungsänderungen.
• Wenn sich der Port nicht kompilieren lässt, ist kein Bump notwendig: Änderungen, die einen nicht funktionstüchtigen Port wieder ordentlich kompilieren lassen, müssen nicht unbedingt eine "Bump-Markierung" mit sich führen.
• Änderungen, die sicherstellen, ob ein Port externe Software verwendet oder nicht, führen eine "Bump-Markierung" mit sich.
• Änderungen an Abhängigkeiten erfordern normalerweise keine Änderung der Versionsnummer. Das Packagessystem verwendet einen Signaturmechanismus, sodass ein Package durch den vollen Packagenamen, die Abhängigkeiten, gegen die es erstellt wurde, und die Versionsnummern aller gemeinsam genutzten Bibliotheken, die es beinhaltet, erkannt wird.

• Man sollte make patch ausführen, um eine erste Kopie des Ports vor der Aktualisierung zu haben.

• Das "Makefile" des Ports ist zu aktualisieren, um die neue Version zu erhalten. Danach sind make makesum und make patch auszuführen.
• Wenn einmal ein Patch geschrieben ist, sollte man einen vollständigen "diff-Befehl" ausführen, um die genauen Unterschiede zwischen der alten und der neuen Version zu erkennen. Es ist gut Notizen anzulegen, auf die man später zurückgreifen kann.
• Alles was nötig ist, um den neuen Port nach OpenBSD zu portieren (z. B. Abhängigkeiten anpassen, Packageinhalt ändern etc.) ist ordentlich auszuführen.
• Gemeinsam genutzte Bibliotheken sind mind. zwei Mal zu überprüfen. Für libtool-basierte Ports gibt es shared_libs.log um zu überprüfen, ob es große Änderungen gibt. Notiz: Das ist nicht genug. Die meisten Softwareautoren verstehen Probleme mit gemeinsam genutzten Bibliotheken nicht richtig. Man muss das ganze "diff-Ergebnis" lesen und dann die Bibliotheksversionen entsprechend anpassen. Wenn man sich nicht sicher ist, sollte man die Majorversion entsprechend setzen.
• Aufpassen sollte man auf Konflikte mit bereits erstellten Packages. Für einfache Aktualisierungen muss nichts Besonderes erledigt werden. Wenn das Package in viele einzelne Subpackages eingeteilt wird, ist sicherzustellen, dass die Subpackages richtig in Bezug auf die Abhängigkeiten gekennzeichnet sind.
• Den Benutzern helfen. Falls spezielle Schritte notwendig sind, die über pkg_add -ui hinausgehen, sollte sichtlich darauf verwiesen werden. Falls die Packagerichtlinien geändert werden, z. B. das Erstellen eines eigenen Packages für die Hilfedateien, sollte auch darauf sichtlich hingewiesen werden.