[OpenBSD]

[FAQ-Index] [Zum Kapitel 14 - Festplattenkonfiguration]

15 - Das Paket- und Portierungssystem von OpenBSD


Inhaltsverzeichnis


15.1 - Einführung

Es gibt viele Applikationen von Drittanbietern, die du eventuell auf einem OpenBSD-System einsetzen möchtest. Um die Installation und Verwaltung dieser Software einfacher zu machen (und um es mit OpenBSDs Richtlinien und Zielen in Einklang zu bringen), wird die Software der Drittanbieter in OpenBSD portiert. Diese Portierungsbemühung kann viele verschiedene Dinge beinhalten. Beispiele sind: dafür sorgen, dass die Software sich an die standardmäßige OpenBSD-Verzeichnisstruktur hält (z. B. sollten Konfigurationsdateien in /etc abgelegt werden), die Software sich an OpenBSDs Spezifikation für Shared Librarys hält, die Software sicherer machen, wenn das möglich ist etc.

Das Endergebnis dieser Portierungsbemühung ist ein Binärpaket, das direkt installiert werden kann. Das Ziel des Paketsystems ist es, die Installation der Software zu vermerken, sodass es auf einfache Art und Weise später aktualisiert oder entfernt werden kann. Auf diese Weise werden keine unnötigen Dateien auf dem System vergessen, wodurch Benutzer ihr System in einem sauberen Zustand halten können. Das Paketsystem stellt ebenfalls sicher, dass nichts aus Versehen gelöscht wird, was zur Folge hätte, dass Software nicht mehr ordnungsgemäß ausgeführt werden könnte. Ein weiterer Vorteil ist, dass Benutzer nur sehr selten Software aus dem Quelltext übersetzen müssen, da Pakete bereits kompiliert wurden und nun bereitstehen, um auf einem OpenBSD-System eingesetzt werden zu können. Innerhalb von Minuten kann eine große Anzahl Pakete heruntergeladen und installiert werden - und alles landet an der richtigen Stelle.

Die Paket- und Portierungs-Kollektionen unterliegen NICHT der gründlichen Sicherheitsüberprüfung, die für das OpenBSD-Basissystem gilt. Obwohl wir danach streben, die Qualität der Paketkollektion auf hohem Niveau zu halten, stehen zu wenig Entwickler bereit, um die gleiche Robustheit und Sicherheit zu gewährleisten. Selbstverständlich werden Sicherheitsaktualisierungen für vielerlei Anwendungen so schnell wie möglich in den Portierungsbaum eingebaut, und entsprechende Paket-Sicherheitsupdates als Schnappschuss in -current zur Verfügung gestellt.

15.2 - Verwaltung der Pakete

15.2.1 - Wie funktioniert das?

Pakete sind die vorkompilierten Binärdateien von einigen der am meist genutzten Software von Drittanbietern. Pakete können mit Hilfe einiger Werkzeuge auf sehr einfache Art und Weise verwaltet werden - diese werden auch als pkg*-Werkzeuge bezeichnet:

Damit eine Applikation X ordnungsgemäß ausgeführt werden kann, kann es notwendig sein, dass die Applikationen Y und Z installiert sind. Applikation X ist somit abhängig von diesen anderen Applikationen. Das ist der Grund, warum Y und Z Abhängigkeiten von X genannt werden. Genauso gut könnte Y die anderen Applikationen P und Q, Z wiederum die Applikation R benötigen, um funktionieren zu können. Auf diese Weise wird ein gesamter Abhängigkeitsbaum modelliert.

Pakete wirken wie einfache .tgz-Bündel. Im Grunde genommen sind sie es auch doch gibt es einen wichtigen Unterschied: Sie enthalten zusätzliche Paketinformationen. Diese Informationen werden von pkg_add(1) für einige Zwecke genutzt:

15.2.2 - Dinge einfach gestalten: PKG_PATH

Du kannst dir das Leben wirklich einfach machen, indem du die Umgebungsvariable PKG_PATH verwendest. Lass sie einfach auf dein bevorzugtes Verzeichnis zeigen und pkg_add(1) wird dort automatisch nach den von dir angegebenen Pakets suchen und ebenfalls alle notwendigen Abhängigkeiten des Pakets automatisch herunterladen und installieren.

Eine Liste möglicher Orte, von wo aus Pakete heruntergeladen werden können, befindet sich in folgender Sektion.

1. Beispiel: Installation von deiner CD-ROM; unter der Annahme, dass sie unter /mnt/cdrom gemountet wurde

$ export PKG_PATH=/mnt/cdrom/5.4/packages/`machine -a`/

2. Beispiel: Installation von einem nahe gelegenen FTP-Spiegelserver

$ export PKG_PATH=ftp://your.ftp.mirror/pub/OpenBSD/5.4/packages/`machine -a`/

Es ist grundsätzlich eine gute Idee, eine zusätzliche Zeile in deine ~/.profile zu schreiben, die den vorherigen Beispielen ähnlich ist. So wie mit der klassischen PATH-Variable kannst du mehrere Verzeichnisse angeben (mit Doppelpunkten getrennt). Vor OpenBSD 4.4 MUSSTE jedoch jedes Verzeichnis in der PKG_PATH-Variable mit einem Schrägstrich (/) enden. Auf diese Weise kann pkg_add(1) den Pfad richtig aufteilen selbst wenn URL-Schemas angegeben werden, die Doppelpunkte beinhalten. Wenn der erste Eintrag in PKG_PATH nicht zum Erfolg führt, wird der nächste ausprobiert; so lange, bis das Paket gefunden wurde. Wenn das Paket in keinem der Einträge gefunden werden kann, wird eine Fehlermeldung ausgegeben.

Beachte die Verwendung von machine(1) in den vorherigen Kommandozeilen. Hiermit wird automatisch deine installierte OpenBSD-Applikationsarchitektur eingefügt, die normalerweise - aber nicht zwangsläufig - dein Plattformname ist. Wenn du natürlich Schnappschüsse verwendest, so musst du »5.4« durch »snapshots« ersetzen.

15.2.3 - Pakete finden

Eine große Sammlung von vorkompilierten Paketen wird für die weit verbreiteten Architekturen bereitgestellt. Wenn du dein Paket suchst, dann sieh hier nach:

Wenn du den Portierungsbaum auf deinem System hast, dann kannst du das Paket sehr schnell aufspüren, indem du nach ihm suchst wie es in »Den Portierungsbaum durchsuchen« beschrieben steht.

Solltest du nach einem speziellen Dateinamen suchen, so installiere das Paket pkglocatedb, und nutze das dort enthaltene Kommando pkg_locate, um herauszufinden, welche(s) Paket(e) diese Datei enthalten.

Es wird dir auffallen, dass bestimmte Pakete in verschiedenen Variationen vorliegen; formal Aromata (»flavors«) genannt. Andere sind Teile der gleichen Applikation, die separat installiert werden könnten; diese werden Unterpakete genannt. Das ganze wird in der Sektion Aromata und Unterpakete verwenden genauer erläutert, doch bedeutet Aroma im Grunde nichts anderes, als dass sie mit anderen Optionen konfiguriert wurden. Momentan haben viele Pakete Aromata; beispielsweise Datenbankunterstützung, Unterstützung für Systeme ohne X oder weitere Netzwerkfunktionalitäten wie SSL und IPv6 bereitstellen. Jedes Aromata eines Pakets hat einen anderen Suffix im Paketnamen. Detailliertere Informationen über Paketnamen können in packages-specs(7) gefunden werden.

