OpenBSD-Portierungsinformationen

Wichtige Unterschiede zu anderen BSD-Projekten

NetBSD benutzt den Ausdruck Ports für Architektur-abhängige Dinge. Ihre Ports-Struktur heißt stattdessen packages.

Zusätzliche Unterstützung

build/resolve-lib

aufgerufen durch make lib-depends-check, um Abhängigkeiten von Shared Librarys zu überprüfen.

build/update-patches

aufgerufen durch make update-patches, das immer benutzt werden sollte, um die Patches neu zu erzeugen.

install/make-plist

aufgerufen durch make update-plist. Hier wird sich sich um die meisten kleinen Punkte gekümmert, mit denen man akkurate Packing-Listen erzeugt. OpenBSD-Packing-Listen unterscheiden sich deutlich von anderen BSDs, zum Teil auch, weil die Packagetools vollkommen neu geschrieben wurden.

Infrastruktur

OpenBSDs make unterstützt ${VAR:U} und ${VAR:L}, um den Wert einer Variablen in Groß- oder Kleinschreibung zu ändern. Dementsprechend sollte ,make test' auch unabhängig von Groß- und Kleinschreibung programmiert sein, also z. B.:

	.if ${NEED_XXX:L} == "yes"
	do stuff if yes
	.else
	do other stuff
	.endif

In der Theorie sollten alle Boolean-Variablen, die von bsd.port.mk erkannt werden, auch definiert sein, sodass Code wie defined(USE_FOO) nicht notwendig sein sollte. ${USE_FOO:L} != "no" müsste funktionieren.

Die Haupt-bsd.port.mk-Datei wurde deutlich verändert und schlanker gemacht. Insbesondere ist sie jetzt bereit für ,parallel-make'. Das scripts/{pre,do,post}-*-Feature ging während des Prozesses verloren. Um das Skript wieder auferstehen zu lassen, rufe es per Hand aus dem Makefile auf.

make sauber benutzen

Denk daran, wenn du make mit make VAR=value aufrufst, wird die Zuweisung jeden Wert überschreiben, den VAR vom Makefile erhalten kann. Also sind viele Makefile-Patches nicht mehr notwendig, es ist viel besser, die MAKE_FLAGS korrekt zu setzen, um den Wartungsaufwand zu verringern.

Quelltexte holen

Es gibt zwei Arten von Archiven: DISTFILES und PATCHFILES. OpenBSD behandelt sie in gleicher Art und Weise, und holt standardmäßig alles von den MASTER_SITES. Es gibt keine PATCH_SITES oder PATCH_SITES_SUBDIR.

Wenn nicht alle zu holenden Dateien von der selben Site kommen, erlaubt OpenBSD die erweiterten Dateinamen:0 bis Dateiname:9, in diesem Fall wird es die Dateien von den MASTER_SITES0 bis MASTER_SITES9 holen.

Manche Architekturen benötigen möglicherweise spezielle distfiles. In der Vergangenheit gab es Probleme damit, soweit das Spiegeln von distfiles betroffen war. OpenBSD unterstützt eine dritte Art von Dateien: SUPDISTFILES. Diese werden nur zum Erzeugen von Prüfsummen und beim Spiegeln verwendet. Denk dran, dass SUPDISTFILES möglicherweise mit DISTFILES oder PATCHFILES kollidieren. Zum Beispiel:

	DISTFILES=foo-1.0.tgz
	.if ${ARCH} == "i386"
	DISTFILES+=foo-i386.tgz
	.elif ${ARCHI} == "sparc"
	DISTFILES+=foo-sparc.tgz
	.endif
	SUPDISTFILES=foo-i386.tgz foo-sparc.tgz

Die WRKDIR-Infrastruktur

Wir wollen nicht, dass Ports NO_WRKDIR benutzen. Alle OpenBSD-Ports müssen ein ,work directory' haben. Die Details der Namensgebung sollten keine Angelegenheit des Portierers sein. Wenn du einen solchen Namen erfahren musst, frage einfach das Makefile: cd that_ports_dir && make show=WRKDIR wird die Vorstellung des Codes von seinem WRKDIR offenlegen.

Der Hauptgrund hinter dieser Annahme ist, dass OpenBSDs bsd.port.mk wie ein echtes Makefile agiert, allerdings mit ein paar Abhängigkeiten. Die fetch-Stufe hängt von den distfiles und patchfiles ab, alle anderen Stufen sind von echten Dateien im ,working directory' (Cookies) abhängig, sodass sie gar nicht ohne einem 'working directory' existieren können.

EXTRACT_ONLY=

