![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[FAQ-Index] [Zum Kapitel 14 - Platteneinrichtung]
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 Binarypackage, das direkt installiert werden kann. Das Ziel des Package-Systems 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 Package-System 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 Packages bereits kompiliert wurden und nun bereitstehen, um auf einem OpenBSD-System eingesetzt werden zu können. Innerhalb von Minuten kann eine große Anzahl Packages heruntergeladen und installiert werden - und alles landet an der richtigen Stelle.
Die Packages- und Ports-Kollektionen unterliegen NICHT der gründlichen Sicherheitsüberprüfung, die für das OpenBSD-Basissystem gilt. Obwohl wir danach streben, die Qualität der Packageskollektion auf hohem Niveau zu halten, stehen zu wenig Entwickler bereit, um die gleiche Robustheit und Sicherheit zu gewährleisten. Selbstverständlich werden so schnell wie möglich Sicherheitsupdates für unterschiedlichste Applikationen eingepflegt; auch die dazugehörigen Sicherheitsupdates für die Packages werden als Snapshots für -current bereitgestellt.
Packages sind die vorkompilierten Binarys von einigen der am meist genutzten Software von Drittanbietern. Packages 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. Genausogut 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.
Packages wirken wie einfache .tgz-Bündel. Im Grunde genommen sind sie es auch doch gibt es einen wichtigen Unterschied: Sie enthalten zusätzliche Packageinformationen. Diese Informationen werden von pkg_add(1) für einige Zwecke genutzt:
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 Packages suchen und ebenfalls alle notwendigen Abhängigkeiten des Packages automatisch herunterladen und installieren.
Eine Liste möglicher Orte, von wo aus Packages 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/4.2/packages/`machine -a`/
2. Beispiel: Installation von einem nahe gelegenen FTP-Mirror
$ export PKG_PATH=ftp://your.ftp.mirror/pub/OpenBSD/4.2/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). Jedes Verzeichnis in der PKG_PATH-Variable MUSS JEDOCH 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 Package gefunden wurde. Wenn das Package 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 Snapshots verwendest, musst du selbstverständlich »4.2« gegen »snapshots« austauschen.
Wenn du den Ports-Tree auf deinem System hast, dann kannst du das Package sehr schnell aufspüren, indem du nach ihm suchst wie es in Den Ports-Tree durchsuchen beschrieben steht.
Es wird dir auffallen, dass bestimmte Packages in verschiedenen Variationen vorliegen; formal Flavors genannt. Andere sind Teile der gleichen Applikation, die separat installiert werden könnten; diese werden Subpackages genannt. Das ganze wird in der Sektion Flavors und Subpackages verwenden genauer erläutert, doch bedeutet Flavor im Grunde nichts anderes, als dass sie mit anderen Optionen konfiguriert wurden. Momentan haben viele Packages Flavors; beispielsweise Datenbankunterstützung, Unterstützung für Systeme ohne X oder weitere Netzwerkfunktionalitäten wie SSL und IPv6 bereitstellen. Jedes Flavor eines Packages hat einen anderen Suffix im Packagenamen. Detailliertere Informationen über Packagenamen können in packages-specs(7) gefunden werden.
Hinweis: Nicht alle möglichen Packages 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 Flavors für einen Port 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 den Port vom Quelltext aus übersetzen. Weitere Informationen darüber, wie du das machst, kannst du im Kapitel Flavors und Subpackages verweden der Portssektion dieses Dokumentes nachlesen.
$ sudo pkg_add -v screen-4.0.3p0
parsing screen-4.0.3p0
installed /etc/screenrc from /usr/local/share/examples/screen/screenrc | 71%
screen-4.0.3p0: 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.
$ sudo pkg_add -i screen
Ambiguous: screen could be screen-4.0.3p0 screen-4.0.3p0-shm screen-4.0.3p0-static
Choose one package
0: <None>
1: screen-4.0.3p0
2: screen-4.0.3p0-shm
3: screen-4.0.3p0-static
Your choice: 1
screen-4.0.3p0: complete
Für einige Packages 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 Package 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
Es ist möglich, mehrere Packagenamen bei einem Aufruf anzugeben, wodurch alle auf einmal installiert werden - neben allen möglichen Abhängigkeiten.
Falls aus irgendeinem Grund du dich gegen die Nutzung von PKG_PATH entscheiden solltest, ist es trotzdem möglich, die absolute Angabe eines Packages 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/4.2/packages/`machine -a`/screen-4.0.3p0.tgz
screen-4.0.3p0: 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 Packages. Einige Ports funktionieren nur auf bestimmten Architekturen; außerdem beschränkt die Leistung bestimmter Architekturen die Anzahl der Packages, die auf diesen kompiliert werden kann.
Bei der Installation eines Packages, 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.3p0
parsing screen-4.0.3p0
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.3p0: complete
$ 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.
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:
$ 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.3p0 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 Packages angegeben wird (oder ein Pfad zu einem Package, das installiert werden soll), wird pkg_info(1) detailliertere Informationen über dieses bestimmte Package ausgeben.
Angenommen, du hättest eine ältere Version von unzip installiert, bevor du diesen Rechner von OpenBSD 4.1 auf 4.2 upgegradet hast. Nun kannst du wie folgt ganz einfach auf das neuere 4.2-Package upgraden:
$ sudo pkg_add -u unzip
unzip-5.52 (extracting): complete
unzip-5.51 (deleting): complete
unzip-5.52 (installing): complete
Clean shared items: complete
Der Aufruf von pkg_add(1) mit der Option -u und keinem Packagenamen wird versuchen, alle installierten Packages 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.
Beginnend mit OpenBSD 4.2 bedeuten mehrere Einträge in PKG_PATH nicht mehr, dass bei Updatevorgä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 jdoch mit der Standardkonfigurationsdatei der neuen Version überschreiben, indem du pkg_add(1) mit der Option -c aufrufst.
Um ein Package zu deinstallieren, nimm einfach den richtigen Namen des Packages, der beim Aufruf von pkg_info(1) angezeigt wird (siehe Installierte Packages auflisten weiter oben) und verwende pkg_delete(1), um Packages zu entfernen. In dem folgenden Beispiel wird das screen-Package 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.3p0: complete
Clean shared items: complete
Hinweis: Oft ist es nicht notwendig, die Versionsnummern und die Flavors mit dem Packagenamen anzugeben, da pkg_delete(1) normalerweise in der Lage ist, diese Namen selbstständig herauszufinden. Du musst den kompletten Packagenamen (in diesem Fall wäre das screen-4.0.3p0) nur dann angeben, wenn eine Verwechslung aufgrund von mehreren installierten Packages mit dem angegebenen Namen möglich wäre; in dem Fall kann pkg_delete(1) nicht wissen, welches Package 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.3p0: complete
Clean shared items: complete
--- screen-4.0.3p0 -------------------
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.
$ sudo pkg_add screen-4.0.3p0
screen-4.0.3p0: complete
Adjusting md5 for /usr/local/info/screen.info-3 from 49fb3fe1cc3a3b0057518459811b6dac to 3b9c7811244fb9f8d83bb27d3a0f60d8
/usr/sbin/pkg_add: Installation of screen-4.0.3p0 failed , partial installation recorded as partial-screen-4.0.3p0
Es ist immer eine gute Idee, teilweise installierte Packages von deinem System zu entfernen und potenzielle Probleme zu lösen, die zu diesem Fehler geführt haben könnten. Wenn soetwas eintritt, dann ist das oft ein Zeichen dafür, dass du kein ordentliches System hast, das vollständig nur von Packages aus installiert wurde sondern mit Software vermischt wurde, die du direkt vom Quelltext aus übersetzt hast.
WICHTIGER HINWEIS: Der Ports-Tree ist nur für erfahrene Anwender gedacht. Es wird jedem nahegelegt, die vorkompilierten Binarypackages 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 Ports-Tree hast, dann wird vorausgesetzt, dass du die Manualseiten und diese FAQ gelesen hast, und dass du in der Lage bist, mit ihm zu arbeiten.
Neben dem Makefile beinhaltet jeder Port ebenfalls mindestens folgende Dinge:
All diese Informationen werden in einer Verzeichnishierarchie unter /usr/ports gespeichert. Die Hierarchie besteht aus drei speziellen Unterverzeichnissen:
Wenn ein Benutzer make(1) in einem Unterverzeichnis eines speziellen Ports 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 des gewünschten Ports forsetzen. All dies passiert in dem Arbeitsverzeichnis, das der Port erstellt. Dies ist entweder ein Unterverzeichnis des Porthauptverzeichnisses (in diesem Fall kann es am Prefix »w-« erkannt werden) oder es ist ein Unterverzeichnis von ${WRKOBJDIR}, falls die Variable WRKOBJDIR gesetzt wurde (siehe Zusätzliche Konfiguration des Ports-Systems).
Hinweis: Ports werden niemals direkt auf deinem System installiert! Sie verwenden ein Scheininstallationsverzeichnis. Alles, was dort installiert wird, wird in ein Package zusammengefasst (welches dann im packages/-Unterverzeichnis des Ports-Trees abgelegt wird, wie es zuvor beschrieben wurde). Einen Port installieren bedeutet daher in Wirklichkeit: Ein Package erstellen und dieses dann installieren!
Weitere Informationen über das Ports-System können in diesen Manualseiten gefunden werden:
| Quelle | Form | Flavor | |||
| -release | -stable | Snapshots | -current | ||
| CD-ROM | .tar.gz | x | - | - | - |
| FTP-Mirror | .tar.gz | x | - | x | - |
| AnonCVS | cvs checkout | x | x | - | x |
Auf der CD-ROM und den FTP-Mirrors 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/4.2/ports.tar.gz
$ cd /usr
$ sudo tar xzf /tmp/ports.tar.gz
Die Snapshots, die auf den FTP-Mirrors vorliegen, werden täglich vom -current-Ports-Tree erstellt. Diese Snapshots kannst du im Verzeichnis pub/OpenBSD/snapshots finden. Wenn du einen Snapshot vom Ports-Tree verwendest, dann solltest du einen dazu passenden OpenBSD-Snapshot haben. Stelle sicher, dass du deinen Ports-Tree 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 Ports-Trees per AnonCVS hast.
HINWEIS: Dieses Kapitel führt einige zusätzliche systemweite Einstellungen für das Erzeugen von Applikationen aus den Ports 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 Ports-Tree zu überprüfen, kannst du das Ports-System so konfigurieren, dass einige weitere Sicherheitsmaßnahmen genutzt werden. Die Portsinfrastruktur 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 Ports-System nicht schützen können, wenn du dich für die Installation einer bösartigen Software entschieden hast.
SUDO=/usr/bin/sudo
# chgrp -R wsrc /usr/ports
# find /usr/ports -type d -exec chmod g+w {} \;
USE_SYSTRACE=Yes
Es ist auch möglich, einen schreibgeschützten Ports-Tree zu nutzen, indem man die Verzeichnisse trennt, die während der Erzeugung des Ports Schreibrechte haben müssen:
WRKOBJDIR=/usr/obj/ports
DISTDIR=/usr/distfiles
PACKAGE_REPOSITORY=/usr/packages
$ cd /usr/ports
$ make search key=rsnapshot
Port: rsnapshot-1.2.9
Path: net/rsnapshot
Info: remote filesystem snapshot utility
Maint: Sigfred Haversen
Index: net
L-deps:
B-deps: :net/rsync
R-deps: :net/rsync
Archs: any
Dieser Mechanismus ist allerdings ein recht simpler, da er nur awk(1) auf die Indexdatei des Ports anwendet. Mit OpenBSD 4.0 wurde ein neuer Port namens »sqlports« erstellt, der genaue Suchanfragen mit SQL erlaubt. Es handelt sich dabei um eine SQLite-Datenbank, doch kann mit der Portsinfrastruktur im Grunde jedes Datenbankformat erstellt werden.
Füge das sqlports-Package einfach mit pkg_add(1) hinzu. In diesem Fall benötigst du ebenfalls das sqlite3-Package. 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>
$ 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 Ports-System viele Dinge automatisch. Es bezieht, extrahiert und patcht den Quelltext, konfiguriert und erzeugt (kompiliert) den Quelltext, installiert die Dateien in ein Scheinverzeichnis, erstellt ein Package (mit Bezug auf die Packinglist) und installiert das Package auf dein System (normalerweise unter /usr/local/). Das Ports-System macht das sogar rekursiv für alle Abhängigkeiten des Ports. 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 eines solchen Ports erhältst, geschah das meist aus einem dieser beiden Gründe:
$ make clean
===> Cleaning for rsnapshot-1.2.9
$ make clean=depends
===> Cleaning for rsync-2.6.9
===> Cleaning for rsnapshot-1.2.9
$ make clean=dist
===> Cleaning for rsnapshot-1.2.9
===> Dist cleaning for rsnapshot-1.2.9
$ make clean=flavors
$ make package BULK=Yes
$ make uninstall
===> Deinstalling for rsnapshot-1.2.9
rsnapshot-1.2.9: complete
Clean shared items: complete
$ 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
$ make clean=packages
===> Cleaning for rsnapshot-1.2.9
rm -f /usr/ports/packages/i386/all/rsnapshot-1.2.9.tgz
Der erste Mechanismus wird Flavors genannt. Ein Flavor verweist normalerweise auf einen bestimmten Satz Kompilierungsoptionen. Zum Beispiel haben einige Applikationen ein no_x11-Flavor, das auf Systemen ohne X genutzt werden kann. Einige Shells haben ein static-Flavor, das eine statisch gelinkte Version erzeugen wird. Es gibt Ports, die verschiedene Flavors 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 Flavors verwenden, wenn ein Package nicht für das Flavor bereitgestellt wurde, nach dem du suchst. In diesem Fall musst du das gewünschte Flavor angeben und selbst den Port erzeugen.
Die meisten Flavors haben ihr eigenes Arbeitsverzeichnis während der Erzeugungsphase; ebenfalls wird jedes Flavor in ein Package mit dem zum Flavor gehörigen Namen gepackt, um Verwechslungen mit anderen auszuschließen. Um die Flavors eines bestimmten Ports anzeigen zu lassen, würdest du in das Unterverzeichnis wechseln und Folgendes aufrufen:
$ make show=FLAVORS
Der zweite Mechanismus wird Subpackages genannt. Ein Portierer könnte entscheiden, dass Subpackages für verschiedene Teile der gleichen Applikation erstellt werden, falls diese logisch getrennt werden können. Dir werden oft Subpackages für den Client- und für den Serverteil eines Programmes begegnen. Manchmal wird auch sehr ausgiebige Dokumentation in ein separates Subpackage gebündelt, da dieses viel Plattenspeicher in Anspruch nimmt. Ebenfalls werden zusätzliche Funktionalitäten in eigene Packages ausgelagert, falls diese eine große Anzahl zusätzlicher Abhängigkeiten mit sich bringen. Der Portierer entscheidet ebenfalls, welches Subpackage das Haupt-Subpackage 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 Ports werden in mehrere Packages aufgeteilt. Mit make install wird nur das Haupt-Subpackage installiert.
Um die unterschiedlichen Packages anzuzeigen, die von einem Port erzeugt werden, verwende:
$ make show=PACKAGES
Mit make install wird nur das erste Subpackage installiert.
Um alle zu installieren, verwende:
$ make install-all
Um die verschiedenen verfügbaren Subpackages für einen Port anzuzeigen, verwende:
$ make show=MULTI_PACKAGES
$ env SUBPACKAGE="-server" make install
Hinweis: Der Subpackagesmechanismus verarbeitet nur Packages - es werden keine Konfigurationsoptionen vor dem Erzeugen des Ports geändert. Du müsstest hierfür Flavors verwenden.
Es ist sehr wahrscheinlich, dass du ein System und einen Ports-Tree verwendest, die nicht synchron sind.
Bitte was?
Ein weiterer häufiger Grund ist eine fehlende X11-Installation. Selbst wenn der Port, den du übersetzen willst, keine direkte X11-Abhänigkeit vorweist, so könnten Subpackages oder weitere Abhängigkeiten X11-Header und -Bibliotheken voraussetzen. Übersetzen von Ports 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 Ports gibt es dennoch »no_x11«-Packages, die du auch ohne X11 auf deinem System installieren kannst.
Für 4.2 gilt, dass für viele Packages, die libexpat verwenden, xbase42.tgz installiert sein muss; selbst wenn keine grafische Funktionalität gewünscht ist. In 4.3 wird dieses Problem behoben sein.
WARNUNG: Mische NIEMALS Versionen der Ports 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 Ports-Collection 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. Deine Spenden können einen Unterschied machen, auf wie vielen Plattformen die Ports getestet werden.
Einige individuelle Ports können gerade deshalb hinter den Mainstreamversionen liegen. In der Ports-Collection könnte eine Version eines Programms vom Januar sein, obwohl eine neue Version des Programms von dessen Entwicklern im Mai - also drei Monate später - veröffentlicht wurde. Oft ist das eine schwere Entscheidung; die neue Version könnte Probleme unter OpenBSD haben, die der Verantwortliche beheben muss - oder aber die Entwickler haben die Software einfach schlechter gemacht als die alte: OpenBSD könnte andere Ziele als die Mainstreamentwickler der anderen Projekte haben, was manchmal dazu führt, dass Funktionalitäts-, Entwurfs- oder Implementationsänderungen der Software aus Sicht der OpenBSD-Entwickler nicht hinnehmbar sind. Das Update könnte aber auch einfach nach hinten verschoben worden sien, da die neue Version einfach nicht als wichtig genug für eine Aktualisierung angesehen wird.
Wenn du wirklich unbedingt eine neue Version eines Ports benötigst, kannst du den Verantwortlichen des Ports bitten, eine Aktualisierung des Ports zu veröffentlichen (siehe unten, wie man herausfindet, wer der Verantwortliche ist). Wenn du helfen kannst, dann ist es natürlich noch besser.
Du kannst helfen. Ziehe das Erstellen eines eigenen Ports in Betracht. Es gibt einige Dokumentationen darüber: Einen OpenBSD-Port erzeugen. Lies es - und lies es wieder. Insbesondere den Teil über das Verwalten deines Ports. Versuche dann, einen eigen Port zu erstellen und teste ihn sorgfältig Schritt für Schritt. Wenn er schlussendlich einwandfrei für dich arbeitet, sende ihn an die Portsmailingliste ports@openbsd.org. Die Chancen, eine Rückmeldung und Testberichte von anderen Leuten zu erhalten, stehen gut. Wenn die Tests erfolgreich sind wird dein Port in Betracht gezogen, in den Ports-Tree übernommen zu werden.
Weitere Antworten hierzu können ebenfalls in der FAQ 1 gefunden werden.
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 jedes einzelnen Ports auf allen Plattformen gewährleisten zu können, doch ist es während dem Entwicklungszyklus sehr wahrscheinlich, dass das mit einigen Ports 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. Ein typisches Beispiel ist CVSup - ein Werkzeug, das oft zum Folgen des OpenBSD-Source-Trees genutzt wird. Um CVSup auf einem durchschnittlich schnellen System mit guter Internetanbindung zu installieren dauert ca. zehn Sekunden - das ist die Zeit, die zum Download und Entpacken einer einzelnen 779 kB großen Packagedatei benötigt wird. Im Gegensatz dazu ist das Erzeugen von CVSup auf der gleichen Maschine vom Quelltext aus eine riesige Aufgabe, die viele Werkzeuge und einen Bootstrap eines Compilers benötigt; das ganze nimmt mehr als eine halbe Stunde auf der gleichen Maschine in Anspruch. Andere Applikationen wie zum Beispiel Mozilla oder or KDE können Stunden und riesige Mengen Plattenspeicher und RAM/Swap in Anspruch nehmen, um erzeugt werden zu können. 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-Mirror darauf warten, installiert zu werden?
Selbstverständlich gibt es ein paar gute Gründe, in einigen Fällen Ports statt Packages zu verwenden:
$ 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-Portsmailingliste ports@openbsd.org. Bitte verwende NICHT die misc@openbsd.org-Mailingliste für portsbezogene Fragen.
Stelle in jedem Fall Folgendes bereit:
$ mkdir ~/portslogs
$ cd /usr/ports/archivers/unzip
$ make clean install 2>&1 | /usr/ports/infrastructure/build/portslogger \
~/portslogs
Alternativ dazu kannst du auch Folgendes machen:
[FAQ-Index] [Zum Kapitel 14 - Platteneinrichtung]
![[back]](../../images/back.gif){kind=small}
www@openbsd.org