Hinweis: Nicht alle möglichen Pakete müssen zwangsläufig auf den FTP-Servern liegen! Es gibt Applikationen, die einfach nicht auf allen Architekturen laufen. Weitere Applikationen können aus Lizenzgründen nicht über FTP (oder CD-ROM) weitergegeben werden. Es kann auch einfach nur eine schier unendliche Kombination aus Aromata für eine Portierung geben; das OpenBSD-Projekt hat jedoch einfach nicht die Ressourcen, um sie alle zu kompilieren. Wenn du eine Kombination brauchst, die nicht bereitgestellt wird, musst du die Portierung aus dem Quelltext übersetzen. Weitere Informationen darüber, wie du das machst, kannst du im Kapitel Aromata und Unterpakete verwenden der Portierungssektion dieses Dokumentes nachlesen.

15.2.4 - Neue Pakete installieren

Um Pakete zu installieren, wird ein Werkzeug namens pkg_add(1) verwendet. Wenn du es dir einfach gemacht hast, indem du die Umgebungsvariable PKG_PATH gesetzt hast, kannst du einfach pkg_add(1) mit dem Paketnamen aufrufen so wie es in dem folgenden Beispiel gezeigt wird.
$ sudo pkg_add -v screen-4.0.3p3
parsing screen-4.0.3p3
installed /etc/screenrc from /usr/local/share/examples/screen/screenrc | 71%
screen-4.0.3p3: complete

In diesem Beispiel wird die Option -v verwendet, um eine informativere Ausgabe zu erhalten. Diese Option ist nicht notwendig, doch ist sie hilfreich, um Fehler zu finden, und wurde hier verwendet, um mehr Aufschluss darüber zu ermöglichen, was pkg_add(1) eigentlich macht. Beachte die Meldung, die /etc/screenrc erwähnt. Die Verwendung von mehreren -v-Optionen wird auch mehr Informationen in die Ausgabe schreiben.

pkg_add(1) im interaktiven Modus verwenden

pkg_add(1) verfügt über einen interaktiven Modus, der aktiviert werden kann, wenn die Option -i angegeben wird. In diesem Modus werden dir Fragen gestellt, falls pkg_add(1) keine eigene Entscheidung fällen kann. Wenn du zum Beispiel die Versionsnummer eines Pakets vor dem Aufruf nicht kennst, kannst du Folgendes ausprobieren:
$ sudo pkg_add -i screen
Ambiguous: screen could be screen-4.0.3p3 screen-4.0.3p3-shm
Choose one package
         0: <None>
         1: screen-4.0.3p3
         2: screen-4.0.3p3-shm
Your choice: 1
screen-4.0.3p3: complete

Für einige Pakete werden weitere wichtige Informationen über die Konfiguration oder über die Verwendung der Applikation auf einem OpenBSD-System ausgegeben. Da diese wichtig sind, werden sie immer ausgegeben - ob du nun die Option -v verwendet hast oder nicht. Sieh dir zum Beispiel das folgende Beispiel an:

$ sudo pkg_add ghostscript-fonts-8.11
ghostscript-fonts-8.11: complete
You may wish to update your font path for /usr/local/share/ghostscript/fonts
--- ghostscript-fonts-8.11 -------------------
To install these fonts for X11, just make sure that the fontpath
lists the 75dpi or 100dpi bitmap fonts before the ghostscript fonts,
and make sure you have the string ":unscaled" appended to the bitmap
font's fontpath. This way, the bitmap fonts will be used if they
match, and the Type 1 versions will be used if the font needs to be
scaled. Below is the relevant section from a typical xorg.conf file.

   FontPath   "/usr/X11R6/lib/X11/fonts/misc/"
   FontPath   "/usr/X11R6/lib/X11/fonts/75dpi/:unscaled"
   FontPath   "/usr/X11R6/lib/X11/fonts/100dpi/:unscaled"
   FontPath   "/usr/local/lib/X11/fonts/ghostscript/"
   FontPath   "/usr/X11R6/lib/X11/fonts/Type1/"

Lass uns nun mit einem Beispiel fortfahren, in dem ein Paket installiert wird, welches Abhängigkeiten besitzt:

$ sudo pkg_add -v tin-1.8.2p0
parsing tin-1.8.2p0
Dependencies for tin-1.6.2 resolve to: gettext-0.14.6, libutf8-0.8, pcre-6.4p1, libiconv-1.9.2p3 (todo: libiconv-1.9.2p3,gettext-0.14.6,pcre-6.4p1,libutf8-0.8)
tin-1.8.2p0:parsing libiconv-1.9.2p3
tin-1.8.2p0:libiconv-1.9.2p3: complete
tin-1.8.2p0:parsing gettext-0.14.6
Dependencies for gettext-0.14.6 resolve to: expat-2.0.0, libiconv-1.9.2p3 (todo: expat-2.0.0)
tin-1.8.2p0:parsing expat-2.0.0
tin-1.8.2p0:expat-2.0.0: complete
tin-1.8.2p0:gettext-0.14.6: complete
tin-1.8.2p0:parsing pcre-6.4p1
tin-1.8.2p0:pcre-6.4p1: complete
tin-1.8.2p0:parsing libutf8-0.8
tin-1.8.2p0:libutf8-0.8: complete
tin-1.8.2p0: complete
Wieder haben wir die Option -v hinzugefügt, um mehr über das eigentliche Geschehen zu erfahren. Beim Überprüfen der Paketinformationen wurden Abhängigkeiten gefunden, die nun zuerst installiert werden. Ungefähr in der Mitte kannst du sehen, wie das Paket gettext installiert wurde, welches wiederum von libiconv abhängig ist. Vor der Installation von gettext wurden seine Paketinformationen ausgelesen und sichergestellt, ob libiconv bereits installiert wurde.

Es ist möglich, mehrere Paketnamen bei einem Aufruf anzugeben, wodurch alle auf einmal installiert werden - neben allen möglichen Abhängigkeiten.

Falls du dich aus irgendeinem Grund gegen die Nutzung von PKG_PATH entscheiden solltest, ist es trotzdem möglich, die absolute Angabe eines Pakets auf der Kommandozeile anzugeben. Diese absolute Angabe kann ein lokaler Pfad oder eine URL sein, die auf FTP-, HTTP- oder SCP-Pfade verweist. Lass uns im nächsten Beispiel eine Installation über FTP ansehen:

$ sudo pkg_add ftp://ftp.openbsd.org/pub/OpenBSD/5.4/packages/`machine -a`/screen-4.0.3p3.tgz
screen-4.0.3p3: complete

In diesem Beispiel wurde die Option -v nicht verwendet, sodass nur die notwendigen Nachrichten angezeigt werden. Achte darauf, dass der vollständige Dateiname angegeben werden muss, indem man ein .tgz-Suffix anhängt. Du kannst jedoch auch wie in den vorherigen Beispielen auf dieses Suffix verzichten, da es automatisch durch pkg_add(1) hinzugefügt wird.

Hinweis: Nicht alle Architekturen verfügen über die gleichen Pakete. Einige Portierungen funktionieren nur auf bestimmten Architekturen; außerdem beschränkt die Leistung bestimmter Architekturen die Anzahl der Pakete, die auf diesen kompiliert werden kann.

Bei der Installation eines Pakets, das du zuvor schon installiert (oder eine frühere Version) und entfernt hast, wird pkg_add(1), um sicherzugehen, keine Konfigurationsdateien überschreiben, die du verändert hast. Stattdessen wird es dich über diese wie folgt informieren (jedoch nur, wenn du die Option -v angegeben hast!):

