Anleitung zum Testen von OpenBSD-Ports

Inhaltsverzeichnis

• Einführung
• So wirds gemacht
• Erste Schritte
• Testen
• Kommentieren
• Noch mehr Tests

Einführung

Der Portstree ist ein riesiges Stück Arbeit, das OpenBSD-Benutzern erlaubt, Programme von Dritten zu benutzen, ohne Zeit mit Patchen, Konfigurieren oder dem Installieren jedes einzelnen Teils zu verschwenden. Diese Arbeit wird von einer Gruppe Freiwilliger gemacht, die ihre Zeit opfern, um Anwendungsprogramme über die ganze Breite der OpenBSD-Plattformen zu portieren und zu testen. Viele Leute glauben, dass sie dabei nicht helfen können, weil sie nicht genug Fachwissen haben; das ist aber falsch, sie können den Programmieren durchaus helfen, schneller und besser zu arbeiten.

So wirds gemacht

Testen von Updates oder neuen Ports, die auf der ports-Mailingliste angekündigt wurden. Indem du das tust, reduzierst du die Wartezeit bei Commits und erhöhst auch die Anzahl der Ports, die committed werden (viele Ports werden mangels Tests gar nicht erst committed!).

Erste Schritte

Der Portstree wird mittels OpenBSD-current entwickelt; es gibt also keinerlei Garantie, dass neue Ports oder Updates auch in den anderen Branches normal funktionieren. Das bedeutet, dass du dein System auf dem neusten Stand halten solltest (Anweisungen dazu gibt es auf der anoncvs- sowie der »-current folgen«-Seite). Außerdem ist es empfehlenswert, sich auf den ports- und den ports-changes-Mailinglisten einzuschreiben. Auf diese Weise wirst du über neue und geänderte Ports informiert.

Testen

Es gibt zwei Typen von Einsendungen auf den Mailinglisten; neue Ports und Updates. Neue Ports werden generell als Tarball-Anhänge oder URLs gepostet. Es ist immer eine gute Idee, sie in ein Verzeichnis wie /usr/ports/mystuff/ zu entpacken und von dort zu testen. Updates sind generell eine Diff gegen den -current-Portstree, also ist es am besten, den Port nach mystuff/ zu kopieren und dann diff anzuwenden, damit es nicht zu einem kaputten Tree kommt.

Ein Schritt-für-Schritt-Erzeugen des Ports ist notwendig, um sicherzustellen, dass jedes Ziel von ports(7) auch korrekt erreicht wird:

• fetch
  • Damit wird überprüft, dass die Distfile(s) korrekt heruntergeladen werden. Versuche alle MASTER_SITES zu testen, die angegeben sind, damit auch alle möglichen Quellen geprüft sind.
• checksum
  • Prüfe die Übereinstimmung zwischen heruntergeladenen Distfiles und den Prüfsummen in der distinfo-Datei.
• extract
  • Jede der Distfiles sollte jedes abhängige Programm (wie z. B. bzip2) vorher installieren.
• patch
  • Patches müssen ohne Warnmeldungen eingespielt werden.
  • Es sollten hinterher keinerlei .orig-Dateien mehr im patches/-Verzeichnis vorhanden sein.
  • Ein anderer weit verbreiteter Fehler ist das Einfügen eines RCS-Tags in einen Patch; sobald der Port in den CVS-Tree eingecheckt wird und das RCS-Tag erweitert wird, führt das zu Problemen.
• configure
  • Überprüfe, dass configure auch die Funktionalitäten deiner Plattform korrekt entdeckt und einbindet.
  • GNU libtool ist berüchtigt für ungewollte »Funktionalitäten« unter OpenBSD. Überprüfe also, dass der Port eine aktuelle Version benutzt und die korrekten Bibliotheken auf deiner Architektur erzeugt.
  • Das configure-Skript sollte keine bereits installierten Applikationen entdecken, die bereits auf deinem System installiert sind, ohne dass die expliziten Abhängigkeiten gesetzt sind.