und mache die Extrahierung in post-extract.

WRKDIR

Das Port-,working directory', wo es seine eigenen Cookies unterbringt.

WRKDIST

Unterverzeichnis von WRKDIR, in dem der Port tatsächlich ausgepackt wird. Das ist auch das Basisverzeichnis für Patches. Andere BSDs haben zurzeit keine WRKDIST/WRKSRC-Aufteilung, sondern nur WRKSRC.

WRKSRC

Unterverzeichnis von WRKDIST, in dem der tatsächliche Source liegt.

WRKBUILD

Unterverzeichnis von WRKDIR, wo das Konfigurieren und Erzeugen (build) des Ports geschehen wird. Andere BSDs haben die WRKBUILD/WRKSRC-Aufteilung nicht. Programme, die (größtenteils) auf autoconf basieren, können für gewöhnlich SEPARATE_BUILD setzen, damit der Port in einem anderen Verzeichnis (WRKBUILD) als WRKSRC erzeugt wird.

WRKCONF

Unterverzeichnis von WRKDIR, in dem configure-Skripte ausgeführt werden sollten. Standardmäßig WRKBUILD, was in 99% der Fälle auch korrekt ist.

WRKINST

Verzeichnis, in das der Port installiert wird, bevor er gepackt wird (packaged) (siehe auch ,Faking ports' weiter unten).

Denk dran, dass es NO_WRKSUBDIR nicht mehr gibt: seine Funktionalität kann stattdessen mit dem Setzen von WRKDIST=$(WRKDIR) erreicht werden.

Faking ports

Einführung

Nachdem ein ,build' komplett ist, gehen andere BSDs dazu, über den Port zu installieren und erzeugen dann ein Package vom installierten Port. OpenBSD benutzt stattdessen ,faked installation'.

• Ein OpenBSD-Port wird ganz normal konfiguriert und erzeugt (z. B. um unter PREFIX installiert zu werden, normalerweise /usr/local).
• Aber es wird ihm gesagt, er solle sich woanders installieren, namentlich unter WRKINST, was für gewöhnlich ein Unterverzeichnis von WRKDIR ist.
• Dann wird die angebliche Installation gepackt (packaged), indem die -B-Option von pkg_create benutzt wird.
• Schlussendlich wird das daraus resultierende Paket (package) mittels pkg_add installiert.

Vorteile

• Für einen ,package builder' bedeutet es, dass die meisten Ports nicht wirklich installiert werden müssen, was eine Menge potenzieller Kompromisse und allgemeiner Probleme vermeidet. Es erlaubt auch das Erzeugen von mehreren Paketen, die einen Konflikt erzeugen, d.h. zum Beispiel verschiedene Versionen derselben Software auf einer Maschine. Schlussendlich erlaubt es das Erzeugen von neuen, ungetesteten Paketen ohne eine funktionierende Installation zu gefährden.
• Für einen ,port writer' vereinfacht es das Ziel, Probleme in den ,packing lists' zu finden, da die ,fake area of installation' leer ist, bevor der Port installiert wird. Zudem ist es nicht mehr nötig, die Portinstallation zu beeinflussen, wenn ein Port zu viele Dateien installiert, es reicht, die unwesentlichen Dateien einfach nicht in der ,packing list' aufzuführen.
• Für den Anwender verbessert es die Qualität der Packages: da der letztliche Port mit pkg_add installiert wird, erhält der Anwender exakt die gleiche Software, wie die, die auf der Maschine des Portierers vorbereitet wurde.

Wie man es macht

Die Ziele (targets), die make fake aufruft, sind die üblichen Installationsziele, mit einigen Ausnahmen:

• FAKE_FLAGS wird anstelle von MAKE_FLAGS benutzt. Standardmäßig setzt FAKE_FLAGS auf DESTDIR=${WRKINST}.
• FAKE_TARGET wird anstelle von INSTALL_TARGET benutzt.
• Die {pre,do,post}-Installationsfragmente werden mittels Setzen von TRUEPREFIX auf $(PREFIX), PREFIX auf $(WRKINST)$(PREFIX) und DESTDIR auf $(WRKINST) in Gang gebracht.

Ports, die imake benutzen, sollten so wie sie sind funktionieren, da die imake-Fragmente konfiguriert sind, um DESTDIR zu benutzen. Genauso sollten Ports, die ein aktuelles GNU configure nutzen, keine Änderungen benötigen.

Eine weitere gute Technik ist ein ,late binding'-Trick: konfiguriere die Ports so, dass sie einen Präfix von $(DESTDIR)/usr/local benutzen, so dass das resultierende Makefile den Präfix

prefix=$(DESTDIR)/usr/local

hat. Wenn der Port erzeugt wird und DESTDIR nichts enthält, wird /usr/local benutzt, und die fake-Installation wird alles unter WRKINST/usr/local installieren (also für GNU configure benutze CONFIGURE_STYLE= gnu dest).

Fallen

• Einige Ports sind inkonsistent in ihrer DESTDIR-Verarbeitung: die meisten Teile des Ports sind zufrieden mit dem gesetzten DESTDIR, mit Ausnahme von zwei oder drei Ausreißern. Patche das Problem weg.
• Unterscheide immer die wirkliche Stelle, an die der Port installiert wird und die, die in den Konfigurationsdateien des Packages aufgeführt ist. Das kann man leicht übersehen, ist aber leicht durch die Verwendung von TRUEPREFIX zu vermeiden.
• Absolute Symlinks müssen immer angepasst werden. Glücklicherweise wird bsd.port.mk hier alle Probleme bemerken.
• Ein paar Ports wollen $(DESTDIR) nicht alleine dem configure-Schritt überlassen. Ein post-configure-Fragment, das allen Makefiles das DESTDIR hinzufügt, wird benötigt.
• Sehr selten wird ein Port allen vernünftigen Versuchen widerstehen, FAKE zu benutzen. Ein Versuch mit roher Gewalt sollte funktionieren: benutze pre-fake, um alles, was der Port im WRKINST-Bereich benötigt, zu linken oder zu kopieren, danach installiere unter chroot.

Packaging-Tools

Die Package-Tools kennen schon ein paar Dateitypen und können viele Dinge automatisch durchführen: in den meisten Fällen werden @exec-Kommandos oder INSTALL-Skripte nicht gebraucht.
Beachte, dass alle unnötigen Skripte verbannt werden sollten, da das zu ,scalability'-Problemen führen kann. Es ist sehr viel einfacher, eine einzelne Package-Infrastruktur nach Fehlern zu überprüfen, als hunderte von Skripten zu modifizieren, damit sie mit neuen Problemen umgehen können.
Zum Beispiel:

• @exec ldconfig wird nicht benötigt, da Shared Librarys mit @lib libfoo.so.1.0 kommentiert werden und ldconfig nur ausgeführt wird, wenn es benötigt wird, und dann auch chroot dankbar verarbeiten wird.
• @exec install-info wird nicht benötigt, da Dokumentationsdateien mit @info file.info kommentiert werden. Dies handhabt auch mehrere Info-Dateien und entfernt die Notwendigkeit von makeinfo --no-split.
• Schriftarten werden dank @font und @fontdir automatisch eingebunden.
• Neue User und Gruppen werden über @newuser und @newgroup verarbeitet, statt über Installationsskripte. Sie werden auch früh genug angelegt, sodass weitere Package-Extrahierung sie nutzen kann.
• Konfigurationsdateien werden über @sample statt über Installationsskripte verarbeitet.

Greife für weitere Details auf pkg_create(1) zurück. In den meisten Fällen wird make update-plist einen sehr guten Angleich für eine komplette Packing-Liste erstellen und wird des weiteren auch von Hand durchgenommene Verbesserungen von einer Version zur nächsten übernehmen.

,flavors'

Optionen wurden zu ,flavors' zusammengefasst, sodass das Erzeugen von Packages (package building) konsistent sein kann. Ein Port mit Optionen sollte mit FLAVORS eine Liste von all den Optionen setzen, die Sinn für diesen Port machen (also FLAVORS=foo bar zoinx); benutze ,FLAVOR' um zu testen, welche Optionen tatsächlich gesetzt wurden (also: FLAVOR=zoinx foo). bsd.port.mk bietet einige Unterstützung:

• Der PKGNAME wird angepasst, um mit Bindestrich getrennte Optionen zu enthalten (z. B. package-foo-zoinx).
• Das WRKDIR wird so angepasst, dass konkurrierende ,flavors' erzeugt werden können, ohne zu kollidieren.
• Konstrukte der Form %%flavor%% werden die Einbeziehung von pfrag.Flavor auslösen. Das %%SHARED%%-Konstrukt löst die Einbeziehung von PFRAG.shared aus.
• bsd.port.subdir.mk versteht die Erweiterung von SUBDIR=directory,opt1,opt2 um sagen zu wollen: ,Baue den Port in directory mit FLAVOR=opt1 opt2.'

Zu überprüfen, ob ein gegebenes ,flavor' ausgewählt wurde, ist recht leicht:

.if ${FLAVOR:L:Mzoinx}