$ sudo pkg_add -v screen-4.0.3p3
parsing screen-4.0.3p3
The existing file /etc/screenrc has NOT been changed**                 | 71%
It does NOT match the sample file /usr/local/share/examples/screen/screenrc
You may wish to update it manually
screen-4.0.3p3: complete
Manchmal kann es sein, dass du einen Fehler wie in dem folgenden Beispiel siehst:
$ sudo pkg_add xv-3.10ap4
xv-3.10ap4:jpeg-6bp3: complete
xv-3.10ap4:png-1.2.14p0: complete
xv-3.10ap4:tiff-3.8.2p0: complete
Can't install xv-3.10ap4: lib not found X11.9.0
Even by looking in the dependency tree:
        tiff-3.8.2p0, jpeg-6bp3, png-1.2.14p0
Maybe it's in a dependent package, but not tagged with @lib ?
(check with pkg_info -K -L)
If you are still running 3.6 packages, update them.
Da ist pkg_add(1) gerade dabei, Abhängigkeiten zu installieren, als es plötzlich während der Installation von xv abbricht. Dies ist ein weiterer Sicherheitsmechanismus, der mit OpenBSD 3.7 eingeführt wurde. Die Paketinformationen, die sich im Paket befinden, enthalten Informationen über Shared Librarys, von denen das Paket erwartet, dass sie installiert sind - sowohl Systembibliotheken als auch Bibliotheken von Drittanbietern. Wenn eine dieser benötigten Bibliotheken nicht gefunden werden kann, wird das Paket nicht installiert, da es sowieso nicht richtig funktionieren würde.

Um diese Art des Konfliktes zu lösen, musst du herausfinden, was installiert werden muss, um die benötigten Bibliotheken auf dein System zu bekommen. Es gibt mehrere Dinge, die überprüft werden sollten:

15.2.5 - Installierte Pakete auflisten

Du kannst eine Liste aller installierten Pakete erhalten, indem du das Werkzeug pkg_info(1) verwendest.
$ pkg_info
aterm-0.4.2p1       color vt102 terminal emulator with transparency support
bzip2-1.0.4         block-sorting file compressor, unencumbered
expat-2.0.0         XML 1.0 parser written in C
fluxbox-0.9.15.1p0  window manager based on the original Blackbox code
gettext-0.14.6      GNU gettext
imlib2-1.3.0        image manipulation library
jpeg-6bp3           IJG's JPEG compression utilities
libiconv-1.9.2p3    character set conversion library
libltdl-1.5.22p1    GNU libtool system independent dlopen wrapper
libungif-4.1.4p0    tools and library routines for working with GIF images
libutf8-0.8         provides UTF-8 locale support
mutt-1.4.2.2i       tty-based e-mail client
pcre-6.4p1          perl-compatible regular expression library
png-1.2.14p0        library for manipulating PNG images
screen-4.0.3p3      multi-screen window manager
tcsh-6.14.00p1      extended C-shell with many useful features
tiff-3.8.2p0        tools and library routines for working with TIFF images
tin-1.8.2p0         threaded NNTP and spool based UseNet newsreader

Wenn der Name eines installierten Pakets angegeben wird (oder ein Pfad zu einem Paket, das installiert werden soll), wird pkg_info(1) detailliertere Informationen über dieses bestimmte Paket ausgeben.

15.2.6 - Installierte Pakete aktualisieren

Angenommen, du hättest eine ältere Version von unzip installiert, bevor du diesen Rechner von OpenBSD 5.3 auf 5.4 nachgerüstest hast. Nun ist es möglich, ganz einfach auf das neuere 5.4-Paket nachzurüsten, wie im Folgenden gezeigt:
$ sudo pkg_add -u unzip
unzip-5.52p0 (extracting): complete
unzip-5.52 (deleting): complete
unzip-5.52p0 (installing): complete
Clean shared items: complete

Der Aufruf von pkg_add(1) mit der Option -u und keinem Paketnamen wird versuchen, alle installierten Pakete zu aktualisieren.

Hinweis: Die Option -u baut auf der Umgebungsvariable PKG_PATH auf. Wenn diese nicht gesetzt ist, wird pkg_add(1) nicht in der Lage sein, Updates finden zu können.

Mehrere Einträge in PKG_PATH zu haben bedeutet nicht, dass bei Aktualisierungsvorgängen alle Einträge durchsucht werden. Stattdessen wird pkg_add(1) beim ersten Pfad aufhören, der passende Kandidaten vorweist.

Wenn du eine Konfigurationsdatei für die alte Version hattest, die du auch geändert hast, wird sie standardmäßig nicht modifiziert. Du kannst sie jedoch mit der Standardkonfigurationsdatei der neuen Version überschreiben, indem du pkg_add(1) mit der Option -c aufrufst.

15.2.7 - Installierte Pakete deinstallieren

Um ein Paket zu deinstallieren, nimm einfach den richtigen Namen des Pakets, der beim Aufruf von pkg_info(1) angezeigt wird (siehe Installierte Pakete auflisten weiter oben) und verwende pkg_delete(1), um Pakete zu entfernen. In dem folgenden Beispiel wird das Paket screen deinstalliert. Beachte, dass es manchmal sein kann, dass es weitere Anweisungen für die Deinstallation von weiteren Dingen gibt, die pkg_delete(1) nicht für dich ausführt. Wie es auch mit dem Werkzeug pkg_add(1) der Fall ist, kannst du die Option -v verwenden, um mehr Informationen in der Ausgabe zu erhalten.

$ sudo pkg_delete screen
screen-4.0.3p3: complete
Clean shared items: complete

Hinweis: Oft ist es nicht notwendig, die Versionsnummern und die Aromata mit dem Paketnamen anzugeben, da pkg_delete(1) normalerweise in der Lage ist, diese Namen selbstständig herauszufinden. Du musst den kompletten Paketnamen (in diesem Fall wäre das screen-4.0.3p3) nur dann angeben, wenn eine Verwechslung aufgrund von mehreren installierten Paketen mit dem angegebenen Namen möglich wäre; in dem Fall kann pkg_delete(1) nicht wissen, welches Paket deinstalliert werden soll.

Konfigurationsdateien werden von pkg_delete(1) nicht gelöscht, falls sie geändert wurden - um sicherzugehen. Stattdessen wird es dich darüber wie folgt informieren:

$ sudo pkg_delete screen
screen-4.0.3p3: complete
Clean shared items: complete
--- screen-4.0.3p3 -------------------
You should also remove /etc/screenrc (which was modified)

Wenn du möchtest, dass diese Konfigurationsdateien automatisch deinstalliert werden, kannst du das tun, indem du die Option -c angibst.

15.2.8 - Unvollständige Pakete (de)installieren

Wenn etwas schiefläuft, dann kann es sein, dass du feststellst, dass ein Paket nicht richtig hinzugefügt oder entfernt wurde weil es Konflikte mit anderen Dateien gab. Die unvollständige Installation wird üblicherweise mit einem »partial-« vor dem Paketnamen gekennzeichnet. Dies kann zum Beispiel passieren, wenn du versehentlich [STRG]+C während der Installation gedrückt hast:
$ sudo pkg_add screen-4.0.3p3
screen-4.0.3p3: complete
Adjusting md5 for /usr/local/info/screen.info-3 from 49fb3fe1cc3a3b0057518459811b6dac to 3b9c7811244fb9f8d83bb27d3a0f60d8
/usr/sbin/pkg_add: Installation of screen-4.0.3p3 failed , partial installation recorded as partial-screen-4.0.3p3