• build
  • Achte auf Übersetzungsfehler und verdächtige Warnungen.
  • Warnungen über tmpnam(3)-Probleme sollten mittels mkstemp(3) gelöst werden.
  • Versuche, die SEPARATE_BUILD-Variable auf »concurrent« zu setzen und sieh nach, ob die Übersetzung dann immer noch funktioniert.
  • Stelle sicher, dass Abhängigkeiten von GNU make wirklich notwendig sind.
  • Überprüfe, ob der Port libtool verwendet. Wenn das der Fall ist, dann versuche, USE_LIBTOOL=Yes zu setzen. Auf diese Weise wird die Portsinfrastruktur die libtool-Version aus dem Tree verwendet und nicht die libtool-Version, die mit dem Quelltext der Software mitgeliefert wurde.
• regress
  • Suche nach Fehlern (Tests ohne Ergebnis bedeuten, dass alles in Ordnung ist).
• fake
  • Dieses Ziel installert die Applikation in ein Schein-Arbeitsverzeichnis, um sicherzustellen, dass alle Dateien ohne Konflikte mit dem Basissystem zusammengestellt werden können.
  • Der Port sollte niemals Dateien außerhalb des Scheinverzeichnisses installieren (wie z. B. in /usr/local). Dieses Problem kann leicht unter Verwendung von USE_SYSTRACE=Yes erkannt werden.
  • GNU libtool hat manchmal Schwierigkeiten mit dem Linken von Bibliotheken während des Scheinprozesses auf manchen Architekturen.
  • Überprüfe, ob alle Dateien mit den korrekten Benutzern und Berechtigungen installiert werden.
• package
  • Das Erzeugen des Packages kann schiefgehen, wenn pkg/PLIST* und/oder pkg/PFRAG* nicht korrekt sind.
• lib-depends-check
  • Hiermit wird überprüft, ob alle Bibliotheken, auf die der Port angewiesen ist, über entweder LIB_DEPENDS oder WANTLIB erreichbar sind. Das Ergebnis sollte leer sein. Diese Variablen sollten überprüft werden, wenn du Zeilen siehst, die mit Extra oder Missing beginnen.
• install
  • Packages sollten alle Dateien aus ihrer Packaginglist erfolgreich und mit den richtigen Dateirechten installieren. Sei besonders bei Dateien mit gesetztem setuid-Bit vorsichtig.
  • Stelle sicher, dass das Package-INSTALL-Skript korrekt funktioniert und auch keinerlei Dateien unter /etc überschreibt.
• deinstall
  • Hiermit sollten alle Dateien entfernt werden, die vom Package installiert wurden, mit Ausnahme derer in /etc.
  • Stelle sicher, dass das DEINSTALL-Skript wie erwartet funktioniert.

Verbleibende pkg/-Dateien wie DESCR und MESSAGE sollten auf Grammatik und Tippfehler geprüft werden. Absätze werden mittels fmt(1) formatiert und bei etwa 70 Zeichen werden die Zeilen umgebrochen.

Kommentieren

Am Ende des Tests kommt das Allerwichtigste: Kommentare. Selbst wenn der Port wunderbar funktioniert, muss das kommentiert werden. Wenn wir zehn Kommentare von Leuten haben, die besagen, dass der Port prima auf verschiedenen Architekturen läuft, wird der Port schneller fertig. Wenn er aber nicht wie gewünscht läuft, solltest du Informationen beisteuern. Es gibt Werkzeuge, die bei diesem Problem helfen können, wie z. B. portslogger, der wie ein »intelligentes tee« funktioniert, das die Ausgaben in eine Logdatei lenkt.

Beispiel:

   # make install 2>&1 | /usr/ports/infrastructure/build/portslogger .

Das wird die Ausgabe in eine Logdatei im aktuellen Verzeichnis umleiten.

Sobald der Port einwandfrei funktioniert müssen noch andere Ports auf ihre Lauffähigkeit überprüft werden, die auf diesem Port aufbauen. Das Maketarget show-required-by wird dir dabei helfen, alle Ports zu finden, die auf diesem basieren.

Noch mehr Tests

Prüfe das Makefile des Ports auf richtige Abhängigkeiten, Tippfehler, falsche Links, unnötige oder fehlende Variablen, korrekte Lizenzen und Kategorien. Die Leute mit noch mehr Sachkenntnis können Patches untersuchen oder auch Diffs zur Korrektur von Fehlern bereitstellen, Flavors hinzufügen oder auch andere Verbesserungen vornehmen.

Diese Diffs sollten mit den Optionen -uNr --exclude=CVS hergestellt werden. cvs diff -uN kann auch genutzt werden, um Patches gegen das CVS-Repository zu machen.