Es ist immer eine gute Idee, teilweise installierte Pakete von deinem System zu entfernen und potenzielle Probleme zu lösen, die zu diesem Fehler geführt haben könnten. Wenn so etwas eintritt, dann ist das oft ein Zeichen dafür, dass du kein ordentliches System hast, das vollständig nur von Paketen aus installiert wurde, sondern mit Software vermischt wurde, die du direkt vom Quelltext aus übersetzt hast.

15.3 - Mit Portierungen arbeiten

Wie in der Einführung erwähnt können Pakete aus dem Portierungsbaum heraus kompiliert werden. In diesem Kapitel werden wir erklären, wie der Portierungsbaum funktioniert, wann du ihn verwenden solltest und wie du ihn verwenden kannst.

WICHTIGER HINWEIS: Der Portierungsbaum ist nur für erfahrene Anwender gedacht. Es wird jedem nahegelegt, die vorkompilierten Binärpakete zu verwenden. Frage NICHT Anfängerfragen auf der Mailingliste wie zum Beispiel "How can I get the ports tree working?". Wenn du Fragen über den Portierungsbaum hast, dann wird vorausgesetzt, dass du die Handbuchseiten und diese FAQ gelesen hast, und dass du in der Lage bist, mit ihm zu arbeiten.

15.3.1 - Wie funktioniert das?

Der Portierungsbaum (ein Konzept, das ursprünglich von FreeBSD übernommen wurde) ist ein Satz Makefiles, wobei für jede Applikation von Drittanbietern ein Makefile existiert und bestimmt

Neben dem Makefile beinhaltet jede Portierung ebenfalls mindestens folgende Dinge:

All diese Informationen werden in einer Verzeichnishierarchie unter /usr/ports gespeichert. Die Hierarchie besteht aus drei speziellen Unterverzeichnissen:

Die anderen Unterverzeichnisse stellen verschiedene Applikationskategorien dar, die Unterverzeichnisse für die tatsächlichen Portierungen haben. Komplexe Portierungen können in noch weitere Ebenen unterteilt werden; zum Beispiel wenn sie eine Kernkomponente und einen Erweiterungssatz haben - oder eine stabile und eine Schnappschuss-Version der Applikation vorliegt. Jedes Portierungsverzeichnis muss ein pkg/-Unterverzeichnis haben, in dem sich die Packingliste(n) und die Beschreibungsdatei(en) befinden. Es können auch die Unterverzeichnisse patches/ und files/ vorliegen - diese sind jeweils für Quelltext-Korrekturroutinen und zusätzliche Dateien gedacht.

Wenn ein Benutzer make(1) in einem Unterverzeichnis einer speziellen Portierungen aufruft, dann wird das System rekursiv den Abhängigkeitsbaum durchgehen und prüfen, ob alle benötigten Abhängigkeiten bereits installiert wurden, die fehlenden Abhängigkeiten übersetzen und installieren und dann mit der Erzeugung der gewünschten Portierung fortsetzen. All dies passiert in dem Arbeitsverzeichnis, das die Portierung erstellt. Normalerweise ist dies unterhalb von ${WRKOBJDIR}, das den Standardwert /usr/ports/pobj hat, was aber überschrieben werden kann (siehe Konfiguration des Portierungssystems). Wenn WRKOBJDIR explizit entfernt wurde, so wird stattdessen ein Unterverzeichnis des Portierungs-Hauptverzeichnisses (Paketname mit vorangestelltem »w-«) benutzt.

Hinweis: Portierungen werden niemals direkt auf deinem System installiert! Sie verwenden ein Scheininstallationsverzeichnis. Alles, was dort installiert wird, wird in ein Paket zusammengefasst (welches dann im Unterverzeichnis packages/ des Portierungsbaums abgelegt wird, wie es zuvor beschrieben wurde). Eine Portierung zu installieren bedeutet daher in Wirklichkeit: Ein Paket erstellen und dann dieses installieren!

Weitere Informationen über das Portierungssystem können in diesen Handbuchseiten gefunden werden:

15.3.2 - Den Portierungsbaum beziehen

Bevor du fortfährst musst du diese Kapitel darüber lesen, dass du NICHT dein OpenBSD-System mit dem Portierungsbaum vermischst. Sobald du dich entschieden hast, welches Aromata des Portierungsbaums du haben möchtest, kannst du den Portierungsbaum von unterschiedlichen Quellen beziehen. Die folgende Tabelle gibt dir einen Überblick darüber, wo du die verschiedenen Aromata finden kannst (und in welcher Form). Ein »x« kennzeichnet die Verfügbarkeit und »-« bedeutet, dass du ihn über diese bestimmte Quelle nicht beziehen kannst.

Quelle Form Aroma
-release -stable Schnappschuss -current
CD-ROM .tar.gz x - - -
FTP-Spiegelserver .tar.gz x - x -
AnonCVS cvs checkout x x - x

Auf der CD-ROM und den FTP-Spiegelservern musst du nach einer Datei mit dem namen ports.tar.gz suchen. Du solltest die Datei in das Verzeichnis /usr/ entpacken, womit du /usr/ports und alle dazugehörigen Unterverzeichnisse erstellst. Zum Beispiel:

$ cd /tmp
$ ftp ftp://ftp.openbsd.org/pub/OpenBSD/5.4/ports.tar.gz
$ cd /usr
$ sudo tar xzf /tmp/ports.tar.gz

Die Schnappschüsse, die auf den FTP-Spiegelservern vorliegen, werden täglich vom Portierungsbaum -current erstellt. Diese Schnappschüsse kannst du im Verzeichnis pub/OpenBSD/snapshots finden. Wenn du einen Schnappschuss des Portierungsbaums verwendest, dann solltest du einen dazu passenden OpenBSD-Schnappschuss haben. Stelle sicher, dass du deinen Portierungsbaum und dein OpenBSD-System synchron hälst!

Lies bitte die AnonCVS-Seite, die eine Liste aller verfügbaren Server und einige Beispiele bereitstellt, wenn du weitere Informationen über das Beziehen des Portierungsbaum per AnonCVS hast.

15.3.3 - Konfiguration des Portierungssystems

HINWEIS: Dieses Kapitel führt einige zusätzliche systemweite Einstellungen für das Erzeugen von Applikationen aus den Portierungen ein. Du kannst dieses Kapitel überspringen, doch musst du dann viele der make(1)-Ausdrücke in den Beispielen als root ausführen.

Da dem OpenBSD-Projekt nicht genügend Ressourcen zur Verfügung stehen, um den gesamten Quelltext der Software aus dem Portierungsbaum zu überprüfen, kannst du das Portierungssystem so konfigurieren, dass einige weitere Sicherheitsmaßnahmen genutzt werden. Die Portierungs-Infrastruktur ist in der Lage, die gesamte Erzeugung als normaler Benutzer auszuführen; nur die Schritte, die Superuserrechte benötigen, werden als root ausgeführt. Beispiele hierfür sind die Make-Targets fake und install. Weil die Rootrechte jedoch immer irgendwann notwendig sind, wird dich das Portierungssystem nicht schützen können, wenn du dich für die Installation einer bösartigen Software entschieden hast.

Es ist auch möglich, einen schreibgeschützten Portierungsbaum zu nutzen, indem man die Verzeichnisse trennt, die während der Erzeugung der Portierung Schreibrechte haben müssen:

Du könntest zum Beispiel die folgenden Zeilen zur /etc/mk.conf hinzufügen:
WRKOBJDIR=/usr/obj/ports
DISTDIR=/usr/distfiles
PACKAGE_REPOSITORY=/usr/packages
Wenn du möchtest, dann kannst du auch den Besitzer dieser Verzeichnisse auf deinen lokalen Benutzernamen und deine Gruppe ändern, sodass das Portierungssystem die Unterverzeichnisse als regulärer Benutzer anlegen kann.

15.3.4 - Den Portierungsbaum durchsuchen

Wenn dein Portierungsbaum sich so weit auf deinem System befindet, wird es sehr einfach, nach bestimmter Software zu suchen. Verwende einfach make search key="Schlüsselwort" so wie es in diesem Beispiel gezeigt wird.
$ cd /usr/ports
$ make search key=rsnapshot
Port:   rsnapshot-1.3.1p0
Path:   net/rsnapshot
Info:   remote filesystem snapshot utility
Maint:  Antoine Jacoutot <ajacoutot@openbsd.org>
Index:  net sysutils
L-deps:
B-deps: :net/rsync
R-deps: :devel/p5-Lchown :net/rsync
Archs:  any
Das Suchergebnis gibt dir einen schönen Überblick über jede einzelne Applikation, die gefunden wurde: der Name der Portierung, der Pfad zur Portierung, eine einzeilige Beschreibung, den Verantwortlichen der Portierung, der Portierung zugewiesene Schlüsselwörter, Bibliotheken/Erzeugungs/Laufzeitabhängigkeiten und die Architekturen, bei denen bekannt ist, dass die Portierung auf ihnen läuft.

Dieser Mechanismus ist allerdings ein recht simpler, da er nur awk(1) auf die Indexdatei der Portierung anwendet. Mit OpenBSD 4.0 wurde eine neue Portierung namens »sqlports« erstellt, die genaue Suchanfragen mit SQL erlaubt. Es handelt sich dabei um eine SQLite-Datenbank, doch kann mit der Portierungs-Infrastruktur im Grunde jedes Datenbankformat erstellt werden.

Benutze einfach pkg_add(1), um das Paket sqlports hinzuzufügen. Eine Beispielsitzung könnte wie folgt aussehen:

$ sqlite3 /usr/local/share/sqlports
SQLite version 3.3.12
Enter ".help" for instructions
sqlite> SELECT FULLPKGNAME,COMMENT FROM Ports WHERE COMMENT LIKE '%statistics%';
Guppi-0.40.3p1|GNOME-based plot program with statistics capabilities
mailgraph-1.12|a RRDtool frontend for Postfix statistics
R-2.4.1|clone of S, a powerful math/statistics/graphics language
py-probstat-0.912p0|probability and statistics utilities for Python
darkstat-3.0.540p1|network statistics gatherer with graphs
pfstat-2.2p0|packet filter statistics visualization
tcpstat-1.4|report network interface statistics
wmwave-0.4p2|Window Maker dockapp to display wavelan statistics
diffstat-1.43p0|accumulates and displays statistics from a diff file
sqlite>
Dieses Beispiel zeigt noch immer eine sehr einfache Suche. Mit SQL kann aber alles durchsucht werden: Abhängigkeiten, Configureoptionen, Shared Librarys etc.

15.3.5 - Unkomplizierte Installation: ein einfaches Beispiel

Um das ganze klarer zu machen nehmen wir folgendes Beispiel an: rsnapshot. Diese Applikation ist nur von einem Paket abhängig: rsync.
$ cd /usr/ports/net/rsnapshot
$ make install
===>  Checking files for rsnapshot-1.2.9
>> rsnapshot-1.2.9.tar.gz doesn't seem to exist on this system.
>> Fetch http://www.rsnapshot.org/downloads/rsnapshot-1.2.9.tar.gz.
100% |**************************************************|   173 KB    00:02
>> Size matches for /usr/ports/distfiles/rsnapshot-1.2.9.tar.gz
>> Checksum OK for rsnapshot-1.2.9.tar.gz. (sha1)
===>  rsnapshot-1.2.9 depends on: rsync-2.6.9 - not found
===>  Verifying install for rsync-2.6.9 in net/rsync
===>  Checking files for rsync-2.6.9
>> rsync-2.6.9.tar.gz doesn't seem to exist on this system.
>> Fetch ftp://ftp.samba.org/pub/rsync/old-versions/rsync-2.6.9.tar.gz.
100% |**************************************************|   792 KB    00:31
>> Size matches for /usr/ports/distfiles/rsync-2.6.9.tar.gz
>> Checksum OK for rsync-2.6.9.tar.gz. (sha1)
===>  Verifying specs:  c
===>  found c.40.3
===>  Extracting for rsync-2.6.9
===>  Patching for rsync-2.6.9
===>  Configuring for rsync-2.6.9
  [... Schnipp ...]
===>  Building for rsync-2.6.9
  [... Schnipp ...]
===>  Faking installation for rsync-2.6.9
  [... Schnipp ...]
===>  Building package for rsync-2.6.9
Link to /usr/ports/packages/i386/ftp/rsync-2.6.9.tgz
Link to /usr/ports/packages/i386/cdrom/rsync-2.6.9.tgz
===>  Installing rsync-2.6.9 from /usr/ports/packages/i386/all/rsync-2.6.9.tgz
rsync-2.6.9: complete
===> Returning to build of rsnapshot-1.2.9
===>  rsnapshot-1.2.9 depends on: rsync-2.6.9 - found
===>  Extracting for rsnapshot-1.2.9
===>  Patching for rsnapshot-1.2.9
===>  Configuring for rsnapshot-1.2.9
  [... Schnipp ...]
===>  Building for rsnapshot-1.2.9
  [... Schnipp ...]
===>  Faking installation for rsnapshot-1.2.9
  [... Schnipp ...]
===>  Building package for rsnapshot-1.2.9
Link to /usr/ports/packages/i386/ftp/rsnapshot-1.2.9.tgz
Link to /usr/ports/packages/i386/cdrom/rsnapshot-1.2.9.tgz
===>  rsnapshot-1.2.9 depends on: rsync-2.6.9 - found
===>  Installing rsnapshot-1.2.9 from /usr/ports/packages/i386/all/rsnapshot-1.2.9.tgz
rsnapshot-1.2.9: complete

Wie du sehen kannst macht das Portierungssystem viele Dinge automatisch. Es bezieht, extrahiert und korrigiert den Quelltext, konfiguriert und erzeugt (kompiliert) den Quelltext, installiert die Dateien in ein Scheinverzeichnis, erstellt ein Paket (mit Bezug auf die Paketliste) und installiert das Paket auf dein System (normalerweise unter /usr/local/). Das Portierungssystem macht das sogar rekursiv für alle Abhängigkeiten der Portierung. Achte einfach mal auf die Zeilen »===> Verifying install for ...« und »===> Returning to build of ...« der vorherigen Ausgabe, die auf das Durchlaufen des Abhängigkeitsbaum deuten.

Wenn bereits eine vorherige Version der Applikation, die du installieren möchtest, auf deinem System installiert wurde, kannst du make update an Stelle von make install aufrufen. Hiermit übergibst du pkg_add(1) die Option -r.

Hinweis: Große Applikationen werden viele Systemressourcen für die Erzeugung benötigen. Gute Beispiele hierfür sind Compiler wie GCC 4.0 oder Java 2 Software Development Kit. Wenn du Fehlermeldungen wie »out of memory« bei der Erzeugung einer solchen Portierung erhältst, geschah das meist aus einem dieser beiden Gründe:

15.3.6 - Nach der Kompilation aufräumen

Du möchtest vermutlich das standardmäßige Arbeitsverzeichnis einer Portierung aufräumen, wenn du mit der Erzeugung und Installation eines Pakets fertig bist.
$ make clean
===>  Cleaning for rsnapshot-1.2.9
Zusätzlich kannst du auch die Arbeitsverzeichnisse aller Abhängigkeiten der Portierung mit diesem Make-Target aufräumen:
$ make clean=depends
===>  Cleaning for rsync-2.6.9
===>  Cleaning for rsnapshot-1.2.9
Wenn du das Set oder die Sets der Quelltextdistribution der Portierung löschen möchtest, würdest du Folgendes aufrufen:
$ make clean=dist
===>  Cleaning for rsnapshot-1.2.9
===>  Dist cleaning for rsnapshot-1.2.9
Falls du mehrere Aromata der gleichen Portierung kompiliert hast, kannst du das Arbeitsverzeichnis aller Aromata auf einmal aufräumen:
$ make clean=flavors
Du kannst auch eine spezielle Variable setzen, mit der automatisch nach der Übersetzung aufgeräumt wird. Arbeitsverzeichnisse werden somit automatisch nach der Erstellung eines Pakets geleert:
$ make package BULK=Yes

15.3.7 - Das Paket einer Portierung deinstallieren

Das Deinstallieren einer Portierung ist sehr einfach:
$ make uninstall
===> Deinstalling for rsnapshot-1.2.9
rsnapshot-1.2.9: complete
Clean shared items: complete
Dies wird pkg_delete(1) so aufrufen, dass das zugehörige Paket von deinem System entfernt wird. Wenn du möchtest, dann kannst du mit folgendem Aufruf das Paket einer Portierung deinstallieren und zugleich wieder neu installieren:
$ make reinstall
===>  Cleaning for rsnapshot-1.2.9
/usr/sbin/pkg_delete rsnapshot-1.2.9
rsnapshot-1.2.9: complete
Clean shared items: complete
===>  Installing rsnapshot-1.2.9 from /usr/ports/packages/i386/all/rsnapshot-1.2.9.tgz
rsnapshot-1.2.9: complete
Wenn du einfach nur die Pakete loswerden willst, die du gerade erzeugt hast, kannst du dies wie folgt tun:
$ make clean=packages
===>  Cleaning for rsnapshot-1.2.9
rm -f /usr/ports/packages/i386/all/rsnapshot-1.2.9.tgz

15.3.8 - Aromata und Unterpakete verwenden

Lies bitte die Handbuchseite ports(7), die einen guten Überblick über diese Thematik verschafft. Es gibt zwei Mechanismen, mit denen das Erstellen von Paketen der Software in Bezug auf verschiedene Bedürfnisse verwaltet werden kann.

Der erste Mechanismus wird Aroma (»Flavor«) genannt. Ein Aromata verweist normalerweise auf einen bestimmten Satz Kompilationsoptionen. Zum Beispiel haben einige Applikationen ein no_x11-Aromata, das auf Systemen ohne X genutzt werden kann. Einige Shells haben ein static-Aromata, das eine statisch gelinkte Version erzeugen wird. Es gibt Portierungen, die verschiedene Aromata für die Erzeugung mit unterschiedlichen grafischen Toolkits besitzen. Andere Beispiele sind u. a.: Unterstützung für verschiedene Datenbankformate, verschiedene Netzwerkoptionen (SSL, IPv6, ...), verschiedene Papierformate etc.

Zusammenfassung: Am wahrscheinlichsten wirst du Aromata verwenden, wenn ein Paket nicht für das Aroma bereitgestellt wurde, nach dem du suchst. In diesem Fall musst du das gewünschte Aroma angeben und selbst die Portierung erzeugen.

Die meisten Aromata haben ihr eigenes Arbeitsverzeichnis während der Erzeugungsphase; ebenfalls wird jedes Aroma in ein Paket mit dem zum Aroma gehörigen Namen gepackt, um Verwechslungen mit anderen auszuschließen. Um die Aromata einer bestimmten Portierung anzeigen zu lassen, würdest du in das Unterverzeichnis wechseln und Folgendes aufrufen:

$ make show=FLAVORS
Wirf auch einen Blick in die DESCR-Dateien der Portierungen; mit ihnen sollen die verfügbaren Aromata erklärt werden.

Der zweite Mechanismus wird Unterpakete genannt. Ein Portierer könnte entscheiden, dass Unterpakete für verschiedene Teile der gleichen Applikation erstellt werden, falls diese logisch getrennt werden können. Dir werden oft Unterpakete für den Client- und für den Serverteil eines Programmes begegnen. Manchmal wird auch sehr ausgiebige Dokumentation in ein separates Unterpaket gebündelt, da dieses viel Plattenspeicher in Anspruch nimmt. Ebenfalls werden zusätzliche Funktionalitäten in eigene Pakete ausgelagert, falls diese eine große Anzahl zusätzlicher Abhängigkeiten mit sich bringen. Der Portierer entscheidet ebenfalls, welches Unterpaket das Haupt-Unterpaket ist und somit standardmäßig installiert wird. Andere Beispiele sind: ausgiebige Testumgebungen, die mit der Software ausgeliefert werden, separate Module mit Unterstützung für unterschiedliche Dinge etc.

Zusammenfassung: Einige Portierungen werden in mehrere Pakete aufgeteilt. Mit make install wird nur das Haupt-Unterpaket installiert.

Um die unterschiedlichen Pakete anzuzeigen, die von einer Portierung erzeugt werden, verwende:

$ make show=PKGNAMES

Mit make install wird nur das erste Unterpaket installiert. Um alle zu installieren, verwende:

$ make install-all

Um die verschiedenen verfügbaren Unterpakete für eine Portierung anzuzeigen, verwende:

$ make show=MULTI_PACKAGES
Es ist möglich, auszuwählen, welche Unterpakete vom Portierungsbaum aus installiert werden soll - das Gleiche gilt für mehrere Unterpakete. Nach einigen Tests wird ein pkg_add(1)-Aufruf erfolgen, der das gewünschte Unterpaket (oder die gewünschten Unterpakete) installiert.
$ env SUBPACKAGE="-server" make install

Hinweis: Der Unterpaket-Mechanismus verarbeitet nur Pakete - es werden keine Konfigurationsoptionen vor dem Erzeugen der Portierung geändert. Du müsstest hierfür Aromata verwenden.

15.3.9 - Nutzung von dpb zur Kompilation mehrerer Portierungen

Wenn mehr als eine Portierung gleichzeitig kompiliert werden soll, so kann man ein Werkzeug benutzen, dass in /usr/ports/infrastructure/bin angeboten wird - dpb(1). dpb(1) nimmt eine Liste der zu kompilierenden Portierungen entgegen, kompiliert sie alle in einer optimalen Reihenfolge, und benutzt dabei soviel Parallelisierung wie möglich. Es kann auch mehrere Maschinen für die Kompilierung nutzen. Es generiert ausführliche Protokolle der Kompilierungsprozesse für die Fehlersuche, und zwar standardmäßig in /usr/ports/log.
/usr/ports/infrastructure/bin/dpb -P ~/localports
wird die Liste der pkgpaths (pkgpath(7)) in ~/localports lesen und alle Pakete bauen. Es kann die Pakete auch installieren, nachdem sie kompiliert wurden. ~/localports würde in etwa so aussehen:
net/cvsync
www/mozilla-firefox
net/rsync
net/nfsen
textproc/mupdf
misc/magicpoint
lang/sbcl
editors/emacs
Wenn keine Liste von zu kompilierenden Portierungen auf der Kommandozeile, oder aber durch die Optionen -P oder -I angegeben wurde, so kompiliert dpb(1) den kompletten Portierungsbaum.

15.3.10 - Sicherheitsaktualisierungen

Wenn schwerwiegende Fehler oder Sicherheitslücken in der Software von Drittanbietern gefunden werden, dann werden sie im -stable-Branch des Portierungsbaums behoben. Im Unterschied zum Basissystem beträgt der Lebenszyklus ein Release: nur -current und das letzte Release werden aktualisiert, so wie es in FAQ 5 - OpenBSDs Aromata erklärt wird.

Dies bedeutet, dass du lediglich darauf achten musst, dass du den korrekten Branch des Portierungsbaums verwendest und die gewünschte Software von diesem aus erzeugst. Halte deinen Baum mit CVS aktuell, und dich zusätzlich in der Mailingliste ports-changes einschreiben, um über sicherheitsbezogene Ankündigungen, die die Software im Portierungsbaum betrifft, auf dem Laufenden gehalten zu werden.

Selbstverständlich landen die Sicherheitsupdates erst im Portierungsbaum -current, bevor sie in den -stable-Zweig übernommen werden.

15.3.11 - Paketsignaturen

Signaturen sind ein guter Weg, um sicherzustellen, dass Pakete legitim und nicht korrumpiert sind.

Um damit zu beginnen, signierte Pakete zu kompilieren, müssen wir zuerst ein (selbst signiertes) Wurzelzertifikat inklusive Schlüssel erzeugen, um damit als Zertifizierungsautorität (»root CA«, »Certificate Authority«) fungieren zu können. Für dieses Beispiel benutzen wir eine Gültigkeit von zehn Jahren.

# openssl req -x509 -days 3650 -newkey rsa:2048 -keyout /etc/ssl/private/pkgca.key -out /etc/ssl/pkgca.pem
Nun erzeugen wir ein Kompilations-Zertifikat mit Schlüssel, welche benutzt werden, um unsere Pakete zu signieren. Für das Beispiel benutzen wir eine Gültigkeit von einem Jahr. Wir erzeugen ebenfalls eine entsprechende Zertifikats-Signierungsanfrage, welche von unserer Zertifizierungsautorität zur Signierung des Zertifikats benutzt werden wird.
# openssl genrsa -out /etc/ssl/private/pkg.key 2048
# openssl req -new -key /etc/ssl/private/pkg.key -out /etc/ssl/private/pkg.csr
Nun signieren wir das Zertifikat mit Hilfe der Zertifizierungsautorität, die wir im ersten Schritt erzeugt haben.
# openssl x509 -req -days 365 -in /etc/ssl/private/pkg.csr -CA /etc/ssl/pkgca.pem -CAkey /etc/ssl/private/pkgca.key -CAcreateserial -out /etc/ssl/pkg.crt
# rm /etc/ssl/private/pkg.csr

Zuletzt fügen wir die folgenden Zeilen zu /etc/mk.conf hinzu, um standardmäßig signierte Pakete zu bauen.

PKG_CREATE=/usr/sbin/pkg_create -s x509 -s /etc/ssl/pkg.crt -s /etc/ssl/private/pkg.key

Wenn signierte Pakete installiert werden, wird man eine zusätzliche Zeile am Ende der Ausgabe sehen, die über die Anzahl der signierten Pakete informiert, die gerade installiert wurden.

$ sudo pkg_add vte-0.24.3.tgz
vte-0.24.3: ok
Packages with signatures: 1

Wenn man in Schwierigkeiten mit signierten Paketen gerät (z. B. ein abgelaufenes Zertifikat ...), so kann man eine (erneute) Installation und/oder Entfernung mit Hilfe eines der folgenden Kommandos erzwingen (je nachdem, was erreicht werden soll):

$ sudo pkg_add -r -D installed PKGNAME
$ sudo pkg_add -D nosig PKGNAME
$ sudo pkg_delete -q PKGNAME

15.4 - FAQ

15.4.1 - Ich bekomme alle möglichen unverständlichen Fehlermeldungen. Ich schaffe es einfach nicht, diesen Portierungskram zum Laufen zu kriegen.

Es ist sehr wahrscheinlich, dass du ein System und einen Portierungsbaum verwendest, die nicht synchron sind.

Bitte was?

Ein weiterer häufiger Grund ist eine fehlende X11-Installation. Selbst wenn die Portierung, den du übersetzen willst, keine direkte X11-Abhängigkeit vorweist, so könnten Unterpakete oder weitere Abhängigkeiten X11-Header und -Bibliotheken voraussetzen. Übersetzen von Portierungen auf Systemen ohne X11 wird daher nicht unterstützt. Solltest du dennoch darauf bestehen, bist du auf dich allein gestellt und musst Fehler selbst herausfinden. Für viele Portierungen gibt es dennoch »no_x11«-Pakete, die du auch ohne X11 auf deinem System installieren kannst.

15.4.2 - Die aktuellste Version meiner Lieblingssoftware ist nicht verfügbar!

Wenn du eine Release- oder stabile Version von OpenBSD verwendest, dann wirst du keine Aktualisierungen der Pakete bis zum nächsten Release sehen; es sei denn, dass Sicherheitsprobleme ein Update der Portierungen im Zweig -stable und dem dazugehörigen Paket rechtfertigen.

WARNUNG: Mische NIEMALS Versionen der Portierungen und von OpenBSD!

Tätest du das, so würdest du früher oder später (aber vermutlich sogar schon sehr früh) dir selbst Kopfzerbrechen bereiten, da du alle möglichen Fehler beheben müsstest.

Was solls, alles was ich hier habe ist -current!

Die Portierungs-Kollection ist ein Projekt von Freiwilligen. Manchmal hat das Projekt einfach nicht genügend Entwicklerressourcen, um alles auf dem neuesten Stand zu halten. Entwickler beschäftigen sich meist mit dem, was sie selbst als interessant ansehen und testen es in ihrer Umgebung. Einige individuelle Portierungen können gerade deshalb hinter den Mainstreamversionen liegen. Wichtiger noch, nicht auf die neueste Version zu aktualisieren ist oftmals eine absichtliche Entscheidung. Die neuere Version könnte Probleme haben, die der Betreuer zu beheben versucht, oder schlichtweg die Anwendung, verglichen mit der alten Version, verschlechtert haben. Außerdem könnte OpenBSD andere Ziele haben, als die Entwickler anderer Projekte, was manchmal dazu führt, dass Funktionalitäts-, Entwurfs- oder Implementierungsentscheidungen getroffen werden, die aus Sicht der OpenBSD-Entwickler nicht wünschenswert sind. Die Aktualisierung mag auch einfach aus dem Grund verschoben worden sein, dass die neue Version nicht als entscheidende Aktualisierung betrachtet wird.

Wenn du wirklich die neuere Version einer Portierung benötigst, so solltest du ihren Betreuer bitten, sie zu aktualisieren (siehe weiter unten, wie man herausfindet, wer der Betreuer einer Portierung ist). Wenn du helfen kannst, umso besser.

15.4.3 - Warum gibt es kein Paket meiner Lieblingssoftware?

Hierfür kann es mehrere Möglichkeiten geben:

15.4.4 - Warum gibt es keine Portierung meiner Lieblingssoftware?

Die Portierungs-Kollection ist ein Projekt von Freiwilligen. Aktive Portierungsentwicklung wird von einer begrenzten Anzahl Leute in ihrer Freizeit durchgeführt. Diese Leute erstellen Portierungen meist nur von der Software, die sie direkt nutzen oder interessant finden.

Du kannst helfen. Ziehe das Erstellen einer eigenen Portierung in Betracht. Es gibt einige Dokumentationen darüber: das OpenBSD Portiererhandbuch. Lies es - und lies es wieder. Insbesondere den Teil über das Verwalten deiner Portierungen. Versuche dann, eine eigene Portierung zu erstellen und teste sie sorgfältig Schritt für Schritt. Wenn sie schlussendlich einwandfrei für dich arbeitet, sende ihn an die Portierungs-Mailingliste ports@openbsd.org. Die Chancen, eine Rückmeldung und Testberichte von anderen Leuten zu erhalten, stehen gut. Wenn die Tests erfolgreich sind, so wird eine Aufnahme deiner Portierung in den Baum in Betracht gezogen.

15.4.5 - Warum ist meine Lieblingssoftware nicht Teil des Basissystems?

OpenBSD soll ein kleines eigenständiges Unix-ähnliches Betriebssystem sein. Wir müssen daher klar begrenzen, was rein darf und was nicht. Generell muss für eine Applikation Folgendes gelten, um in das Basissystem übernommen werden zu können:

Weitere Antworten hierzu können ebenfalls in der FAQ 1 gefunden werden.

15.4.6 - Was sollte ich verwenden: Pakete oder Portierungen?

Generell wird dir dringend geraten, die Pakete dem Erzeugen der Applikationen aus den Portierungen heraus vorzuziehen. Das OpenBSD-Portierungsteam betrachtet die Pakete als ihr Ziel ihrer Portierungsbemühung - nicht die Portierungen selbst.

Das Erzeugen einer komplexen Applikation vom Quelltext aus ist nicht trivial. Nicht nur muss die Applikation kompiliert werden, auch die Werkzeuge, die während der Erzeugung genutzt werden, müssen übersetzt werden. Leider entwickeln sich OpenBSD, die Werkzeuge und die Applikationen ständig weiter; oft ist es schwer, alle Teile zusammenfügen zu können. Wenn dann alles läuft, könnte eine Revision eines der Teile wieder alles zunichte machen. Alle sechs Monate wird ein neues Release von OpenBSD veröffentlicht. Es gibt Bemühungen, das Erzeugen jeder einzelnen Portierung auf allen Plattformen gewährleisten zu können, doch ist es während dem Entwicklungszyklus sehr wahrscheinlich, dass das mit einigen Portierungen nicht funktioniert.

Neben der Zusammenstellung aller Teile ist es eine Frage der benötigten Zeit und der Ressourcen, einige der Applikationen vom Quelltext aus zu übersetzen. Applikationen wie zum Beispiel Mozilla oder KDE können Stunden und riesige Mengen Plattenspeicher und RAM/Swap während der Erzeugung in Anspruch nehmen. Warum willst du dir das alles antun und die Zeit opfern, wenn die Programme bereits kompiliert vorliegen und auf deiner CD-ROM oder auf einem FTP-Spiegelserver darauf warten, installiert zu werden?

Selbstverständlich gibt es in einigen Fällen ein paar gute Gründe, Portierungen anstatt der Pakete zu verwenden:

Für die meisten Leute und für die meisten Applikationen ist das Verwenden der Pakete jedoch bei weitem einfacher und selbstverständlich der empfohlene Weg, um Applikationen zu OpenBSD hinzuzufügen.

15.4.7 - Wie optimiere ich diese Portierungen, damit sie bestmögliche Leistung bieten?

Bei OpenBSD geht es um Stabilität und Sicherheit. Genauso wie der GENERIC-Kernel der standardmäßige und der einzige unterstützte Kernel ist, so stellt auch das Portierungsteam sicher, dass die Portierungen funktionieren und stabil sind. Wenn du alle möglichen Übersetzeroptionen aktivieren willst, so musst du das schon selbst machen. Frage bitte nicht auf den Mailinglisten nach, warum etwas nicht funktioniert, wenn du versucht hast, ein paar der versteckten Kniffe zu aktivieren, die die Dinge schneller machen. Generell gilt, dass das Optimieren für 99 % der Anwender nicht nötig ist und vermutlich eine totale Verschwendung von Zeit ist - deiner Zeit, die der Anwender sowie die der Entwickler, die von deinen Problemen lesen, die in Wirklichkeit aber gar keine sind.

15.4.8 - Ich habe eine neue Portierung/ein neues Update vor Wochen bereitgestellt. Warum wird sie/es nicht eingebunden?

Dem Portierungsteam stehen nur begrenzte Ressourcen zur Verfügung und kein Committer konnte sich deine Portierung/dein Update bisher ansehen. So frustrierend es sein mag, ignoriere die Tatsache einfach. Kümmer dich um deine Portierung und sende Updates - vielleicht wird sich jemand darum kümmern. Es ist bereits vorgekommen, dass Leute auf einmal etwas freie Zeit hatten, Portierungen zu committen oder ihr Interesse richtete sich auf einmal auf andere Dinge, was dann plötzlich dazu führte, dass alte Bereitstellungen interessant wurden, wenn man sich an sie erinnerte.

15.5 - Probleme berichten

Wenn du Probleme mit einer bereits existierenden Portierung hast, sende bitte eine E-Mail an den Verantwortlichen. Um herauszufinden, wer der Verantwortliche für die Portierung ist, gib beispielsweise Folgendes ein:
$ cd /usr/ports/archivers/unzip
$ make show=MAINTAINER

Alternativ dazu, falls kein Verantwortlicher angegeben ist oder du ihn/sie nicht erreichen kannst, sende eine E-Mail an die OpenBSD-Portierungs-Mailingliste ports@openbsd.org. Bitte verwende NICHT die misc@openbsd.org-Mailingliste für Portierungsbezogene Fragen.

Stelle in jedem Fall Folgendes bereit:

Für Portierungen, die nicht richtig übersetzt werden können, muss eine vollständige Protokollierung der Erzeugungsphase angegeben werden. Du kannst hierfür das portslogger-Skript verwenden, das sich extra hierfür unter /usr/ports/infrastructure/bin befindet. Ein Beispiel für einen portslogger-Aufruf könnte Folgendes sein:
$ mkdir ~/portslogs
$ cd /usr/ports/archivers/unzip
$ make clean install 2>&1 | /usr/ports/infrastructure/bin/portslogger \
           ~/portslogs
Hiernach solltest du eine Logdatei der Erzeugungsphase in deinem ~/portslogs-Verzeichnis haben, die du dem Verantwortlichen der Portierung senden kannst. Stelle ebenfalls sicher, dass du keine speziellen Optionen während der Übersetzung verwendet hast (z. B. in /etc/mk.conf).

Alternativ dazu kannst du auch Folgendes machen:

15.6 - Wie man uns helfen kann

Es gibt viele Wege, wie du uns helfen kannst. Sie sind hier aufgelistet - sortiert nach der Schwierigkeit.

Hardwarespenden können dazu beitragen, Portierungen auf den verschiedenen Plattformen zu testen, auf denen OpenBSD läuft.

Hinweis: Für alle Erstellungen von neuen Portierungen und das subsequente Testen, oder für das Testen von Portierungsaktualisierungen musst du ein -current-System verwenden! Generell ist das aufgrund der ständigen Änderungen keine schöne Grundlage, sodass du dir sicher sein solltest, ob du -current ständig folgen willst.

[FAQ-Index] [Zum Kapitel 14 - Festplattenkonfiguration]


[back] www@openbsd.org
$OpenBSD: faq15.html,v 1.63 2013/11/13 07:09:30 ajacoutot Exp $