---
title: Kapitel 5. Die Konfiguration des Makefile
prev: books/porters-handbook/slow
next: books/porters-handbook/special
showBookMenu: true
weight: 5
params:
  path: "/books/porters-handbook/makefile/"
---

[[flavors]]
= Die Konfiguration des Makefile
:doctype: book
:toc: macro
:toclevels: 1
:icons: font
:sectnums:
:sectnumlevels: 6
:sectnumoffset: 5
:partnums:
:source-highlighter: rouge
:experimental:
:images-path: books/porters-handbook/

ifdef::env-beastie[]
ifdef::backend-html5[]
:imagesdir: ../../../../images/{images-path}
endif::[]
ifndef::book[]
include::shared/authors.adoc[]
include::shared/mirrors.adoc[]
include::shared/releases.adoc[]
include::shared/attributes/attributes-{{% lang %}}.adoc[]
include::shared/{{% lang %}}/teams.adoc[]
include::shared/{{% lang %}}/mailing-lists.adoc[]
include::shared/{{% lang %}}/urls.adoc[]
toc::[]
endif::[]
ifdef::backend-pdf,backend-epub3[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]
endif::[]

ifndef::env-beastie[]
toc::[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]

Das Konfigurieren des [.filename]#Makefile# ist sehr einfach und wir schlagen vor, dass Sie zunächst einen Blick auf vorhandene Beispiele werfen. Zusätzlich gibt es ein <<porting-samplem,Beispiel eines Makefile>> in diesem Handbuch. Schauen Sie es sich an und verfolgen Sie bitte die Abfolge der Variablen und Abschnitte in dieser Vorlage. Damit erleichtern Sie es anderen, Ihren Port zu lesen.

Bedenken Sie bitte die folgenden Probleme in der hier vorgegebenen Abfolge der Unterabschnitte dieses Kapitels, wenn Sie Ihr neues [.filename]#Makefile# erstellen:

[[makefile-source]]
== Der originale Quelltext

Liegt der Quelltext in `DISTDIR` als eine standardisierte und mit gzip gepackte Datei in der Art [.filename]#foozolix-1.2.tar.gz#? Falls ja, können Sie zum nächsten Schritt übergehen. Falls nicht, sollten Sie versuchen, die Variablen `DISTVERSION`, `DISTNAME`, `EXTRACT_CMD`, `EXTRACT_BEFORE_ARGS`, `EXTRACT_AFTER_ARGS`, `EXTRACT_SUFX`, oder `DISTFILES` zu ändern. Das hängt davon ab, wie fremdartig das Distributionsfile Ihres Ports ist (der häufigste Fall ist `EXTRACT_SUFX=.tar.Z`, wenn der Tarball durch ein normales `compress` und nicht durch `gzip` gepackt wurde).

Im schlimmsten Fall können Sie einfach Ihre eigene Vorgabe mittels `do-extract` erzeugen und die Standardvorgabe überschreiben; aber dies sollte in den wenigsten Fällen, wenn überhaupt, notwendig sein.

[[makefile-naming]]
== Bezeichnungen

Der erste Teil des [.filename]#Makefile# beschreibt die Versionsnummer des Ports und führt ihn in der richtigen Kategorie auf.

=== `PORTNAME` und `PORTVERSION`

Setzen Sie bitte die Variable `PORTNAME` auf den Basisnamen Ihres Ports und die Variable `PORTVERSION` auf dessen Versionsnummer.

[[makefile-naming-revepoch]]
=== `PORTREVISION` und `PORTEPOCH`

==== `PORTREVISION`

Die `PORTREVISION`-Variable ist ein streng monoton wachsender Wert, welcher auf 0 zurückgesetzt wird, nachdem `PORTVERSION` erhöht wurde (d.h. jedes Mal, wenn ein offizielles Release erfolgt). Sie wird an den Namen des Pakets angehängt, wenn sie ungleich 0 ist. Änderungen an `PORTREVISION` werden von automatisierten Werkzeugen (z.B. man:pkg_version[1]) genutzt, um anzuzeigen, dass ein neues Paket verfügbar ist.

`PORTREVISION` sollte jedes Mal erhöht werden, wenn eine Änderung am Port erfolgt, die beträchtliche Auswirkungen auf den Inhalt oder Struktur des aus dem Port erzeugten Pakets zur Folge hat.

Beispiele dafür, wann `PORTREVISION` erhöht werden sollte:

* Hinzufügen von Patches, welche Sicherheitslücken schließen, Fehler beseitigen oder neue Funktionalität zum Port hinzufügen.
* Änderungen am [.filename]#Makefile# des Ports, welche compile-time-Optionen hinzufügen oder entfernen.
* Änderungen bezüglich Packliste oder am Verhalten während der Installation des Pakets (d.h. Änderungen an einem Skript, welches Ausgangsdaten für das Paket erzeugt, wie z.B. SSH-Hostschlüssel).
* Versionssprung einer Shared-Library, welche eine Abhängigkeit dieses Ports ist (In diesem Fall würde ein Anwender bei der Installation des alten Pakets scheitern, falls er eine neue Version der Abhängigkeit bereits installiert hat, weil nach der alten Bibliothek libfoo.x anstatt nach libfoo.(x+1)) gesucht wird).
* Schleichende Änderungen am Distfile, welche bedeutende funktionale Änderungen verursachen, d.h. Änderungen des Distfile erfordern eine Korrektur an [.filename]#distinfo#, ohne dass damit zusammenhängend die `PORTVERSION` verändert wird, obwohl ein `diff -ru` zwischen der alten und der neuen Version bedeutende Veränderungen am Code nachweist.

Beispiele für Änderungen, welche keine Erhöhung von `PORTREVISION` erfordern:

* Stilistische Änderungen am Grundgerüst des Ports ohne funktionale Änderungen am daraus resultierenden Paket.
* Änderungen an der Variable `MASTER_SITES` oder andere funktionale Änderungen, welche das resultierende Paket nicht verändern.
* Marginale Patches am Distfile wie die Korrektur von Tippfehlern, welche nicht wichtig genug sind, um dem Benutzer die Bürde eines Upgrades aufzuerlegen.
* Build fixes, die ein Paket erst kompilierbar machen, welches ohne diese Änderungen vorher nicht erzeugt werden konnte (solange die Änderungen keine funktionale Differenz bringen auf Plattformen, auf denen dieses Paket schon vorher gebaut werden konnte). Da `PORTREVISION` den Inhalt des Pakets wiederspiegelt, ist es nicht notwendig `PORTREVISION` zu erhöhen, wenn das Paket vorher nicht erstellt werden konnte.

Als Faustregel gilt: Stellen Sie sich die Frage, ob die durchgeführte Änderung am Port jedem hilft (entweder aufgrund einer Verbesserung, Beseitigung eines Fehlers, oder der Annahme, dass das neue Paket überhaupt erst funktioniert) und wägen Sie es gegen den Umstand ab, dass jedermann, der seine Ports-Sammlung regelmässig auf dem neuesten Stand hält, zu einer Aktualisierung gezwungen wird. Falls Sie die Frage positiv beantworten sollten, erhöhen Sie die Variable `PORTREVISION`.

==== `PORTEPOCH`

Von Zeit zu Zeit geschieht es, dass irgendjemand (Drittanbieter von Software oder FreeBSD Ports Committer) etwas Dummes tut und eine Version einer Software veröffentlicht, deren Versionsnummer niedriger ist als die der vorherigen. Ein Beispiel hierfür ist ein Port, der von foo-20000801 auf foo-1.0 geändert wird (der Erstere wird fälschlicherweise als neue Version behandelt, weil 2000801 ein numerisch größerer Wert ist als 1).

In Situationen wie diesen sollte die Variable `PORTEPOCH` erhöht werden. Wenn `PORTEPOCH` größer als 0 ist, wird sie an den Namen des Pakets angehängt, wie in Abschnitt 0 oberhalb bereits beschrieben. `PORTEPOCH` darf niemals verringert oder auf 0 gesetzt werden, weil der Vergleich des Pakets mit einem früheren Zeitpunkt scheitern würde (d.h. das Paket würde niemals als veraltet erkannt werden): Die neue Versionsnummer (`1.0,1` im obigen Beispiel) ist immer noch numerisch kleiner als die vorherige Version (2000801), aber das Suffix `,1` wird von automatisierten Werkzeugen gesondert behandelt und wird als größer erkannt, als das implizit angenommene Suffix `,0` im früheren Paket.

Das Entfernen oder Zurücksetzen von `PORTEPOCH` führt zu unendlichem Ärger. Wenn Sie die obigen Ausführungen nicht vollständig verstanden haben, lesen Sie es bitte unbedingt nochmals bis Sie es vollständig verinnerlicht haben, oder fragen Sie vor jeder Änderung auf den Mailinglisten nach!

Es wird erwartet, dass `PORTEPOCH` für die weitaus überwiegende Zahl der Ports nicht verwendet wird und der verantwortungsvolle und vorausschauende Umgang mit `PORTVERSION` macht es meist überflüssig, falls ein späteres Release die Versionsstruktur ändern sollte. Vorsicht ist geboten, wenn ein Release einer Drittanbieter-Software ohne eine offizielle Versionsnummer veröffentlicht wird, wie z.B. bei "Snapshot-Versionen". Man ist versucht, das Release mit dem jeweiligen Datum zu bezeichnen, was unweigerlich zu den oben beschriebenen Problemen führt, wenn das nächste "offizielle" Release erscheint.

Wenn z.B. ein Snapshot zum Datum 20000917 veröffentlicht wird und die vorherige Version der Software war 1.2, dann sollte der Snapshot die `PORTVERSION` 1.2.20000917 oder ähnlich erhalten und nicht 20000917, damit das nachfolgende Release, angenommen 1.3, immer noch einen größeren numerischen Wert aufweist.

==== Beispiel für den Gebrauch von `PORTREVISION` und `PORTEPOCH`

Der `gtkmumble`-Port, Version `0.10`, befindet sich in der Ports-Sammlung:

[.programlisting]
....
PORTNAME=       gtkmumble
PORTVERSION=    0.10
....

`PKGNAME` wird zu `gtkmumble-0.10`.

Ein Sicherheitsloch wurde entdeckt, das einen lokalen Patch von FreeBSD erforderlich macht. `PORTREVISION` wird entsprechend erhöht.

[.programlisting]
....
PORTNAME=       gtkmumble
PORTVERSION=    0.10
PORTREVISION=   1
....

`PKGNAME` wird zu `gtkmumble-0.10_1`

Eine neue Version wird vom Software-Drittanbieter veröffentlicht, bezeichnet mit der Version `0.2` (es stellt sich heraus, dass der Autor beabsichtigte, dass `0.10` eigentlich `0.1.0` bedeuten sollte, nicht "was kommt nach 0.9" - Hoppla, aber nun ist es zu spät). Da die neue Unterversion `2` numerisch kleiner ist als die vorherige Version `10`, muss `PORTEPOCH` erhöht werden, um sicherzustellen, dass das neue Paket auch als "neuer" erkannt wird. Da es ein neues Release des Drittanbieters ist, wird `PORTREVISION` auf 0 zurückgesetzt (oder aus dem [.filename]#Makefile# entfernt).

[.programlisting]
....
PORTNAME=       gtkmumble
PORTVERSION=    0.2
PORTEPOCH=      1
....

`PKGNAME` wird zu `gtkmumble-0.2,1`

Das nächste Release ist 0.3. Da `PORTEPOCH` niemals verringert wird, sind die Versionsvariablen nun wie folgt:

[.programlisting]
....
PORTNAME=       gtkmumble
PORTVERSION=    0.3
PORTEPOCH=      1
....

`PKGNAME` wird zu `gtkmumble-0.3,1`

[NOTE]
====
Falls `PORTEPOCH` mit diesem Upgrade auf `0` zurückgesetzt worden wäre, dann würde jemand, der das Paket `gtkmumble-0.10_1` installiert hätte, das Paket `gtkmumble-0.3` nicht als neuer erkennen, da `3` immer noch numerisch kleiner ist als `10`. Bedenken Sie, dass genau dies der springende Punkt an `PORTEPOCH` ist.
====

=== `PKGNAMEPREFIX` und `PKGNAMESUFFIX`

Zwei optionale Variablen, `PKGNAMEPREFIX` und `PKGNAMESUFFIX`, werden verknüpft mit `PORTNAME` und `PORTVERSION`, um `PKGNAME` zu bilden als `${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}`. Stellen Sie bitte unbedingt sicher, dass diese Variablen den <<porting-pkgname,Richtlinien für einen guten Paketnamen>> entsprechen. Insbesondere dürfen Sie _keinesfalls_ einen Bindestrich (`-`) in `PORTVERSION` verwenden. Falls das Paket den _language-_ oder _-compiled.specifics_-Teil aufweist (siehe unten) benutzen Sie `PKGNAMEPREFIX` oder `PKGNAMESUFFIX` respektive. Machen Sie diese Variablen nicht zum Bestandteil von `PORTNAME`!

=== `LATEST_LINK`

Die Umgebungsvariable `LATEST_LINK` wird während der Paketerstellung verwendet, um einen Kurznamen festzulegen, der danach von `pkg_add -r` genutzt werden kann. Dadurch wird es beispielsweise möglich, die aktuelle Perl-Version durch einen einfachen Aufruf von `pkg_add -r perl` zu installieren (ohne die Angabe der korrekten Versionsnummer). Dieser Name muss eindeutig sowie "offensichtlich" sein.

In einigen Fällen können mehrere Versionen einer Applikation gleichzeitig in der Ports-Sammlung sein. Das index build- und das package build-System müssen nun in der Lage sein, diese als unterschiedliche Ports zu erkennen, obwohl diese Versionen alle die gleichen Variablen `PORTNAME`, `PKGNAMEPREFIX` und sogar `PKGNAMESUFFIX` aufweisen. In solchen Fällen sollte die optionale Variable `LATEST_LINK` auf einen unterschiedlichen Wert für alle Ports gesetzt werden mit Ausnahme des "Haupt-Ports". Beispiele hierfür sind die [.filename]#lang/gcc46# und [.filename]#lang/gcc#-Ports und die [.filename]#www/apache*#-Familie. Wenn Sie die Umgebungsvariable `NO_LATEST_LINK` setzen, wird kein Link erzeugt, was für alle Versionen (aber nicht für die "Hauptversion") nützlich sein kann. Beachten Sie bitte, dass die Frage der Auswahl der "wichtigsten" Version ("am populärsten", "am besten Unterstützt", "zuletzt gepatcht" usw.) ausserhalb der Möglichkeiten dieses Handbuches liegt. Wir sagen Ihnen nur, wie Sie die anderen Ports spezifizieren, nachdem Sie den "Haupt-Port" erkoren haben.

[[porting-pkgname]]
=== Namensregeln für Pakete

Im Folgenden finden Sie die Regeln für die Benennung Ihrer Pakete. Diese sollen gewährleisten, dass das Paketverzeichnis leicht zu durchsuchen ist, da es bereits abertausende Pakete gibt und die Nutzer sich mit Schauder abwenden, wenn Ihre Augen überstrapaziert werden!

Der Paketname soll aussehen wie [.filename]#language_region-name-compiled.specifics-version.numbers#.

Der Paketname ist definiert als `${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}`. Stellen Sie bitte sicher, dass die Variablen Ihres Ports diesem Format entsprechen.

. FreeBSD bemüht sich ausserordentlich, die Landessprachen seiner Nutzer zu unterstützen. Die _language-_Variable soll eine Abkürzung mit 2 Buchstaben sein der Sprachen gemäß ISO-639, falls der Port für eine bestimmte Sprache spezifisch ist. Beispiele hierfür sind `ja` für Japanisch, `ru` für Russisch, `vi` für Vietnamesisch, `zh` für Chinesisch, `ko` für Koreanisch und `de` für Deutsch.
+ 
Sollte der Port spezifisch sein für eine gewisse Region innerhalb eines Sprachraumes, dann fügen Sie bitte auch den Ländercode mit 2 Buchstaben hinzu. Beispiele sind `en_US` für nordamerikanisches Englisch und `fr_CH` für schweizerisches Französisch.
+ 
Der __language-__Teil muss in der `PKGNAMEPREFIX`-Variable gesetzt werden.
. Der erste Buchstabe des [.filename]#name#-Teils muss kleingeschrieben werden (der Rest des Namens kann Großbuchstaben enthalten. Daher seien Sie bitte umsichtig, wenn Sie den Namen einer Software konvertieren, welche Grossbuchstaben enthält). Es ist Tradition, `Perl 5`-Module durch ein vorstehendes `p5-` und durch Umwandlung des doppelten Doppelpunktes in Bindestriche zu bezeichnen. So wird z.B. aus dem `Data::Dumper`-Modul der `p5-Data-Dumper`-Port.
. Vergewissern Sie sich, dass der Name des Ports und seine Versionsnummer klar getrennt sind und in den Variablen `PORTNAME` und `PORTVERSION` stehen. Der einzige Grund, um in `PORTNAME` einen Versionsteil aufzunehmen ist der, dass die Software wirklich so bezeichnet wird, wie z.B. die Ports [.filename]#textproc/libxml2# oder [.filename]#japanese/kinput2-freewnn#. Ansonsten sollte `PORTNAME` keine versionsspezifischen Bestandteile aufweisen. Es ist vollkommen normal, dass viele Ports den gleichen `PORTNAME` aufweisen wie z.B. die [.filename]#www/apache*#-Ports. In diesem Falle werden unterschiedliche Versionen (und unterschiedliche Indexeinträge) unterschieden durch die Werte von `PKGNAMEPREFIX`, `PKGNAMESUFFIX` und `LATEST_LINK`.
. Falls der Port mit verschiedenen, <<makefile-masterdir,fest kodierten Vorgaben>> (üblicherweise Teil des Verzeichnisnamens in einer Familie von Ports) gebaut werden kann, dann soll der _-compiled.specifics_-Teil die einkompilierten Vorgaben anzeigen (der Bindestrich ist optional). Beispiele hierfür sind Papiergrößen und Font-Einheiten.
+ 
Der _-compiled.specifics_-Teil muss in der Variablen `PKGNAMESUFFIX` gesetzt werden.
. Die Versionszeichenfolge sollte einen Bindestrich (`-`) am Schluss haben und eine von Punkten getrennte Liste von Integer-Zahlen und kleingeschriebenen Buchstaben sein. Es ist nicht zulässig, einen weiteren Bindestrich innerhalb des Versionsstrings zu verwenden! Die einzige Ausnahme hiervon ist die Zeichenfolge `pl` (bedeutet "patchlevel"), welche _nur_ dann gebraucht werden darf, wenn die Applikation über keine Haupt- oder Unterversionsnummern verfügt. Wenn die Versionsbezeichnung der Software Zeichenketten wie "alpha", "beta", "rc" oder "pre" enthält, dann nehmen Sie bitte den ersten Buchstaben daraus und setzen ihn unmittelbar hinter einen Punkt. Falls die Versionszeichenfolge nach diesem Punkt fortgesetzt wird, sollen die Zahlen ohne einen Punkt zwischen den einzelnen Buchstaben folgen.
+ 
Das Ziel ist es, die Ports anhand der Versionszeichenfolge zu sortieren. Stellen Sie bitte unbedingt sicher, dass die Bestandteile der Versionsnummer immer durch einen Punkt getrennt sind und falls Datumsangaben verwendet werden, dass diese im Format `0.0.yyyy.mm.dd` und nicht `dd.mm.yyyy` oder gar dem nicht Y2K-kompatiblen Format `yy.mm.dd` vorliegen. Es ist wichtig, dass die Versionsnummer mit `0.0.` beginnt, da die Versionsnummer im Falle einer Veröffentlichung auf jeden Fall kleiner als `yyyy` sein wird.

Hier sind einige reale Beispiele, die aufzeigen, wie man den Namen einer Applikation zu einem vernünftigen Paketnamen umwandelt:

[.informaltable]
[cols="1,1,1,1,1,1", frame="none", options="header"]
|===
| Softwarename
| PKGNAMEPREFIX
| PORTNAME
| PKGNAMESUFFIX
| PORTVERSION
| Grund

|mule-2.2.2
|(leer)
|mule
|(leer)
|2.2.2
|Keine Änderung erforderlich

|EmiClock-1.0.2
|(leer)
|emiclock
|(leer)
|1.0.2
|keine Großbuchstaben für einzelne Applikationen

|rdist-1.3alpha
|(leer)
|rdist
|(leer)
|1.3.a
|Keine Zeichenketten wie `alpha` erlaubt

|es-0.9-beta1
|(leer)
|es
|(leer)
|0.9.b1
|keine Zeichenketten wie `beta` erlaubt

|mailman-2.0rc3
|(leer)
|mailman
|(leer)
|2.0.r3
|keine Zeichenketten wie `rc` erlaubt

|v3.3beta021.src
|(leer)
|tiff
|(leer)
|3.3
|Was sollte denn das eigentlich sein?

|tvtwm
|(leer)
|tvtwm
|(leer)
|pl11
|Versionsstring zwingend erforderlich

|piewm
|(leer)
|piewm
|(leer)
|1.0
|Versionsstring zwingend erforderlich

|xvgr-2.10pl1
|(leer)
|xvgr
|(leer)
|2.10.1
|`pl` nur erlaubt, wenn keine Versionsnummer vorhanden

|gawk-2.15.6
|ja-
|gawk
|(leer)
|2.15.6
|Japanische Sprachversion

|psutils-1.13
|(leer)
|psutils
|-letter
|1.13
|Papergröße beim Paketbau fix kodiert

|pkfonts
|(leer)
|pkfonts
|300
|1.0
|Paket für 300 DPI Schriftarten
|===

Falls es in der Originalquelle überhaupt keinen Anhaltspunkt für irgendeine Versionsbezeichnung gibt und es unwahrscheinlich ist, dass der Autor jemals eine neue Version veröffentlichen wird, dann setzen Sie bitte die Version einfach auf `1.0` (wie im obigen Beispiel `piewm`). Sie können auch den Autor fragen oder eine Datumszeichenfolge in der Art `0.0.yyyy.mm.dd` als Version verwenden.

[[makefile-categories]]
== Kategorisierung

=== `CATEGORIES`

Wenn ein Paket erzeugt wird, dann wird es unter [.filename]#/usr/ports/packages/All# abgelegt und von einem oder mehreren Unterverzeichnissen werden auf [.filename]#/usr/ports/packages# Links erstellt. Die Namen dieser Unterverzeichnisse werden durch die Variable `CATEGORIES` festgelegt. Dies geschieht, um dem Nutzer zu helfen, eine große Zahl von Paketen auf einer FTP-Webseite oder einer CD/DVD zu durchsuchen. Bitte werfen Sie einen Blick auf die <<porting-categories,Aktuelle Liste der Kategorien>> und suchen Sie die beste Kategorie für Ihren Port aus.

Diese Liste legt auch fest, an welcher Stelle in der Ports-Sammlung der Port eingefügt wird. Falls Sie mehrere Kategorien angeben wird angenommen, dass die Dateien des Ports im Unterverzeichnis mit dem Namen der ersten angegebenen Kategorie liegen. Schauen Sie bitte <<choosing-categories,unten>> für weitere Informationen darüber, wie man die richtige Kategorie bestimmt.

[[porting-categories]]
=== Aktuelle Liste der Kategorien

Hier ist die aktuelle Liste der Kategorien. Die mit einem Asterisk (`*`) bezeichneten sind _virtuelle_ Kategorien, also solche, welche über kein eigenes Unterverzeichnis in der Ports-Sammlung verfügen. Sie werden nur als Sekundärkategorien benutzt und sind nur für Suchzwecke eingerichtet worden.

[NOTE]
====
Für nicht-virtuelle Kategorien finden Sie eine einzeilige Beschreibung in der Variable `COMMENT` im [.filename]#Makefile# des jeweiligen Unterverzeichnisses.
====

[.informaltable]
[cols="1,1,1", frame="none", options="header"]
|===
| Kategorie
| Beschreibung
| Anmerkung

|[.filename]#accessibility#
|Ports für behinderte Menschen.
|

|[.filename]#afterstep*#
|Ports für den http://www.afterstep.org[AfterStep] Window Manager.
|

|[.filename]#arabic#
|Arabische Sprachunterstützung.
|

|[.filename]#archivers#
|Archivierungswerkzeuge.
|

|[.filename]#astro#
|Ports für Astronomie.
|

|[.filename]#audio#
|Sound-Unterstützung.
|

|[.filename]#benchmarks#
|Benchmarking-Werkzeuge.
|

|[.filename]#biology#
|Software für Biologie.
|

|[.filename]#cad#
|CAD-Werkzeuge.
|

|[.filename]#chinese#
|Chinesische Sprachunterstützung.
|

|[.filename]#comms#
|Kommunikationsprogramme.
|Hauptsächlich Software für serielle Schnittstellen.

|[.filename]#converters#
|Zeichensatz-Konverter.
|

|[.filename]#databases#
|Datenbanken.
|

|[.filename]#deskutils#
|Dinge, die vor der Erfindung des Computers auf dem Schreibtisch waren.
|

|[.filename]#devel#
|Entwicklungs-Werkzeuge.
|Legen Sie keine Bibliotheken hier ab, nur weil es Bibliotheken sind, es sei denn, sie gehören wirklich nirgendwo anders hin.

|[.filename]#dns#
|DNS-bezogene Software.
|

|[.filename]#docs*#
|Meta-Ports für die FreeBSD-Dokumentation.
|

|[.filename]#editors#
|allgemeine Editoren.
|Spezielle Editoren gehören in Ihre jeweilige Kategorie, (z.B. gehört ein mathematischer Formeleditor in [.filename]#math#).

|[.filename]#elisp*#
|Emacs-lisp-Ports.
|

|[.filename]#emulators#
|Emulatoren für andere Betriebssysteme. 
|Terminal-Emulatoren gehören _nicht_ hierher; X-basierende gehören zu [.filename]#x11# und text-basierende zu [.filename]#comms# oder [.filename]#misc#, abhängig von deren genauer Funktionalität.

|[.filename]#finance#
|Finanz-Software und ähnliches.
|

|[.filename]#french#
|Französische Sprachunterstützung. 
|

|[.filename]#ftp#
|FTP Client- und Server-Werkzeuge.
|Falls Ihr Port sowohl FTP als auch HTTP unterstützt, stellen Sie ihn in [.filename]#ftp# mit der Zweitkategorie [.filename]#www#.

|[.filename]#games#
|Spiele.
|

|[.filename]#geography*#
|geografische Software.
|

|[.filename]#german#
|Deutsche Sprachunterstützung.
|

|[.filename]#gnome*#
|Ports für http://www.gnome.org[GNOME]
|

|[.filename]#gnustep*#
|Software für GNUstep.
|

|[.filename]#graphics#
|grafische Werkzeuge.
|

|[.filename]#hamradio*#
|Software für Amateurfunk.
|

|[.filename]#haskell*#
|Software für die Haskell-Programmiersprache.
|

|[.filename]#hebrew#
|Hebräische Sprachunterstützung. 
|

|[.filename]#hungarian#
|Ungarische Sprachunterstützung.
|

|[.filename]#ipv6*#
|IPv6-bezogene Software.
|

|[.filename]#irc#
|Internet Relay Chat (IRC)-Werkzeuge.
|

|[.filename]#japanese#
|Japanische Sprachunterstützung.
|

|[.filename]#java#
|Software für die Java(TM)-Programmiersprache. 
|Die [.filename]#java#-Kategorie sollte nicht die Einzige für einen Port sein mit Ausnahme der direkt nur mit der Programmiersprache zusammenhängenden Applikationen. Porter sollten [.filename]#java# nicht als Hauptkategorie eines Ports wählen.

|[.filename]#kde*#
|Ports für das http://www.kde.org[K Desktop Environment (KDE)]-Projekt.
|

|[.filename]#kld*#
|Kernelmodule.
|

|[.filename]#korean#
|Koreanische Sprachunterstützung.
|

|[.filename]#lang#
|Programmiersprachen.
|

|[.filename]#linux*#
|Linux-Applikationen und -Werkzeuge.
|

|[.filename]#lisp*#
|Software für die Lisp-Programmiersprache. 
|

|[.filename]#mail#
|Mail-Software.
|

|[.filename]#math#
|Numerische Berechnungen und andere mathematische Werkzeuge.
|

|[.filename]#mbone*#
|MBone-Applikationen.
|

|[.filename]#misc#
|Verschiedene Werkzeuge.
|Hauptsächlich Werkzeuge, die nicht anderswo hingehören. Versuchen Sie, falls irgend möglich, eine bessere Kategorie für Ihren Port zu finden als `misc`, weil Ports hier leicht untergehen.

|[.filename]#multimedia#
|Multimedia-Software.
|

|[.filename]#net#
|Verschiedene Netzwerk-Software.
|

|[.filename]#net-im#
|Instant Messaging-Software.
|

|[.filename]#net-mgmt#
|Netzwerk-Management-Software.
|

|[.filename]#net-p2p#
|Peer to peer-Netzwerkprogramme.
|

|[.filename]#news#
|USENET News-Software.
|

|[.filename]#palm#
|Software für http://www.palm.com/[Palm(TM)]. 
|

|[.filename]#parallel*#
|Applikationen für paralleles Rechnen. 
|

|[.filename]#pear*#
|Ports für das Pear PHP-Framework.
|

|[.filename]#perl5*#
|Ports, welche Perl Version 5 benötigen.
|

|[.filename]#plan9*#
|Verschiedene Programme von http://www.cs.bell-labs.com/plan9dist/[Plan9]. 
|

|[.filename]#polish#
|Polnische Sprachunterstützung.
|

|[.filename]#ports-mgmt#
|Hilfsprogramme für das Installieren und Entwickeln von FreeBSD Ports und Paketen.
|

|[.filename]#portuguese#
|Portugiesische Sprachunterstützung. 
|

|[.filename]#print#
|Drucker-Software.
|Desktop Veröffentlichungs-Werkzeuge (DTP, Betrachter etc.) gehören auch hierher.

|[.filename]#python*#
|Software für http://www.python.org/[Python]. 
|

|[.filename]#ruby*#
|Software für http://www.ruby-lang.org/[Ruby]. 
|

|[.filename]#rubygems*#
|Ports für http://www.rubygems.org/[RubyGems]-Pakete. 
|

|[.filename]#russian#
|Russische Sprachunterstützung.
|

|[.filename]#scheme*#
|Software für die Scheme-Programmiersprache.
|

|[.filename]#science#
|Wissenschaftliche Programme, die in keine andere Kategorie passen wie z.B. [.filename]#astro#, [.filename]#biology# und [.filename]#math#.
|

|[.filename]#security#
|Security-Werkzeuge.
|

|[.filename]#shells#
|Shells.
|

|[.filename]#spanish*#
|Spanische Sprachunterstützung.
|

|[.filename]#sysutils#
|System-Werkzeuge.
|

|[.filename]#tcl*#
|Ports, welche Tcl benötigen.
|

|[.filename]#textproc#
|Textverarbeitungsprogramme.
|Dies beinhaltet nicht DTP-Werkzeuge, diese gehören in [.filename]#print#. 

|[.filename]#tk*#
|Ports, welche Tk benötigen.
|

|[.filename]#ukrainian#
|Ukrainische Sprachunterstützung.
|

|[.filename]#vietnamese#
|Vietnamesische Sprachunterstützung. 
|

|[.filename]#windowmaker*#
|Ports für den WindowMaker Window-Manager. 
|

|[.filename]#www#
|Software für das World Wide Web (WWW). 
|HTML-Werkzeuge gehören auch hierher. 

|[.filename]#x11#
|X-Window-System und dergleichen.
|Diese Kategorie ist nur für Software, welche direkt X unterstützt. Fügen Sie keine normalen X-Applikationen hinzu. Die meisten davon gehören in eine andere [.filename]#x11-*#-Kategorie (siehe unten). Falls Ihr Port eine X-Applikation _ist_, dann definieren Sie bitte `USE_XLIB` (impliziert durch `USE_IMAKE`) und fügen ihn der entsprechenden Kategorie hinzu.

|[.filename]#x11-clocks#
|X11-Uhren.
|

|[.filename]#x11-drivers#
|X11-Treiber.
|

|[.filename]#x11-fm#
|X11-Dateimanager.
|

|[.filename]#x11-fonts#
|X11-Schriftarten und Werkzeuge.
|

|[.filename]#x11-servers#
|X11-Server.
|

|[.filename]#x11-themes#
|X11-Themes.
|

|[.filename]#x11-toolkits#
|X11-Toolkits.
|

|[.filename]#x11-wm#
|X11-Window-Manager.
|

|[.filename]#xfce*#
|Ports in Zusammenhang mit http://www.xfce.org/[Xfce].
|

|[.filename]#zope*#
|http://www.zope.org/[Zope]-Unterstützung. 
|
|===

[[choosing-categories]]
=== Wählen der richtigen Kategorie

Da viele der Kategorien sich überlappen, müssen Sie oft festlegen, welches die primäre Kategorie Ihres Ports ist. Hierzu gibt es einige Regeln, welche diese Auswahl bestimmen. Hier ist die Liste der Regeln mit abnehmender Wichtigkeit:

* Die erste (primäre) Kategorie muss eine physische (keine virtuelle, siehe <<porting-categories,oben>>) sein. Dies ist notwendig damit Pakete erstellt werden können. Die nachfolgenden Kategorien können wahllos virtuelle oder physische Kategorien sein.
* Sprachspezifische Kategorien kommen immer zuerst. Wenn Ihr Port z.B. Japanische X11-Schriftarten installiert, dann muss Ihre `CATEGORIES`-Zeile [.filename]#japanese x11-fonts# enthalten.
* Spezifische Kategorien werden vor weniger spezifischen Kategorien aufgelistet. Ein HTML-Editor sollte z.B. als [.filename]#www editors# aufgeführt werden und nicht umgekehrt. Genauso sollten Sie keinen Port unter [.filename]#net# aufführen, wenn er zu [.filename]#irc#, [.filename]#mail#, [.filename]#news#, [.filename]#security# oder [.filename]#www# passt, da [.filename]#net# in diesen Kategorien bereits implizit eingeschlossen ist.
* [.filename]#x11# wird nur als sekundäre Kategorie benutzt, wenn die primäre Kategorie eine sprachspezifische ist. Keinesfalls sollten Sie [.filename]#x11# in die Kategorie-Zeile einer X-Applikation setzen.
* Emacs modes gehören in die gleiche Kategorie wie die vom jeweiligen mode unterstützte Applikation und nicht in [.filename]#editors#. Ein Emacs mode z.B. für das Editieren von Quelltext einer bestimmten Programmiersprache gehört zur Kategorie [.filename]#lang#.
* Für Ports, die vom Benutzer ladbare Kernelmodule installieren, sollte die virtuelle Kategorie [.filename]#kld# in die `CATEGORIES`-Zeile aufgenommen werden.
* [.filename]#misc# sollte nicht zusammen mit irgendeiner anderen nicht-virtuellen Kategorie auftreten. Falls Sie `misc` mit einer anderen Kategorie in `CATEGORIES` haben bedeutet dies, dass Sie gefahrlos `misc` streichen und die andere Kategorie alleine verwenden können!
* Falls Ihr Port wirklich in keine andere Kategorie passt, verwenden Sie bitte [.filename]#misc#.

Falls Sie sich über die Kategorie im Unklaren sind, hinterlassen Sie bitte einen Kommentar in Ihrem per man:send-pr[1] eingereichten Bericht, damit wir diese Frage vor dem Import diskutieren können. Falls Sie ein Committer sind, schicken Sie bitte eine Nachricht an {freebsd-ports}, damit die Frage im Vorhinein erörtert werden kann. Neue Ports werden zu häufig falsch kategorisiert und werden sofort wieder verschoben. Das bläht das Master Source Repository unnötig auf.

[[proposing-categories]]
=== Eine neue Kategorie vorschlagen

Da die Ports-Sammlung über viele Jahre gewachsen ist, wurden viele neue Kategorien hinzugefügt. Neue Kategorien können _virtuell_ (ohne eigenes Unterverzeichnis in der Ports-Sammlung) oder _physisch_ sein. Der nachfolgende Text führt einige Punkte auf, welche bei der Neueinführung einer physischen Kategorie beachtet werden müssen, damit Sie dies bei einem eventuellen Vorschlag Ihrerseits berücksichtigen können.

Unsere bestehende Maxime ist die Vermeidung der Neuanlage von physischen Kategorien, solange nicht eine große Zahl von Ports zugeordnet werden können oder falls ihr nicht Ports zugehören würden, welche eine logisch abgegrenzte Gruppe von limitiertem öffentlichem Interesse zugehören würden (zum Beispiel neue Sprachkategorien) oder vorzugsweise beides.

Die Erklärung dafür ist, dass eine Neuanlage einer physischen Kategorie einen extref:{committers-guide}[erheblichen Arbeitsaufwand, ports] sowohl für die Committer als auch diejenigen Nutzer bedeutet, welche die Änderungen der Ports-Sammlung nachvollziehen. Zusätzlich verursachen Vorschläge für neue Kategorien oftmals Kontroversen (natürlich deswegen, weil es keinen klaren Konsens darüber gibt, welche Kategorie als "zu groß" betrachtet werden muss noch ob sich bestimmte Kategorien zur einfachen Suche eignen (und wie viele Kategorien überhaupt ideal wären) und so weiter).

Hier ist das Prozedere:

[.procedure]
====
. Schlagen Sie die neue Kategorie auf {freebsd-ports} vor. Sie sollten eine detaillierte Begründung für die neue Kategorie beifügen einschließlich einer Erklärung, warum Sie meinen, die existierenden Kategorien seien nicht ausreichend. Zeigen Sie außerdem eine Liste der zu verschiebenden Ports (falls neue Ports in GNATS auf ihren commit warten, die in diese Kategorie passen würden. Listen Sie diese bitte auch mit auf). Sind Sie der Maintainer oder Einreicher dieser Ports, erwähnen Sie es bitte. Es verleiht Ihrem Vorschlag mehr Gewicht.
. Nehmen Sie an der Diskussion teil.
. Falls es Unterstützung für Ihren Vorschlag geben sollte, reichen Sie bitte einen PR ein, welcher die Begründung und die Liste der betroffenen Ports enthält, die verschoben werden müssen. Idealerweise sollte der PR Patches für Folgendes enthalten:

** [.filename]##Makefile##s für die neuen Ports nach dem Repocopy
** [.filename]#Makefile# für die neue Kategorie
** [.filename]#Makefile# für die alten Kategorien der betroffenen Ports
** [.filename]##Makefile##s für Ports, welche von den alten Ports abhängen
** Für zusätzliches Ansehen sorgen Sie, wenn Sie die anderen Dateien, die geändert werden müssen, beifügen wie in der Direktive des Committer's Guide beschrieben.

. Da es die Ports-Infrastruktur beeinflusst und nicht nur die Durchführung von Repocopies und möglicherweise sogar Regressionstests auf dem Build Cluster durchgeführt werden müssen, sollte der PR dem Ports Management Team {portmgr} zugeordnet werden.
. Sobald der PR bestätigt wurde muss ein Committer den Rest der Prozedur durchführen, welche im extref:{committers-guide}[Committers Guide, ports] beschrieben ist.
====

Das Vorschlagen einer neuen virtuellen Kategorie ist ähnlich, aber wesentlich weniger aufwendig, weil keine Ports verschoben werden müssen. In diesem Falle müssen nur die Patches an den PR beigefügt werden, welche die neue Kategorie zur Variable `CATEGORIES` der betroffenen Ports hinzufügen.

[[proposing-reorg]]
=== Vorschlagen einer Neuorganisation aller Kategorien

Von Zeit zu Zeit schlägt jemand eine komplette Neuorganisation aller Ports, entweder mit einer zweistufigen Struktur oder irgendeiner Art von Schlüsselwörtern, vor. Bis heute wurde keiner dieser Vorschläge umgesetzt, weil sie zwar einfach zu machen sind, aber der Aufwand zur Umsetzung und Reorganisation der kompletten Ports-Sammlung schlichtweg mörderisch wäre. Bitte lesen Sie die Geschichte dieser Vorschläge in den Archiven der Mailinglisten nach, bevor Sie diese Ideen nochmals unterbreiten. Zudem sollten Sie gewappnet sein, dass man Sie auffordert, einen arbeitsfähigen Prototyp vorzulegen.

[[makefile-distfiles]]
== Die Distributionsdateien

Der zweite Teil des [.filename]#Makefile# beschreibt die Dateien, welche heruntergeladen werden müssen, um den Port zu bauen und wo diese Dateien zu finden sind.

=== `DISTVERSION/DISTNAME`

`DISTNAME` ist der Name der Applikation wie er von den Autoren vergeben wurde. `DISTNAME` hat als Vorgabe `${PORTNAME}-${PORTVERSION}` also überschreiben Sie diese Vorgabe nur, wenn es notwendig ist. `DISTNAME` wird nur an zwei Stellen genutzt. Erstens: (`DISTFILES`) hat als Vorgabe `${DISTNAME}${EXTRACT_SUFX}`. Zweitens: Die Distributionsdatei soll in einem Unterverzeichnis namens `WRKSRC` extrahiert werden, dessen Vorgabe [.filename]#work/${DISTNAME}# ist.

Manche Drittanbieter-Namen, welche nicht in das Schema `${PORTNAME}-${PORTVERSION}` passen, können durch Setzen von `DISTVERSION` automatisch behandelt werden. `PORTVERSION` und `DISTNAME` werden automatisch abgeleitet, können aber natürlich manuell überschrieben werden. Die folgende Tabelle führt einige Beispiele auf:

[.informaltable]
[cols="1,1", frame="none", options="header"]
|===
| DISTVERSION
| PORTVERSION

|0.7.1d
|0.7.1.d

|10Alpha3
|10.a3

|3Beta7-pre2
|3.b7.p2

|8:f_17
|8f.17
|===

[NOTE]
====
`PKGNAMEPREFIX` und `PKGNAMESUFFIX` beeinflussen `DISTNAME` nicht. Beachten Sie bitte auch, dass Sie `DISTNAME` unverändert lassen sollten, falls `WRKSRC` denselben Wert hat wie [.filename]#work/${PORTNAME}-${PORTVERSION}# und gleichzeitig dass Archiv des originalen Quelltextes anders benannt ist als `${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX}`. Es ist einfacher `DISTFILES` zu definieren, als `DISTNAME` und `WRKSRC` (und möglicherweise `EXTRACT_SUFX`) zu setzen.
====

=== `MASTER_SITES`

Dokumentieren Sie das Verzeichnis der FTP/HTTP-URL, welche auf den originalen Tarball zeigt, in der Variable `MASTER_SITES`. Bitte vergessen Sie niemals den Schrägstrich ([.filename]#/#) am Ende!

Die `make`-Makros werden versuchen, diese Festlegung für die Aufbereitung der Distributionsdateien mittels `FETCH` zu benutzen, falls sie diese nicht schon auf dem System finden.

Es wird empfohlen, mehrere Webseiten in dieser Liste aufzuführen, vorzugsweise auf verschiedenen Kontinenten. Dies ist ein Schutz gegen Probleme bei größeren Ausfällen im Internet. Wir planen sogar Unterstützung einzubauen, die automatisch einen Server in der Nähe zum Herunterladen bestimmt. Die Verfügbarkeit von vielen Webseiten wird dieses Vorhaben beträchtlich erleichtern.

Falls der originale Tarball Teil eines populären Archivs ist, wie SourceForge, GNU oder Perl CPAN, können Sie möglicherweise auf diese Seiten in einer einfachen und kompakten Form mittels `MASTER_SITE_*` (d.h., `MASTER_SITE_SOURCEFORGE`,, `MASTER_SITE_GNU` und `MASTER_SITE_PERL_CPAN`) referenzieren. Setzen Sie einfach `MASTER_SITES` auf eine dieser Variablen und `MASTER_SITE_SUBDIR` auf den Pfad innerhalb des Archivs. Hier ist ein Beispiel:

[.programlisting]
....
MASTER_SITES=         ${MASTER_SITE_GNU}
MASTER_SITE_SUBDIR=   make
....

Oder verwenden Sie ein kondensiertes Format:

[.programlisting]
....
MASTER_SITES=   GNU/make
....

Diese Variablen werden in [.filename]#/usr/ports/Mk/bsd.sites.mk# definiert. Es werden ständig neue Einträge hinzugefügt, daher stellen Sie bitte unbedingt sicher, dass Sie die neueste Version verwenden, bevor Sie einen Port einschicken.

Für beliebte Seiten existieren sogenannte _magic_-Makros, die eine bestimmte Verzeichnisstruktur erstellen. Um eines dieser Makros zu verwenden, geben Sie dessen Abkürzung an und Ihr System wird versuchen, das korrekte Unterverzeichnis automatisch zu bestimmen.

[.programlisting]
....
MASTER_SITES=	SF
....

Ist das Ergebnis nicht korrekt, können Sie diesen Wert auch überschreiben.

[.programlisting]
....
MASTER_SITES=	SF/stardict/WyabdcRealPeopleTTS/${PORTVERSION}
....

.Beliebte magic `MASTER_SITES`-Makros
[cols="1,1", frame="none", options="header"]
|===
| Makro
| Erwartetes Unterverzeichnis

|`APACHE_JAKARTA`
|`/dist/jakarta/${PORTNAME:S,-,,/,}/source`

|`BERLIOS`
|`/${PORTNAME:L}`

|`CHEESESHOP`
|`/packages/source/source/${DISTNAME:C/(.).\*/\1/}/${DISTNAME:C/(.*)-[0-9].*/\1/}`

|`DEBIAN`
|`/debian/pool/main/${PORTNAME:C/^((lib)?.).*$/\1/}/${PORTNAME}`

|`GCC`
|`/pub/gcc/releases/${DISTNAME}`

|`GNOME`
|`/pub/GNOME/sources/${PORTNAME}/${PORTVERSION:C/^([0-9]+\.[0-9]+).*/\1/}`

|`GNU`
|`/gnu/${PORTNAME}`

|`MOZDEV`
|`/pub/mozdev/${PORTNAME:L}`

|`PERL_CPAN`
|`/pub/CPAN/modules/by-module/${PORTNAME:C/-.*//}`

|`PYTHON`
|`/ftp/python/${PYTHON_PORTVERSION:C/rc[0-9]//}`

|`RUBYFORGE`
|`/${PORTNAME:L}`

|`SAVANNAH`
|`/${PORTNAME:L}`

|`SF`
|`/project/${PORTNAME:L}/${PORTNAME:L}/${PORTVERSION}`
|===

=== `EXTRACT_SUFX`

Falls Sie eine Distributionsdatei haben, die ein eigentümliches Suffix nutzt, um die Art der Kompression anzuzeigen, dann setzen Sie `EXTRACT_SUFX`.

Ist die Distributionsdatei zum Beispiel im Stil von [.filename]#foo.tgz# anstatt des normalen [.filename]#foo.tar.gz# benannt, würden Sie schreiben:

[.programlisting]
....
DISTNAME=      foo
EXTRACT_SUFX=  .tgz
....

Falls erforderlich, setzen die Variablen `USE_BZIP2` und `USE_ZIP` automatisch `EXTRACT_SUFX` auf `.tar.bz2` oder `.zip`. Falls keine der beiden gesetzt ist, dann verwendet `EXTRACT_SUFX` die Vorgabe `.tar.gz`.

[NOTE]
====
Sie müssen niemals beide Variablen `EXTRACT_SUFX` und `DISTFILES` setzen.
====

=== `DISTFILES`

Manchmal haben die zu ladenden Dateien keinerlei Ähnlichkeit mit dem Namen des Ports. Es könnte z.B. [.filename]#source.tar.gz# oder ähnlich heißen. In anderen Fällen könnte der Quelltext in mehreren Archiven sein und alle müssen heruntergeladen werden.

Falls dies der Fall ist, setzen Sie `DISTFILES` als eine durch Leerzeichen getrennte Liste aller Dateien, die geladen werden müssen.

[.programlisting]
....
DISTFILES=     source1.tar.gz source2.tar.gz
....

Wenn nicht ausdrücklich gesetzt, verwendet `DISTFILES` als Vorgabe `${DISTNAME}${EXTRACT_SUFX}`.

=== `EXTRACT_ONLY`

Falls nur einige der `DISTFILES` extrahiert werden müssen (z.B. eine Datei ist der Quelltext und eine andere ist ein unkomprimiertes Dokument), dann listen Sie die zu extrahierenden Dateien in `EXTRACT_ONLY` auf.

[.programlisting]
....
DISTFILES=     source.tar.gz manual.html
EXTRACT_ONLY=  source.tar.gz
....

Falls _keine_ der `DISTFILES` unkomprimiert sein sollte, dann setzen Sie `EXTRACT_ONLY` auf einen leeren String.

[.programlisting]
....
EXTRACT_ONLY=
....

[[porting-patchfiles]]
=== `PATCHFILES`

Falls Ihr Port zusätzliche Patches benötigt, welche per FTP oder HTTP verfügbar sind, dann setzen Sie `PATCHFILES` auf den Namen der Dateien und `PATCH_SITES` auf die URL des Verzeichnisses, das diese Patches enthält (das Format ist das gleiche wie `MASTER_SITES`).

Falls ein Patch wegen einiger zusätzlicher Pfadnamen nicht relativ zum Anfang des Quelltextbaumes (d.h., `WRKSRC`) liegt, dann setzen Sie bitte `PATCH_DIST_STRIP` entsprechend. Wenn z.B. alle Pfadnamen in diesem Patch ein zusätzliches `foozolix-1.0/` vor ihren Dateinamen aufweisen, dann setzen Sie bitte `PATCH_DIST_STRIP=-p1`.

Kümmern Sie sich nicht darum, ob die Patches komprimiert sind. Sie werden automatisch dekomprimiert, wenn die Dateinamen auf [.filename]#.gz# oder [.filename]#.Z# enden.

Falls der Patch zusammen mit anderen Dateien in einem gezippten Tarball verteilt wird (z.B. mit Dokumentation), dann können Sie nicht `PATCHFILES` verwenden. In diesem Fall fügen Sie den Namen und den Ort dieses Tarballs zu `DISTFILES` und `MASTER_SITES`. Benutzen Sie dann die `EXTRA_PATCHES`-Variable, um auf diese Dateien zu zeigen und [.filename]#bsd.port.mk# wird automatisch diese Dateien nutzen. Kopieren Sie _niemals_ Patch-Dateien in das `PATCHDIR`-Verzeichnis, weil es möglicherweise nicht beschreibbar ist.

[NOTE]
====
Der Tarball wird zusammen mit dem anderen Quelltext extrahiert werden. Eine ausdrückliche Dekomprimierung eines mit gzip oder compress erzeugten Tarball ist nicht notwendig. Sollten Sie dies dennoch vorgeben, so beachten Sie bitte peinlich genau, dass Sie nichts überschreiben, was bereits im Verzeichnis vorhanden ist. Vergessen Sie auch nicht den kopierten Patch im Target von `pre-clean` zu entfernen.
====

[[porting-master-sites-n]]
=== Verschiedene Distributionsdateien oder Patches von verschiedenen Seiten und Verzeichnissen (`MASTER_SITES:n`)

(Betrachten Sie es als in irgendeiner Form "fortgeschrittenes Thema". Neulinge sollten möglicherweise diesen Abschnitt beim ersten Lesen überspringen).

Dieser Abschnitt stellt Informationen über die Mechanismen zum Herunterladen von Dateien zur Verfügung und behandelt die Variablen `MASTER_SITES:n` und `MASTER_SITES_NN`. Wir beziehen uns im weiteren Text auf diese Variablen als `MASTER_SITES:n`.

Etwas Hintergrundinformation zu Beginn: OpenBSD verfügt über eine sehr elegante Option innerhalb der Variablen `DISTFILES` und `PATCHFILES`. Sowohl Dateien als auch Patches können mit angehängten `:n`-Bezeichnern versehen werden wobei `n` in beiden Fällen `[0-9]` sein kann und eine Gruppenzugehörigkeit anzeigt. Ein Beispiel hierfür ist:

[.programlisting]
....
DISTFILES=      alpha:0 beta:1
....

In OpenBSD wird die Datei [.filename]#alpha# mit der Variable `MASTER_SITES0` verknüpft anstatt dem in FreeBSD gebräuchlichen `MASTER_SITES` und [.filename]#beta# mit `MASTER_SITES1`.

Das ist eine sehr interessante Möglichkeit, die endlose Suche nach der richtigen Download-Seite zu verkürzen.

Stellen Sie sich zwei Dateien in `DISTFILES` und 20 Webseiten in der Variable `MASTER_SITES` vor. Alle Seiten sind erschreckend langsam, [.filename]#beta# findet sich auf allen Seiten in `MASTER_SITES` und [.filename]#alpha# kann nur auf der zwanzigsten Seite gefunden werden. Wäre es nicht reine Verschwendung, wenn der Maintainer alle Seiten zuvor überprüfen müsste? Kein guter Start für das wundervolle Wochenende!

Übertragen Sie diesen Umstand auf noch mehr `DISTFILES` und mehr `MASTER_SITES`. Ganz sicher würde unser "distfiles survey master" die Erleichterung sehr zu schätzen wissen, die eine solche Verringerung der Netzwerkbelastung bringen würde.

In den nächsten Abschnitten sehen Sie die Implementierung dieser Idee durch FreeBSD. Dabei wurde das Konzept von OpenBSD ein wenig verbessert.

==== Prinzipielle Information

Dieser Abschnitt informiert Sie, wie Sie schnell ein fein granuliertes Herunterladen von vielen Dateien und Fehlerbereinigungen von verschiedenen Webseiten und Unterverzeichnissen bewerkstelligen. Wir beschreiben hier den Fall der vereinfachten Nutzung von `MASTER_SITES:n`. Das ist für die meisten Szenarien ausreichend. Falls Sie weitere Informationen benötigen, sollten Sie den nächsten Abschnitt lesen.

Einige Programme bestehen aus mehreren Dateien, welche von verschiedenen Webseiten heruntergeladen werden müssen. Zum Beispiel besteht Ghostscript aus dem Kern des Programms und einer großen Zahl von Treiberdateien, die vom Drucker des Benutzers abhängen. Einige dieser Treiberdateien werden mit der Kernapplikation mitgeliefert aber viele müssen von verschiedenen Webseiten heruntergeladen werden.

Um das zu unterstützen, muss jeder Eintrag in `DISTFILES` mit einem Komma und einem "tag name" abgeschlossen werden. Jeder in `MASTER_SITES` aufgeführte Webseite folgt ein Komma und eine Marke (tag), die anzeigt, welche Datei von dieser Webseite heruntergeladen werden kann.

Stellen Sie sich bitte eine Applikation vor, deren Quelltext in zwei Teile aufgeteilt ist, [.filename]#source1.tar.gz# und [.filename]#source2.tar.gz#, welche von zwei verschiedenen Webseiten heruntergeladen werden müssen. Das [.filename]#Makefile# des Port würde Zeilen enthalten wie in <<ports-master-sites-n-example-simple-use-one-file-per-site>>.

[[ports-master-sites-n-example-simple-use-one-file-per-site]]
.Vereinfachtes Beispiel für den Gebrauch von `MASTER_SITES:n` mit einer Datei pro Webseite
[example]
====
[.programlisting]
....
MASTER_SITES=   ftp://ftp.example1.com/:source1 \
	ftp://ftp.example2.com/:source2
DISTFILES=      source1.tar.gz:source1 \
	source2.tar.gz:source2
....

====

Verschiedene Dateien können die gleiche Marke aufweisen. Ausgehend vom vorherigen Beispiel nehmen wir an, dass es noch eine dritte Datei gibt ([.filename]#source3.tar.gz#), welche von `ftp.example2.com` heruntergeladen werden soll. Das [.filename]#Makefile# würde dann aussehen wie <<ports-master-sites-n-example-simple-use-more-than-one-file-per-site>>.

[[ports-master-sites-n-example-simple-use-more-than-one-file-per-site]]
.Vereinfachtes Beispiel für den Gebrauch von `MASTER_SITES:n` mit mehr als einer Datei pro Webseite
[example]
====
[.programlisting]
....
MASTER_SITES=   ftp://ftp.example1.com/:source1 \
	ftp://ftp.example2.com/:source2
DISTFILES=      source1.tar.gz:source1 \
	source2.tar.gz:source2 \
	source3.tar.gz:source2
....

====

==== Ausführliche Information

In Ordnung, das vorherige Beispiel reicht nicht für Ihre Bedürfnisse? In diesem Abschnitt werden wir im Detail erklären, wie der fein granulierte Mechanismus zum Herunterladen (`MASTER_SITES:n`) funktioniert und wie Sie Ihre Ports modifizieren, um ihn zu nutzen.

. Elemente können nachstehend bezeichnet werden mit `:n` wobei _n_ in diesem Falle `[^:,]+` ist. Das heißt _n_ könnte theoretisch jede alphanumerische Zeichenkette sein, aber wir beschränken sie auf `[a-zA-Z_][0-9a-zA-Z_]+` für diesen Moment.
+ 
Zudem ist die Zeichenkette case sensitive; d.h. `n` unterscheidet sich von `N`.
+ 
Allerdings dürfen die folgenden Wörter nicht gebraucht werden, da sie spezielle Bedeutungen haben: `default`, `all` und `ALL` (diese Wörter werden intern genutzt in Punkt <<porting-master-sites-n-what-changes-in-port-targets,ii>>). Ausserdem ist `DEFAULT` ein reserviertes Wort (beachten Sie <<porting-master-sites-n-DEFAULT-group,3>>).
. Elemente mit angehängtem `:n` gehören zur Gruppe `n`, `:m` gehört zur Gruppe `m` und so weiter.
[[porting-master-sites-n-DEFAULT-group]]
. Elemente ohne Anhängsel sind gruppenlos, d.h. sie gehören alle zu der speziellen Gruppe `DEFAULT`. Falls sie an irgendeinem Element `DEFAULT` hängen, ist dies überflüssig, es sei denn Sie wollen, dass ein Element sowohl zu `DEFAULT` als auch anderen Gruppen gleichzeitig gehört (beachten Sie <<porting-master-sites-n-comma-operator,5>>).
+ 
Die folgenden Beispiele sind gleichwertig, aber das erste Beispiel ist vorzuziehen:
+
[.programlisting]
....
MASTER_SITES=   alpha

MASTER_SITES=   alpha:DEFAULT
....

. Gruppen sind nicht ausschliessend, d.h. ein Element kann mehreren Gruppen gleichzeitig angehören und eine Gruppe wiederum kann entweder mehrere Elemente oder überhaupt keine aufweisen. Wiederholte Elemente sind schlicht nur wiederholte Elemente.
[[porting-master-sites-n-comma-operator]]
. Wenn Sie wollen, dass ein Element gleichzeitig zu mehreren Gruppen gehört, dann können Sie diese durch ein Komma (`,`) trennen.
+ 
Anstatt jedes Mal ein anderes Anhängsel zu verwenden und Wiederholungen aufzuführen, können Sie mehrere Gruppen auf einmal in einem einzigen Anhängsel bestimmen. Zum Beispiel markiert `:m,n,o` ein Element, welches zu den Gruppen `m`, `n` und `o` gehört.
+ 
Alle folgenden Beispiele sind gleichwertig, aber das erste Beispiel ist vorzuziehen:
+
[.programlisting]
....
MASTER_SITES=   alpha alpha:SOME_SITE

MASTER_SITES=   alpha:DEFAULT alpha:SOME_SITE

MASTER_SITES=   alpha:SOME_SITE,DEFAULT

MASTER_SITES=   alpha:DEFAULT,SOME_SITE
....

. Alle Webseiten in einer Gruppe werden gemäß `MASTER_SORT_AWK` sortiert. Alle Gruppen innerhalb von `MASTER_SITES` und `PATCH_SITES` werden genauso sortiert.
[[porting-master-sites-n-group-semantics]]
. Gruppensemantik kann benutzt werden in den folgenden Variablen: `MASTER_SITES`, `PATCH_SITES`, `MASTER_SITE_SUBDIR`, `PATCH_SITE_SUBDIR`, `DISTFILES` und `PATCHFILES` entsprechend der folgenden Syntax:
.. Elemente mit `MASTER_SITES`, `PATCH_SITES`, `MASTER_SITE_SUBDIR` und `PATCH_SITE_SUBDIR` müssen mit einem Schrägstrich beendet werden ( `/`). Falls Elemente zu irgendwelchen Gruppen gehören, muss `:n` direkt nach dem Trenner `/` stehen. Der `MASTER_SITES:n`-Mechanismus verlässt sich auf das Vorhandensein des Trennzeichens `/`, um verwirrende Elemente zu vermeiden in denen `:n` ein zulässiger Bestandteil des Elementes ist und das Auftreten von `:n` die Gruppe `n` anzeigt. Aus Kompatibilitätsgründen (da der `/`-Trenner sowohl in `MASTER_SITE_SUBDIR` als auch `PATCH_SITE_SUBDIR`-Elementen nicht erforderlich ist) wird, falls das auf das Anhängsel folgende nächste Zeichen kein `/` ist, auch `:n` als gültiger Teil des Elementes behandelt anstatt als Gruppenzusatz, selbst wenn ein Element ein angehängtes `:n` aufweist. Beachten Sie sowohl <<ports-master-sites-n-example-detailed-use-master-site-subdir>> als auch <<ports-master-sites-n-example-detailed-use-complete-example-master-sites>>.
+
[[ports-master-sites-n-example-detailed-use-master-site-subdir]]
.Ausführliches Beispiel von `MASTER_SITES:n` in `MASTER_SITE_SUBDIR`
[example]
====
[.programlisting]
....
MASTER_SITE_SUBDIR=     old:n new/:NEW
....

*** Verzeichnisse innerhalb der Gruppe `DEFAULT` -> old:n
*** Verzeichnisse innerhalb der Gruppe `NEW` -> new

====
+
[[ports-master-sites-n-example-detailed-use-complete-example-master-sites]]
.Ausführliches Beispiel von `MASTER_SITES:n` mit Komma-Operator, mehreren Dateien, mehreren Webseiten und mehreren Unterverzeichnissen
[example]
====
[.programlisting]
....
MASTER_SITES=   http://site1/%SUBDIR%/ http://site2/:DEFAULT \
	http://site3/:group3 http://site4/:group4 \
	http://site5/:group5 http://site6/:group6 \
	http://site7/:DEFAULT,group6 \
	http://site8/%SUBDIR%/:group6,group7 \
	http://site9/:group8
DISTFILES=      file1 file2:DEFAULT file3:group3 \
	file4:group4,group5,group6 file5:grouping \
	file6:group7
MASTER_SITE_SUBDIR=     directory-trial:1 directory-n/:groupn \
	    directory-one/:group6,DEFAULT \
	    directory
....

Das vorstehende Beispiel führt zu einem fein granulierten Herunterladen. Die Webseiten werden in der exakten Reihenfolge ihrer Nutzung aufgelistet.

*** [.filename]#file1# wird heruntergeladen von

**** `MASTER_SITE_OVERRIDE`
**** http://site1/directory-trial:1/
**** http://site1/directory-one/
**** http://site1/directory/
**** http://site2/
**** http://site7/
**** `MASTER_SITE_BACKUP`

*** [.filename]#file2# wird genauso heruntergeladen wie [.filename]#file1#, da sie zur gleichen Gruppe gehören

**** `MASTER_SITE_OVERRIDE`
**** http://site1/directory-trial:1/
**** http://site1/directory-one/
**** http://site1/directory/
**** http://site2/
**** http://site7/
**** `MASTER_SITE_BACKUP`

*** [.filename]#file3# wird heruntergeladen von

**** `MASTER_SITE_OVERRIDE`
**** http://site3/
**** `MASTER_SITE_BACKUP`

*** [.filename]#file4# wird heruntergeladen von

**** `MASTER_SITE_OVERRIDE`
**** http://site4/
**** http://site5/
**** http://site6/
**** http://site7/
**** http://site8/directory-one/
**** `MASTER_SITE_BACKUP`

*** [.filename]#file5# wird heruntergeladen von

**** `MASTER_SITE_OVERRIDE`
**** `MASTER_SITE_BACKUP`

*** [.filename]#file6# wird heruntergeladen von

**** `MASTER_SITE_OVERRIDE`
**** http://site8/
**** `MASTER_SITE_BACKUP`

====

. Wie gruppiere ich eine der speziellen Variablen aus [.filename]#bsd.sites.mk#, d.h. `MASTER_SITE_SOURCEFORGE`?
+ 
Lesen Sie <<ports-master-sites-n-example-detailed-use-master-site-sourceforge>>.
+
[[ports-master-sites-n-example-detailed-use-master-site-sourceforge]]
.Ausführliches Beispiel von `MASTER_SITES:n` mit `MASTER_SITE_SOURCEFORGE`
[example]
====
[.programlisting]
....
MASTER_SITES=   http://site1/ ${MASTER_SITE_SOURCEFORGE:S/$/:sourceforge,TEST/}
DISTFILES=      something.tar.gz:sourceforge
....

====
+ 
[.filename]#something.tar.gz# wird von allen Webseiten innerhalb von `MASTER_SITE_SOURCEFORGE` heruntergeladen.
. Wie nutze ich dies mit `PATCH*`-Variablen.
+ 
In allen Beispielen wurden `MASTER*`-Variablen genutzt, aber sie funktionieren exakt genauso mit `PATCH*`-Variablen, wie Sie an <<ports-master-sites-n-example-detailed-use-patch-sites>>. sehen können.
+
[[ports-master-sites-n-example-detailed-use-patch-sites]]
.Vereinfachte Nutzung von `MASTER_SITES:n` mit `PATCH_SITES`.
[example]
====
[.programlisting]
....
PATCH_SITES=    http://site1/ http://site2/:test
PATCHFILES=     patch1:test
....

====

==== Was ändert sich für die Ports? Was ändert sich nicht?

[lowerroman]
. Alle bestehenden Ports bleiben gleich. Der Code für `MASTER_SITES:n` wird nur aktiviert, falls es Elemente mit angehängtem `:n` entsprechend den zuvor erwähnten Syntax-Regeln wie in <<porting-master-sites-n-group-semantics,7>> gezeigt gibt.
[[porting-master-sites-n-what-changes-in-port-targets]]
. Das Target des Port bleibt gleich: `checksum`, `makesum`, `patch`, `configure`, `build` etc. Mit der offensichtlichen Ausnahme von `do-fetch`, `fetch-list`, `master-sites` und `patch-sites`.

** `do-fetch`: nutzt die neue Gruppierung `DISTFILES` und `PATCHFILES` mit ihren darauf zutreffenden Gruppenelementen in `MASTER_SITES` und `PATCH_SITES` welche zutreffende Gruppenelemente sowohl in `MASTER_SITE_SUBDIR` als auch `PATCH_SITE_SUBDIR` aufweisen. Sehen Sie hierzu <<ports-master-sites-n-example-detailed-use-complete-example-master-sites>>.
** `fetch-list`: arbeitet wie das alte `fetch-list` mit der Ausnahme, dass es nur wie `do-fetch` gruppiert.
** `master-sites` und `patch-sites`: (inkompatibel zu älteren Versionen) geben nur die Elemente der Gruppe `DEFAULT` zurück. Beziehungsweise sie führen genau genommen die Targets von `master-sites-default` und `patch-sites-default` aus.
+ 
Weiterhin ist der Gebrauch des Target entweder von `master-sites-all` oder `patch-sites-all` der direkten Überprüfung von `MASTER_SITES` oder `PATCH_SITES` vorzuziehen. Zudem ist nicht garantiert, dass das direkte Überprüfen in zukünftigen Versionen funktionieren wird. Sehen Sie <<porting-master-sites-n-new-port-targets-master-sites-all,B>> für weitere Informationen zu diesen neuen Port-Targets.

. Neue Port-Targets
.. Es gibt `master-sites-_n_` und `patch-sites-_n_`-Targets, welche die Elemente der jeweiligen Gruppe _n_ innerhalb von `MASTER_SITES` und `PATCH_SITES` auflisten. Beispielweise werden sowohl `master-sites-DEFAULT` als auch `patch-sites-DEFAULT` die Elemente der Gruppe `DEFAULT`, `master-sites-test` und `patch-sites-test` der Gruppe `test` usw. zurückgeben.
[[porting-master-sites-n-new-port-targets-master-sites-all]]
.. Es gibt das neue Target `master-sites-all` und `patch-sites-all`, welche die Arbeit der alten Targets `master-sites` und `patch-sites` übernehmen. Sie geben die Elemente aller Gruppen zurück,als würden sie zur gleichen Gruppe gehören - mit dem Vorbehalt, dass sie so viele `MASTER_SITE_BACKUP` und `MASTER_SITE_OVERRIDE` auflisten wie Gruppen mittels `DISTFILES` oder `PATCHFILES` definiert sind. Das gleiche gilt entsprechend für `master-sites-all` und `patch-sites-all`.

=== `DIST_SUBDIR`

Verhindern Sie, dass Ihr Port das Verzeichnis [.filename]#/usr/ports/distfiles# in Unordnung bringt. Falls Ihr Port eine ganze Reihe von Dateien herunterladen muss oder eine Datei enthält, die einen Namen hat, der möglicherweise mit anderen Ports in Konflikt stehen könnte (d.h.[.filename]#Makefile#), dann setzen Sie die Variable `DIST_SUBDIR` auf den Namen des Ports (`${PORTNAME}` oder `${PKGNAMEPREFIX}${PORTNAME}` sollte hervorragend funktionieren). Dies wird `DISTDIR` von der Vorgabe [.filename]#/usr/ports/distfiles# auf [.filename]#/usr/ports/distfiles/DIST_SUBDIR# ändern und stellt tatsächlich alle für Ihren Port benötigten Dateien in dieses Unterverzeichnis.

Es wird zusätzlich nach dem Unterverzeichnis mit dem gleichen Namen auf der Sicherung der Hauptseite auf [.filename]#ftp.FreeBSD.org# suchen (das ausdrückliche Setzen von `DISTDIR` in Ihrem `Makefile` wird dies nicht gewährleisten, also nutzen Sie bitte `DIST_SUBDIR`).

[NOTE]
====
Dies hat keine Auswirkungen auf die Variable `MASTER_SITES`, die Sie in Ihrem [.filename]#Makefile# definieren.
====

=== `ALWAYS_KEEP_DISTFILES`

Falls Ihr Port binäre Distfiles benutzt und eine Lizenz aufweist, die verlangt, dass das der Quelltext in Form binärer Pakete verteilt werden muss, z.B. GPL, dann wird `ALWAYS_KEEP_DISTFILES` den FreeBSD Build Cluster anweisen eine Kopie der Dateien in `DISTFILES` vorzuhalten. Nutzer dieser Ports benötigen generell diese Dateien nicht, daher ist es ein gutes Konzept, nur dann die Distfiles zu `DISTFILES` hinzuzufügen, wenn `PACKAGE_BUILDING` definiert ist.

[[ports-master-sites-n-example-always-keep-distfiles]]
.Nutzung von `ALWAYS_KEEP_DISTFILES`.
[example]
====
[.programlisting]
....
.if defined(PACKAGE_BUILDING)
DISTFILES+=             foo.tar.gz
ALWAYS_KEEP_DISTFILES=  yes
.endif
....

====

Wenn Sie zusätzliche Dateien zu `DISTFILES` hinzufügen, dann beachten Sie bitte, dass Sie diese auch in [.filename]#distinfo# aufführen. Zudem werden die zusätzlichen Dateien normalerweise ebenso in `WRKDIR` extrahiert, was für einige Ports zu unbeabsichtigten Seiteneffekten führen mag und spezielle Behandlung erfordert.

[[makefile-maintainer]]
== `MAINTAINER`

Fügen Sie hier Ihre E-Mailadresse ein. Bitte. _:-)_

Beachten Sie bitte, dass nur eine einzelne E-Mailadresse ohne Kommentar in der Variable `MAINTAINER` zulässig ist. Das Format sollte `user@hostname.domain` sein. Bitte fügen Sie keinen beschreibenden Text wie z.B. Ihren wirklichen Namen ein, dies verwirrt lediglich [.filename]#bsd.port.mk#.

Der Maintainer ist dafür verantwortlich, dass der Port aktuell gehalten wird und er sorgt dafür, dass der Port korrekt arbeitet. Für eine detaillierte Beschreibung der Verantwortlichkeiten eines Maintainers beachten Sie bitte den Abschnitt link:{contributing-ports}#maintain-port/[ Die Herausforderung für einen Port-Maintainer].

Änderungen am Port werden dem Maintainer zur Begutachtung und Zustimmung vorgelegt, bevor sie committed werden. Falls der Maintainer einem Aktualisierungs-Wunsch nicht binnen 2 Wochen (ausgenommen wichtige öffentliche Feiertage) zustimmt, dann wird dies als Maintainer-Timeout betrachtet und eine Aktualisierung kann ohne ausdrückliche Zustimmung des Maintainers erfolgen. Falls der Maintainer nicht binnen 3 Monaten zustimmt, wird er als abwesend ohne Grund betrachtet und kann als Maintainer des fraglichen Ports durch eine andere Person ersetzt werden. Ausgenommen davon ist alles, was durch das {portmgr} oder das {security-officer} betreut wird. Es dürfen niemals committs ohne vorherige Zustimmung an solchen Ports vorgenommen werden!

Wir behalten uns das Recht vor, die Einreichungen eines Maintainers ohne ausdrückliche Zustimmung zu ändern, falls wir der Auffassung sind, dass dadurch die Einhaltung von Richtlinien und stilistischen Vorgaben für die Ports-Sammlung besser erfüllt wird. Zudem können größere Änderungen an der Infrastruktur der Ports zu Änderungen an einem bestimmten Port ohne Zustimmung des Maintainers führen. Diese Änderungen beeinflussen niemals die Funktionalität eines Ports.

Das {portmgr} behält sich das Recht vor, die Maintainerschaft jedem aus irgendeinem Grund zu entziehen oder ausser Kraft zu setzen, und das Security Officer Team {security-officer} behält sich das Recht vor, jede Maintainerschaft aus Sicherheitsgründen aufzuheben oder ausser Kraft zu setzen.

[[makefile-comment]]
== `COMMENT`

Dies ist eine einzeilige Beschreibung des Ports. _Bitte_ fügen Sie nicht den Paketnamen (oder die Version der Software) in den Kommentar ein. Der Kommentar soll mit einem Großbuchstaben beginnen und ohne Punkt enden. Hier ist ein Beispiel:

[.programlisting]
....
COMMENT=       A cat chasing a mouse all over the screen
....

Die COMMENT-Variable soll unmittelbar nach der MAINTAINER-Variable im [.filename]#Makefile# stehen.

Bitte versuchen Sie die COMMENT-Zeile auf weniger als 70 Zeichen zu begrenzen, da man:pkg_info[1] diese zur Anzeige einer kurzen, einzeiligen Zusammenfassung des Ports verwendet.

[[makefile-depend]]
== Abhängigkeiten (dependencies)

Viele Ports hängen von anderen Ports ab. Dies ist ein sehr praktisches und nettes Feature der meisten Unix-ähnlichen Betriebssysteme, FreeBSD nicht ausgeschlossen. Es erlaubt, dass häufig vorkommende Abhängigkeiten nicht mit jedem Port oder Paket zusammen ausgeliefert werden müssen, da viele Ports diese gemeinsam benutzen. Es gibt sieben Variablen, die benutzt werden können, um sicherzustellen, dass alle benötigten Teile auf dem Rechner des Nutzers sind. Zusätzlich gibt es einige vordefinierte Variablen für Abhängigkeiten in häufigen Fällen und einige, welche das Verhalten der Abhängigkeiten bestimmen.

=== `LIB_DEPENDS`

Diese Variable spezifiziert die Shared-Libraries, von denen der Port abhängt. Es ist eine Liste von lib:dir:target-Tupeln wobei _lib_ den Name der gemeinsam genutzten Bibliothek, _dir_ das Verzeichnis, in welchem sie zu finden ist, falls nicht verfügbar, und _target_ das Target in diesem Verzeichnis angeben. Zum Beispiel wird 

[.programlisting]
....
LIB_DEPENDS=   jpeg.9:${PORTSDIR}/graphics/jpeg
....

auf eine jpeg-Bibliothek mit der Hauptversionsnummer 9 prüfen, in das [.filename]#graphics/jpeg#-Unterverzeichnis Ihrer Ports-Sammlung wechseln, es bauen und installieren, falls es nicht gefunden wird. Der _target_-Teil kann weggelassen werden, falls er identisch mit `DEPENDS_TARGET` ist (Vorgabe hierfür ist `install`).

[NOTE]
====
Der _lib_-Teil ist ein regulärer Ausdruck, welcher die Ausgabe von `ldconfig -r` ausgewertet. Werte wie `intl.[5-7]` und `intl` sind zulässig. Das erste Muster, `intl.[5-7]`, stimmt überein mit: `intl.5`, `intl.6` oder `intl.7`. Das zweite Muster, `intl`, stimmt überein mit jeder Version der `intl`-Bibliothek.
====

Die Abhängigkeit wird zwei Mal überprüft, einmal innerhalb des `extract`-Target und dann innerhalb des `install`-Target. Zudem wird der Name der Abhängigkeit in das Paket eingefügt, damit man:pkg_add[1] es automatisch installiert, falls es nicht auf dem Rechner des Nutzers ist.

=== `RUN_DEPENDS`

Diese Variable legt Binärdateien oder Dateien, von denen der Port abhängt, für die Laufzeit fest. Es ist eine Liste von path:dir:target-Tupeln, wobei _path_ der Name der Binärdatei oder Datei, _dir_ das Verzeichnis, in welchem sie gefunden werden kann, falls nicht vorhanden, und _target_ das Target in diesem Verzeichnis angeben. Falls _path_ mit einem Slash (`/`) beginnt, wird es als Datei behandelt und deren Vorhandensein wird mit `test -e`; überprüft. Andernfalls wird angenommen, dass es eine Binärdatei ist und `which -s` wird benutzt, um zu überprüfen, ob das Programm im Pfad vorhanden ist.

Zum Beispiel wird

[.programlisting]
....
RUN_DEPENDS=   ${LOCALBASE}/etc/innd:${PORTSDIR}/news/inn \
	   xmlcatmgr:${PORTSDIR}/textproc/xmlcatmgr
....

überprüfen, ob die Datei oder das Verzeichnis [.filename]#/usr/local/etc/innd# existiert und es erstellen und installieren aus dem [.filename]#news/inn#-Unterverzeichnis der Ports-Sammlung, falls es nicht gefunden wird. Es wird zudem überprüft, ob die Binärdatei namens `xmlcatmgr` im Suchpfad vorhanden ist und danach zum Unterverzeichnis [.filename]#textproc/xmlcatmgr# in Ihrer Ports-Sammlung wechseln, es bauen und installieren, falls es nicht gefunden wird.

[NOTE]
====
In diesem Fall ist `innd` eine Binärdatei. Falls sich eine Binärdatei an einem ungewöhnlichen Platz befindet, der nicht im Suchpfad ist, dann sollten Sie die volle Pfadangabe verwenden.
====

[NOTE]
====
Der offizielle Suchpfad `PATH`, welcher im Ports Cluster benutzt wird, ist

[.programlisting]
....
/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin
....

====

Die Abhängigkeit wird innerhalb des `install`-Target überprüft. Zudem wird der Name der Abhängigkeit in das Paket übernommen, damit man:pkg_add[1] es automatisch installieren wird, falls es auf dem System des Nutzers nicht vorhanden ist. Der _target_-Teil kann weggelassen werden, wenn er der gleiche ist wie in der Variable `DEPENDS_TARGET`.

Es kommt recht häufig vor, dass `RUN_DEPENDS` genau dasselbe enthält wie `BUILD_DEPENDS`, gerade dann, wenn die portierte Software in einer Skriptsprache geschrieben ist oder dieselbe Umgebung, die zum Bau verwendet wurde, zur Laufzeit gebraucht wird. In diesem Fall ist es sowohl verlockend als auch intuitiv, den Wert der einen Variable der anderen direkt zuzuweisen:

[.programlisting]
....
RUN_DEPENDS= ${BUILD_DEPENDS}
....

Jedoch kann eine solche Zuweisung dazu führen, dass die Liste der Laufzeitabhängigkeiten mit überflüssigen Einträgen belastet wird, die sich nicht in der ursprünglichen Liste `BUILD_DEPENDS` des Ports befanden, da sich man:make[1] bei der Auswertung solcher Zuweisungen träge verhält. Stellen Sie sich ein [.filename]#Makefile# mit `USE_*`-Variablen vor, die von [.filename]#ports/Mk/bsd.*.mk# verarbeitet werden, um initiale Bauabhängigkeiten zusammenzutragen. Zum Beispiel fügt `USE_GMAKE=yes` package:devel/gmake[] zu `BUILD_DEPENDS` hinzu. Um zu verhindern, dass solche zusätzlichen Abhängigkeiten `RUN_DEPENDS` belasten, achten Sie darauf, bei gleichzeitiger Auswertung zuzuweisen, d.h. der Ausdruck wird ausgewertet, bevor er als Wert der Variablen zugewiesen wird:

[.programlisting]
....
RUN_DEPENDS:=  ${BUILD_DEPENDS}
....

=== `BUILD_DEPENDS`

Diese Variable legt Binärdateien oder Dateien fest, die dieser Port zur Erstellung benötigt. Wie `RUN_DEPENDS` ist es eine Liste von path:dir:target-Tupeln. Zum Beispiel wird 

[.programlisting]
....
 BUILD_DEPENDS=
	  unzip:${PORTSDIR}/archivers/unzip
....

überprüfen, ob eine Binärdatei `unzip` vorhanden ist und in das Unterverzeichnis [.filename]#archivers/unzip# Ihrer Ports-Sammlung wechseln und sie erstellen und installieren, falls sie nicht gefunden wird.

[NOTE]
====
"Erstellen" bedeutet hier alles von der Extraktion bis zur Kompilierung. Die Abhängigkeit wird im `extract`-Target überprüft. Der _target_-Teil kann weggelassen werden, falls er identisch mit der Variable `DEPENDS_TARGET` ist.
====

=== `FETCH_DEPENDS`

Diese Variable legt eine Binärdatei oder Datei fest, welche der Port benötigt, um heruntergeladen werden zu können. Wie die vorherigen beiden Variablen ist er eine Liste von path:dir:target-Tupeln. Zum Beispiel wird 

[.programlisting]
....
 FETCH_DEPENDS=
	  ncftp2:${PORTSDIR}/net/ncftp2
....

überprüfen, ob eine Binärdatei namens `ncftp2` vorhanden ist, in das Unterverzeichnis [.filename]#net/ncftp2# Ihrer Ports-Sammlung wechseln, sie erstellen und installieren, falls sie nicht gefunden wird.

Die Abhängigkeit wird innerhalb des `fetch`-Target überprüft. Der _target_-Teil kann weggelassen werden, falls er identisch mit der Variable `DEPENDS_TARGET` ist.

=== `EXTRACT_DEPENDS`

Diese Variable spezifiziert eine Binärdatei oder eine Datei, welche dieser Port für die Extraktion benötigt. Wie die vorherigen Variablen ist er eine Liste von path:dir:target-Tupeln. Zum Beispiel wird 
[.programlisting]
....
EXTRACT_DEPENDS=
	  unzip:${PORTSDIR}/archivers/unzip
....

überprüfen, ob eine Binärdatei namens `unzip` vorhanden ist, in das Unterverzeichnis [.filename]#archivers/unzip# Ihrer Ports-Sammlung wechseln, sie erstellen und installieren, falls sie nicht gefunden wird.

Die Abhängigkeit wird innerhalb des `extract`-Target überprüft. Der _target_-Teil kann weggelassen werden, falls er identisch mit der Variable `DEPENDS_TARGET` ist.

[NOTE]
====
Nutzen Sie diese Variable nur, wenn die Extraktion nicht funktioniert (die Vorgabe nimmt `gzip` an) und nicht mit `USE_ZIP` oder `USE_BZIP2` wie in <<use-vars>> beschrieben zum Laufen gebracht werden kann.
====

=== `PATCH_DEPENDS`

Diese Variable legt eine Binärdatei oder eine Datei fest, welche dieser Port zum Patchen benötigt. Wie die vorhergehenden Variablen ist diese eine Liste von path:dir:target-Tupeln. Zum Beispiel wird 
[.programlisting]
....
 PATCH_DEPENDS=
	  ${NONEXISTENT}:${PORTSDIR}/java/jfc:extract
....

in das Unterverzeichnis [.filename]#java/jfc# Ihrer Ports-Sammlung wechseln, um es zu entpacken.

Die Abhängigkeit wird innerhalb des `patch`-Target überprüft. Der _target_-Teil kann entfallen, falls er identisch mit der Variable `DEPENDS_TARGET` ist.

[[use-vars]]
=== `USE_*`

Es gibt eine Reihe von Variablen, um gebräuchliche Abhängigkeiten einzukapseln, die viele Ports aufweisen. Obwohl Ihre Verwendung optional ist, können sie helfen die Übersichtlichkeit des [.filename]#Makefile# eines Ports zu erhöhen. Jede von ihnen ist im Stil von `USE_*`. Der Gebrauch dieser Variablen ist beschränkt auf das [.filename]#Makefile# eines Ports und [.filename]##ports/Mk/bsd.\*.mk##. Es ist nicht entworfen worden, um durch den Nutzer setzbare Optionen einzukapseln; benutzen Sie `WITH_*` und `WITHOUT_*` für diese Zwecke.

[NOTE]
====
Es ist _immer_ falsch, irgendeine `USE_*`-Variable in der [.filename]#/etc/make.conf# zu setzen. Zum Beispiel würde das Setzen von 
[.programlisting]
....
USE_GCC=3.4
....

eine Abhängigkeit für GCC34 für jeden Port einschliesslich GCC34 selbst hinzufügen!
====

.Die `USE_*`-Varibalen 
[cols="1,1", frame="none", options="header"]
|===
| Variable
| Bedeutung

|`USE_BZIP2`
|Der Tarball dieses Ports wird mit `bzip2` komprimiert.

|`USE_ZIP`
|Der Tarball des Ports wird mit `zip` komprimiert.

|`USE_BISON`
|Der Port benutzt `bison` für die Erstellung.

|`USE_CDRTOOLS`
|Der Port erfordert cdrecord entweder von package:sysutils/cdrtools[] oder package:sysutils/cdrtools-cjk[], abhängig davon, was der Nutzer vorgibt. 

|`USE_GCC`
|Dieser Port benötigt eine bestimmte Version von `gcc` zur Erstellung. Die genaue Version kann festgelegt werden mit Werten wie `3.4`. Mit `3.4+` kann die mindestens erforderliche Version spezifiziert werden. Der `gcc` aus dem Basissystem wird genutzt, wenn er die erforderliche Version erfüllt, andernfalls wird eine geeignete Version des `gcc` aus den Ports kompiliert und die Variablen `CC` und `CXX` werden angepasst.
|===

Variablen zugehörig zu gmake und dem [.filename]#configure#-Skript werden in crossref:special[building, Build-Mechanismen] beschrieben, währenddessen autoconf, automake und libtool in crossref:special[using-autotools, Benutzung von GNU autotools] beschrieben sind. Perl-spezifische Variablen werden in crossref:special[using-perl, Die Benutzung von `perl`] behandelt. X11-Variablen sind aufgelistet in crossref:special[using-x11, Benutzung von X11]. crossref:special[using-gnome, Benutzung von GNOME] behandelt GNOME-bezogene Variablen und crossref:special[using-kde, Benutzung von KDE] KDE-bezogene Variablen. crossref:special[using-java, Benutzung von Java] dokumentiert Java-Variablen, während crossref:special[using-php, Webanwendungen, Apache und PHP]Informationen zu Apache, PHP und PEAR-Modulen enthält. Python wird in crossref:special[using-python, Python benutzen] und Ruby in crossref:special[using-ruby, Ruby benutzen] erörtert. crossref:special[using-sdl, SDL verwenden] stellt Variablen für SDL-Programme zur Verfügung und crossref:special[using-xfce, Xfce verwenden] enthält schliesslich Variablen für Xfce.

=== Minimale Version einer Abhängigkeit

Eine minimale Version einer Abhängigkeit kann in jeder `*_DEPENDS`-Variable festgelegt werden mit Ausnahme von `LIB_DEPENDS` durch Anwendung folgender Syntax:

[.programlisting]
....
p5-Spiffy>=0.26:${PORTSDIR}/devel/p5-Spiffy
....

Das erste Feld enthält einen abhängigen Paketnamen, welcher einem Eintrag in der Paketdatenbank entsprechen muss und einen Vergleich mit einer Paketversion. Die Abhängigkeit wird erfüllt, wenn p5-Spiffy-0.26 oder eine neuere Version auf dem System installiert ist.

=== Anmerkungen zu Abhängigkeiten

Wie vorstehend beschrieben ist das Vorgabe-Target `DEPENDS_TARGET`, wenn eine Abhängigkeit benötigt wird. Die Vorgabe hierfür ist `install`. Dies ist eine Nutzer-Variable; sie wird niemals im [.filename]#Makefile# eines Ports definiert. Falls Ihr Port einen besonderen Weg benötigt, um mit einer Abhängigkeit umzugehen, dann benutzen Sie bitte den `:target`-Teil der `*_DEPENDS`-Variablen, anstatt `DEPENDS_TARGET` zu ändern.

Falls Sie `make clean` schreiben, werden dessen Abhängigkeiten auch gesäubert. Falls Sie dies nicht wollen, definieren Sie die Variable `NOCLEANDEPENDS` in Ihrer Umgebung. Dies kann besonders erstrebenswert sein, wenn der Port etwas in seiner Liste von Abhängigkeiten hat, das sehr viel Zeit für einen rebuild benötigt wie KDE, GNOME oder Mozilla.

Um von einem anderen Port bedingungslos abhängig zu sein, benutzen Sie bitte die Variable `${NONEXISTENT}` als erstes Feld von `BUILD_DEPENDS` oder `RUN_DEPENDS`. Benutzen Sie dies nur, wenn Sie den Quelltext eines anderen Port benötigen. Sie können auch oft Kompilierzeit sparen, wenn Sie das Target festlegen. Zum Beispiel wird 

[.programlisting]
....
BUILD_DEPENDS=   ${NONEXISTENT}:${PORTSDIR}/graphics/jpeg:extract
....

immer zum ``jpeg``-Port wechseln und ihn extrahieren.

=== Zirkuläre Abhängigkeiten sind fatal

[IMPORTANT]
====
Führen Sie niemals irgendwelche zirkulären Abhängigkeiten in der Ports-Sammlung ein!
====

Die Struktur für die Erstellung von Ports dulde keinerlei zirkuläre Abhängigkeiten. Falls Sie dennoch eine verwenden, wird es irgendjemanden irgendwo auf der Welt geben, dessen FreeBSD-Installation nahezu sofort zusammenbricht und vielen anderen wird es sehr schnell genauso ergehen. So etwas kann extrem schwer festzustellen sein. Falls Sie Zweifel haben vor einer Änderung, dann vergewissern Sie sich, dass Sie folgendes getan haben: `cd /usr/ports; make index`. Dieser Prozess kann auf alten Maschinen sehr langsam sein, aber Sie ersparen sich und einer Vielzahl von Menschen möglicherweise eine Menge Ärger.

[[makefile-masterdir]]
== `MASTERDIR`

Falls Ihr Port wegen einer Variable, die verschiedene Werte annimmt (z.B. Auflösung oder Papiergröße), leicht unterschiedliche Versione von Paketen erzeugen muss, dann legen Sie bitte ein Unterverzeichnis pro Paket an, um es für den Nutzer einfacher begreiflich zu machen, was zu machen ist. Aber versuchen Sie dabei so viele Dateien wie möglich zwischen diesen Ports gemeinsam zu nutzen. Normalerweise benötigen Sie nur ein sehr kurzes [.filename]#Makefile# in allen ausser einem Unterverzeichnis, wenn Sie Variablen intelligent nutzen. In diesem einzigen [.filename]#Makefile# können Sie `MASTERDIR` verwenden, um anzugeben, wo der Rest der Dateien liegt. Benutzen Sie bitte auch eine Variable für <<porting-pkgname,`PKGNAMESUFFIX`>>, damit die Pakete unterschiedliche Namen haben werden.

Wir demonstrieren dies am Besten an einem Beispiel. Es ist Teil von [.filename]#japanese/xdvi300/Makefile#;

[.programlisting]
....
PORTNAME=       xdvi
PORTVERSION=    17
PKGNAMEPREFIX=  ja-
PKGNAMESUFFIX=  ${RESOLUTION}
 :
# default
RESOLUTION?=   300
.if ${RESOLUTION} != 118 && ${RESOLUTION} != 240 && \
       ${RESOLUTION} != 300 && ${RESOLUTION} != 400
       @${ECHO_MSG} "Error: invalid value for RESOLUTION: \"${RESOLUTION}\""
       @${ECHO_MSG} "Possible values are: 118, 240, 300 (default) and 400."
       @${FALSE}
.endif
....

package:japanese/xdvi300[] verfügt ebenfalls über alle Patches, Paket-Dateien usw. Wenn Sie `make` eintippen, wird der Port die Standardvorgabe für die Auflösung nehmen (300) und den Port ganz normal erstellen.

Genauso wie für alle anderen Auflösungen ist dies das _vollständige_ [.filename]#xdvi118/Makefile#:

[.programlisting]
....
RESOLUTION=     118
MASTERDIR=      ${.CURDIR}/../xdvi300

.include "${MASTERDIR}/Makefile"
....

([.filename]#xdvi240/Makefile# und [.filename]#xdvi400/Makefile# sind ähnlich). Die `MASTERDIR`-Definition teilt dem [.filename]#bsd.port.mk# mit, dass die normalen Unterverzeichnisse wie `FILESDIR` und `SCRIPTDIR` unter [.filename]#xdvi300# gefunden werden können. Die `RESOLUTION=118`-Zeile wird die `RESOLUTION=300`-Zeile in [.filename]#xdvi300/Makefile# überschreiben und der Port wird mit einer Auflösung von 118 erstellt.

[[makefile-manpages]]
== Manualpages

Die Variablen `MAN[1-9LN]` werden automatisch jede Manualpage zur [.filename]#pkg-plist# hinzufügen (dies bedeutet, dass Sie Manualpages _nicht_ in der [.filename]#pkg-plist# auflisten dürfen, lesen Sie bitte <<plist-sub,Erstellung der PLIST>> für weitere Details). Sie veranlassen zudem den Installationsabschnitt dazu, die Manualpages zu Komprimieren oder zu Dekomprimieren abhängig vom gesetzten Wert der Variable `NO_MANCOMPRESS` in [.filename]#/etc/make.conf#.

Falls Ihr Port versucht verschiedene Namen für Manualpages unter Zuhilfenahme von Symlinks oder Hardlinks zu installieren, müssen Sie die Variable `MLINKS` nutzen, um diese zu identifizieren. Der von Ihrem Port installierte Link wird von [.filename]#bsd.port.mk# gelöscht und wieder eingefügt, um sicherzustellen, dass er auf die korrekte Datei zeigt. Jede Manualpage, welche in `MLINKS` aufgeführt ist, darf nicht in der [.filename]#pkg-plist# aufgenommen werden.

Falls die Manualpages während der Installation komprimiert werden sollen, müssen Sie die Variable `MANCOMPRESSED` setzen. Diese Variable kann drei Werte annehmen, `yes`, `no` und `maybe`. `yes` bedeutet, dass Manualpages bereits komprimiert installiert sind, bei `no` sind sie es nicht und `maybe` bedeutet, dass die Software bereits den Wert von `NO_MANCOMPRESS` beachtet, damit [.filename]#bsd.port.mk# nichts Besonderes auszuführen hat.

`MANCOMPRESSED` wird automatisch auf `yes` gesetzt, wenn `USE_IMAKE` vorgegeben ist und gleichzeitig `NO_INSTALL_MANPAGES` nicht. Im umgekehrten Falle ist `MANCOMPRESSED` auf `no` gesetzt. Sie müssen es nicht explizit angeben, außer die Standardvorgabe ist für Ihren Port nicht passend.

Wenn Ihr Port den man tree irgendwo anders als in der Variable `PREFIX` verankert, können Sie ihn mit `MANPREFIX` bestimmen. Sollten zudem Manualpages nur in bestimmten Abschnitten an einem nicht-standardkonformen Platz liegen, wie z.B. bestimmte `Perl`-Modul-Ports, dann können Sie mittels der Variable `MAN_sect_PREFIX` (wobei _sect_ ein Wert aus `1-9`, `L` oder `N` ist) individuelle Pfade zu den Manualpages festlegen.

Wenn Ihre Manualpages in sprachspezifische Unterverzeichnisse installiert werden, dann bestimmen Sie bitte den Namen der Sprache mit der Variable `MANLANG`. Der Wert dieser Variable ist mit `""` vorgegeben (das bedeutet nur Englisch).

Hier ist ein Beispiel, welches alles zusammenfasst.

[.programlisting]
....
MAN1=          foo.1
MAN3=          bar.3
MAN4=          baz.4
MLINKS=        foo.1 alt-name.8
MANLANG=       "" ja
MAN3PREFIX=    ${PREFIX}/shared/foobar
MANCOMPRESSED= yes
....

Dies zeigt an, dass sechs Dateien von diesem Port installiert werden;

[.programlisting]
....
${MANPREFIX}/man/man1/foo.1.gz
${MANPREFIX}/man/ja/man1/foo.1.gz
${PREFIX}/shared/foobar/man/man3/bar.3.gz
${PREFIX}/shared/foobar/man/ja/man3/bar.3.gz
${MANPREFIX}/man/man4/baz.4.gz
${MANPREFIX}/man/ja/man4/baz.4.gz
....

[.filename]#${MANPREFIX}/man/man8/alt-name.8.gz# kann zusätzlich von Ihrem Port installiert werden, oder auch nicht. Unabhängig davon wird ein Symlink erstellt, welcher die Manualpages foo(1) und alt-name(8) einbindet.

Falls nur manche Manualpages übersetzt sind, können Sie einige dynamisch vom `MANLANG`-Inhalt erzeugte Variablen nutzen:

[.programlisting]
....
MANLANG=       "" de ja
MAN1=          foo.1
MAN1_EN=       bar.1
MAN3_DE=       baz.3
....

Dies führt zu folgender Liste von Dateien:

[.programlisting]
....
${MANPREFIX}/man/man1/foo.1.gz
${MANPREFIX}/man/de/man1/foo.1.gz
${MANPREFIX}/man/ja/man1/foo.1.gz
${MANPREFIX}/man/man1/bar.1.gz
${MANPREFIX}/man/de/man3/baz.3.gz
....

[[makefile-info]]
== Info-Dateien

Falls Ihr Paket GNU-Info-Dateien installiert, sollten diese in der `INFO`-Variablen augelistet sein (ohne das angehängte `.info`) mit einem Eintrag für jedes Dokument. Von diesen Dateien wird angenommen, dass sie nach [.filename]#PREFIX/INFO_PATH# installiert werden. Sie können `INFO_PATH` ändern, falls Ihr Paket einen anderen Ort vorsieht. Jedoch wird dies nicht empfohlen. Die Einträge enthalten nur den relativen Pfad zu [.filename]#PREFIX/INFO_PATH#. Zum Beispiel installiert package:lang/gcc34[] Info-Dateien nach [.filename]#PREFIX/INFO_PATH/gcc34#, wobei `INFO` etwa so aussieht: 

[.programlisting]
....
INFO= gcc34/cpp gcc34/cppinternals gcc34/g77 ...
....

Entsprechende Installations-/Deinstalltions-Codes werden vor der Paket-Registrierung automatisch der vorläufigen [.filename]#pkg-plist# hinzugefügt.

[[makefile-options]]
== Makefile-Optionen

Einige größere Applikationen können mit einer Reihe von Konfigurationen, die zusätzliche Funktionalitäten hinzufügen, erstellt werden, falls eine oder mehrere Bibliotheken oder Applikationen verfügbar sind. Dazu gehören die Auswahl von natürlichen Sprachen, GUI versus Kommandozeilen-Versionen oder die Auswahl aus mehreren Datenbank-Programmen. Da nicht alle Nutzer diese Bibliotheken oder Applikationen wollen, stellt das Ports-System hooks (Haken) zur Verfügung, damit der Autor des Ports bestimmen kann, welche Konfiguration erstellt werden soll.

=== KNOBS (Einstellungen)

==== `WITH_*` und `WITHOUT_*`

Diese Variablen sind entworfen worden, um vom System-Administrator gesetzt zu werden. Es gibt viele, die in http://www.freebsd.org/cgi/cvsweb.cgi/ports/KNOBS?rev=HEAD&content-type=text/x-cvsweb-markup[ports/KNOBS] standardisiert sind.

Benennen Sie Schalter bei der Erstellung eines Ports nicht programmspezifisch. Verwenden Sie zum Beispiel im Avahi-Port `WITHOUT_MDNS` anstelle von `WITHOUT_AVAHI_MDNS`.

[NOTE]
====
Sie sollten nicht annehmen, dass ein `WITH_*` notwendigerweise eine korrespondierende ``WITHOUT_*``-Variable hat oder umgekehrt. Im Allgemeinen wird diese Vorgabe einfach unterstellt.
====

[NOTE]
====
Falls nicht anderweitig festgelegt, werden diese Variablen nur dahingehend überprüft, ob sie gesetzt sind oder nicht - nicht darauf, ob sie auf bestimmte Werte wie `YES` oder `NO` gesetzt sind.
====

.Häufige `WITH_*` und ``WITHOUT_*``-Variablen 
[cols="1,1", frame="none", options="header"]
|===
| Variable
| Bedeutung

|`WITHOUT_NLS`
|Falls gesetzt, bedeutet sie, dass eine Internationalisierung nicht benötigt wird, was Kompilierzeit sparen kann. Als Vorgabe wird Internationalisierung gebraucht.

|`WITH_OPENSSL_BASE`
|Nutze die Version von OpenSSL aus dem Basissystem.

|`WITH_OPENSSL_PORT`
|Installiert die Version von OpenSSL aus package:security/openssl[], auch wenn das Basissystem auf aktuellem Stand ist.

|`WITHOUT_X11`
|Falls der Port mit oder ohne Unterstützung für X erstellt werden kann, dann sollte normalerweise mit X-Unterstützung erstellt werden. Falls die Variable gesetzt ist, soll die Version ohne X-Unterstützung erstellt werden.
|===

==== Benennung von Knobs (Einstellungen)

Um die Anzahl der Knobs niedrig zu halten und zum Vorteil des Anwenders, wird empfohlen, dass Porter ähnliche Namen für Knobs verwenden. Eine Liste der beliebtesten Knobs kann in der http://www.freebsd.org/cgi/cvsweb.cgi/ports/KNOBS?rev=HEAD&content-type=text/x-cvsweb-markup[KNOBS-Datei] eingesehen werden.

Knob-Namen sollten wiederspiegeln, was der Knob bedeutet und was er bewirkt. Wenn ein Port einen lib-Präfix im `PORTNAME` hat, dann soll das lib-Präfix im Knob-Namen entfallen.

=== `OPTIONS`

==== Hintergrund

Die `OPTIONS`-Variable gibt dem Nutzer, der diesen Port installiert, einen Dialog mit auswählbaren Optionen und speichert diese in [.filename]#/var/db/ports/portname/options#. Bei der nächsten Neuerstellung des Ports werden diese Einstellungen wieder verwandt. Sie werden sich niemals mehr an all die zwanzig `WITH_*` und `WITHOUT_*`-Optionen erinnern müssen, die Sie benutzt haben, um diesen Port zu erstellen!

Wenn der Anwender `make config` benutzt (oder ein `make build` das erste Mal laufen lässt) wird das Framework auf [.filename]#/var/db/ports/portname/options# die Einstellungen prüfen. Falls die Datei nicht existiert, werden die Werte von `OPTIONS` genutzt, um eine Dialogbox zu erzeugen, in welcher die Optionen an- oder abgeschaltet werden können. Dann wird die [.filename]#options#-Datei gespeichert und die ausgewählten Variablen werden bei der Erstellung des Ports benutzt.

Falls eine neue Version des Ports `OPTIONS` hinzufügt, wird der Dialog mit den gespeicherten Werten dem Nutzer angezeigt.

Benutzen Sie `make showconfig`, um die gespeicherte Konfiguration zu betrachten. Benutzen Sie `make rmconfig`, um die gespeicherte Konfiguration zu Löschen.

==== Syntax

Die Syntax für die `OPTIONS`-Variable lautet: 

[.programlisting]
....
OPTIONS=    OPTION    "descriptive text" default ...
....

Der Wert als Vorgabe ist entweder `ON` oder `OFF`. Wiederholungen dieser drei Felder sind erlaubt.

`OPTIONS`-Definitionen müssen vor der Einbindung von [.filename]#bsd.port.options.mk# erscheinen. Die `WITH_*` und `WITHOUT_*`-Variablen können nur nach der Einbindung von [.filename]#bsd.port.options.mk# getestet werden. [.filename]#bsd.port.pre.mk# kann auch stattdessen eingebunden werden und wird immer noch von vielen Ports eingebunden, die vor der Einführung von [.filename]#bsd.port.options.mk# erstellt wurden. Jedoch wirken manche Variablen nicht wie gewohnt nach der Einbindung von [.filename]#bsd.port.pre.mk#, typischerweise `USE_*`-Optionen.

[[ports-options-simple-use]]
.Einfache Anwendung von `OPTIONS`
[example]
====

[.programlisting]
....
OPTIONS=      FOO "Enable option foo" On \
              BAR "Support feature bar" Off

.include <bsd.port.options.mk>

.if defined(WITHOUT_FOO)
CONFIGURE_ARGS+=    --without-foo
.else
CONFIGURE_ARGS+=    --with-foo
.endif

.if defined(WITH_BAR)
RUN_DEPENDS+=    bar:${PORTSDIR}/bar/bar
.endif

.include <bsd.port.mk>
....

====

[[ports-options-old-style-use]]
.Veraltete Anwendung von `OPTIONS`
[example]
====

[.programlisting]
....
OPTIONS=      FOO "Enable option foo" On

.include <bsd.port.pre.mk>

.if defined(WITHOUT_FOO)
CONFIGURE_ARGS+=    --without-foo
.else
CONFIGURE_ARGS+=    --with-foo
.endif

.include <bsd.port.post.mk>
....

====

=== Automatische Aktivierung von Funktionen

Wenn Sie ein GNU-Konfigurationsskript benutzen, sollten Sie ein Auge darauf werfen, welche Funktionen durch die automatische Erkennung aktiviert werden. Schalten Sie Funktionen, die Sie nicht möchten, ausdrücklich durch Verwendung von `--without-xxx` oder `--disable-xxx` in der Variable `CONFIGURE_ARGS` einzeln ab.

.Falsche Behandlung einer Option
[example]
====
[.programlisting]
....
.if defined(WITH_FOO)
LIB_DEPENDS+=        foo.0:${PORTSDIR}/devel/foo
CONFIGURE_ARGS+=    --enable-foo
.endif
....

====

Stellen Sie sich vor im obigen Beispiel ist eine Bibliothek libfoo auf dem System installiert. Der Nutzer will nicht, dass diese Applikation libfoo benutzt, also hat er die Option auf "off" im `make config`-Dialog umgestellt. Aber das Konfigurationsskript der Applikation hat erkannt, dass die Bibliothek auf dem System vorhanden ist und fügt ihre Funktionen in die Binärdatei ein. Falls der Nutzer sich nun entschliesst libfoo von seinem System zu entfernen, dann wird das Ports-System nicht protestieren (es wurde keine Abhängigkeit von libfoo eingetragen), aber die Applikation bricht ab.

.Korrekte Behandlung einer Option
[example]
====
[.programlisting]
....
.if defined(WITH_FOO)
LIB_DEPENDS+=        foo.0:${PORTSDIR}/devel/foo
CONFIGURE_ARGS+=    --enable-foo
.else
CONFIGURE_ARGS+=    --disable-foo
.endif
....

====

Im zweiten Beispiel wird die Bibliothek libfoo explizit abgeschaltet. Das Konfigurationsskript aktiviert die entsprechenden Funktionen nicht in der Applikation trotz der Anwesenheit der Bibliothek auf dem System.

[[makefile-wrkdir]]
== Die Festlegung des Arbeitsverzeichnisses

Jeder Port wird extrahiert in ein Arbeitsverzeichnis, welches beschreibbar sein muss. Das Ports-System gibt als Standard vor, dass die `DISTFILES` in einem Verzeichnis namens `${DISTNAME}` entpackt werden. Mit anderen Worten, wenn Sie:

[.programlisting]
....
PORTNAME=      foo
PORTVERSION=   1.0
....

festgelegt haben, dann enthalten die Distributions-Dateien des Ports ein Verzeichnis auf oberster Ebene, [.filename]#foo-1.0#, und der Rest der Dateien befindet sich unter diesem Verzeichnis.

Es gibt eine Reihe von Variablen, die Sie überschreiben können, falls dies nicht der Fall sein sollte.

=== `WRKSRC`

Diese Variable listet den Namen des Verzeichnisses, welches erstellt wird, wenn die Distfiles der Applikation extrahiert werden. Wenn unser vorheriges Beispiel in einem Verzeichnis namens [.filename]#foo# (und nicht [.filename]#foo-1.0#) extrahiert wurde, würden Sie schreiben:

[.programlisting]
....
WRKSRC=      ${WRKDIR}/foo
....

oder möglicherweise

[.programlisting]
....
WRKSRC=      ${WRKDIR}/${PORTNAME}
....

=== `NO_WRKSUBDIR`

Wenn der Port überhaupt nicht in einem Unterverzeichnis extrahiert wird, sollten Sie dies mit dem Setzen von `NO_WRKSUBDIR` anzeigen.

[.programlisting]
....
NO_WRKSUBDIR= yes
....

[[conflicts]]
== Konfliktbehandlung

Es gibt drei verschiedene Variablen, um einen Konflikt zwischen Paketen und Ports zu dokumentieren: `CONFLICTS`, `CONFLICTS_INSTALL` sowie `CONFLICTS_BUILD`.

[NOTE]
====
`CONFLICTS` setzt automatisch die Variable `IGNORE`, die ausführlicher in crossref:porting-dads[dads-noinstall, Einen Port durch `BROKEN` - `FORBIDDEN` oder `IGNORE` als nicht installierbar markieren] beschrieben wird.
====

Beim Entfernen eines von mehreren in Konflikt stehenden Ports ist es ratsam, die `CONFLICTS`-Einträge in den anderen Ports für einige Monate beizubehalten, um Nutzer zu unterstützen, die ihre Ports nur sporadisch aktualisieren.

=== `CONFLICTS_INSTALL`

Falls Ihr Paket nicht mit anderen Paketen koexistieren kann (wegen Dateikonflikten, Laufzeit-Inkompatibilitäten usw.), führen Sie bitte die anderen Paketnamen in der Variable `CONFLICTS_INSTALL` auf. Sie können hier Shell-Globs wie `*` und `?` verwenden. Paketnamen sollten in der gleichen Weise aufgezählt werden, wie sie in [.filename]#/var/db/pkg# auftauchen. Bitte stellen Sie sicher, dass `CONFLICTS` nicht mit dem Paket des Ports selbst übereinstimmt, da ansonsten das Erzwingen der Installation durch `FORCE_PKG_REGISTER` nicht länger funktionieren wird.

=== `CONFLICTS_BUILD`

Wenn Ihr Port nicht gebaut werden kann, wenn ein bestimmter Port bereits installiert ist, geben Sie diesen in der Variable `CONFLICTS_BUILD` an. Sie können hier Shell-Globs wie `*` und `?` verwenden. Paketnamen sollten in der gleichen Weise aufgezählt werden, wie sie in [.filename]#/var/db/pkg# auftauchen. Die CONFLICTS_BUILD-Prüfung erfolgt vor dem Bau des Ports. Baukonflikte werden im erzeugten Paket nicht verzeichnet.

=== `CONFLICTS`

Wenn Ihr Port nicht gebaut werden kann, wenn ein bestimmter Port bereits installiert ist und das aus dem Port erzeugte Paket nicht mit dem anderen Paket koexistieren kann, geben Sie das andere Paket in der Variable `CONFLICTS` an. Sie können hier Shell-Globs wie `*` und `?` verwenden. Paketnamen sollten in der gleichen Weise aufgezählt werden, wie sie in [.filename]#/var/db/pkg# auftauchen. Bitte stellen Sie sicher, dass `CONFLICTS_INSTALL` nicht mit dem Paket des Ports selbst übereinstimmt, da ansonsten das Erzwingen der Installation durch `FORCE_PKG_REGISTER` nicht länger funktionieren wird. Die CONFLICTS-Prüfung erfolgt vor dem Bau des Ports und vor der Installation des gebauten Ports.

[[install]]
== Installation von Dateien

[[install-macros]]
=== INSTALL_* macros

Nutzen Sie die Makros in [.filename]#bsd.port.mk#, um korrekte Modi und Eigentümer von Dateien in Ihren `*-install`-Targets sicherzustellen.

* `INSTALL_PROGRAM` ist ein Befehl, um binäre Binärdateien zu installieren.
* `INSTALL_SCRIPT` ist ein Befehl, um ausführbare Skripte zu installieren.
* `INSTALL_LIB` ist ein Befehl zur Installation Shared-Libraries.
* `INSTALL_KLD` ist ein Befehl, mit dem Kernelmodule installiert werden können. Einige Architekturen haben Probleme mit stripped-Modulen. Daher sollten Sie diesen Befehl anstelle von `INSTALL_PROGRAM` verwenden.
* `INSTALL_DATA` ist ein Befehl, um gemeinsam nutzbare Daten zu installieren.
* `INSTALL_MAN` ist ein Befehl, um Manualpages oder andere Dokumentation zu installieren (es wird nichts komprimiert).

Das sind grundsätzlich alle `install`-Befehle mit ihren passenden Flags.

[[install-strip]]
=== Zerlegen von Binärdateien und Shared-Libraries

Zerlegen Sie keine Binärdateien manuell, wenn Sie es nicht müssen. Alle Binaries sollten gestripped werden; allerdings vermag das `INSTALL_PROGRAM`-Makro gleichzeitig eine Binärdatei zu installieren und zu strippen (beachten Sie den nächsten Abschnitt). Das Makro `INSTALL_LIB` erledigt das gleiche für Shared-Libraries.

Wenn Sie eine Datei strippen müssen, aber weder das `INSTALL_PROGRAM`- noch das `INSTALL_LIB`-Makro nutzen wollen, dann kann `${STRIP_CMD}` Ihr Programm strippen. Dies wird typischerweise innerhalb des `post-install`-Targets gemacht. Zum Beispiel:

[.programlisting]
....
post-install:
    ${STRIP_CMD} ${PREFIX}/bin/xdl
....

Nutzen Sie man:file[1] für die installierte Applikation, um zu überprüfen, ob eine Binärdatei gestripped ist oder nicht. Wenn es nicht meldet `not stripped`, dann ist es bereits gestripped. Zudem wird man:strip[1] nicht ein bereits gestripptes Programm nochmals versuchen zu strippen, sondern wird stattdessen einfach sauber beenden.

[[install-copytree]]
=== Installation eines ganzen Verzeichnisbaums inklusive Dateien

Manchmal muss man eine große Zahl von Dateien unter Erhalt ihrer hierarchischen Struktur installieren, d.h. Kopieraktionen über einen ganzen Verzeichnisbaum von `WRKSRC` zu einem Zielverzeichnis unter `PREFIX`.

Für diesen Fall gibt es zwei Makros. Der Vorteil der Nutzung dieser Makros anstatt `cp` ist, dass sie korrekte Besitzer und Berechtigungen auf den Zieldateien garantieren. Das erste Makro, `COPYTREE_BIN`, wird alle installierten Dateien ausführbar markieren und damit passend für die Installation in [.filename]#PREFIX/bin# vorbereiten. Das zweite Makro, `COPYTREE_SHARE`, setzt keine Ausführungsberechtigungen auf Dateien und ist daher geeignet für die Installation von Dateien im Target von [.filename]#PREFIX/share#.

[.programlisting]
....
post-install:
    ${MKDIR} ${EXAMPLESDIR}
    (cd ${WRKSRC}/examples/ && ${COPYTREE_SHARE} \* ${EXAMPLESDIR})
....

Dieses Beispiel wird den Inhalt des [.filename]#examples#-Verzeichnisses im Distfile des Drittanbieters in das Beispielverzeichnis Ihres Ports kopieren.

[.programlisting]
....
post-install:
    ${MKDIR} ${DATADIR}/summer
    (cd ${WRKSRC}/temperatures/ && ${COPYTREE_SHARE} "June July August" ${DATADIR}/summer/)
....

Und dieses Beispiel wird die Daten der Sommermonate in das [.filename]#summer#-Unterverzeichnis eines [.filename]#DATADIR# installieren.

Zusätzliche `find`-Argumente können mit dem dritten Argument an die `COPYTREE_*`-Makros übergeben werden. Um zum Beispiel alle Dateien aus dem 1. Beispiel ohne die Makefiles zu installieren, kann man folgenden Befehl benutzen.

[.programlisting]
....
post-install:
    ${MKDIR} ${EXAMPLESDIR}
    (cd ${WRKSRC}/examples/ && \
	${COPYTREE_SHARE} \* ${EXAMPLESDIR} "! -name Makefile")
....

Beachten Sie bitte, dass diese Makros die installierten Dateien nicht zur [.filename]#pkg-plist# hinzufügen, Sie müssen sie immer noch selbst auflisten.

[[install-documentation]]
=== Installation zusätzlicher Dokumentation

Falls Ihre Software zusätzlich zu den üblichen Manualpages und Info-Seiten weitere Dokumentation hat und Sie diese für nützlich halten, dann installieren Sie sie unter [.filename]#PREFIX/shared/doc#. Dies kann wie vorstehend im Target des `post-install` geschehen.

Legen Sie ein neues Verzeichnis für Ihren Port an. Das Verzeichnis sollte wiederspiegeln, was der Port ist. Das bedeutet normalerweise `PORTNAME`. Wie auch immer, wenn Sie meinen, der Nutzer möchte verschiedene Versionen des Ports zur gleichen Zeit installiert haben, dann können Sie die gesamte Variable `PKGNAME` nutzen.

Machen Sie die Installation von der Variablen `NOPORTDOCS` abhängig, damit die Nutzer sie in [.filename]#/etc/make.conf# abschalten können:

[.programlisting]
....
post-install:
.if !defined(NOPORTDOCS)
    ${MKDIR} ${DOCSDIR}
    ${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${DOCSDIR}
.endif
....

Hier einige praktische Variablen und wie sie standardmässig bei Verwendung im [.filename]#Makefile# expandiert werden:

* `DATADIR` wird expandiert zu [.filename]#PREFIX/shared/PORTNAME#.
* `DATADIR_REL` wird expandiert zu [.filename]#share/PORTNAME#.
* `DOCSDIR` wird expandiert zu [.filename]#PREFIX/shared/doc/PORTNAME#.
* `DOCSDIR_REL` wird expandiert zu [.filename]#share/doc/PORTNAME#.
* `EXAMPLESDIR` wird expandiert zu [.filename]#PREFIX/shared/examples/PORTNAME#.
* `EXAMPLESDIR_REL` wird expandiert zu [.filename]#share/examples/PORTNAME#.

[NOTE]
====
`NOPORTDOCS` behandelt nur zusätzliche Dokumentation, die in `DOCSDIR` installiert ist. Für normale Manualpages und Info-Seiten wird die Variable benutzt. Dinge, welche in `DATADIR` und `EXAMPLESDIR` installiert werden, legen die Variablen `NOPORTDATA` und `NOPORTEXAMPLES` fest.
====

Die Variablen werden nach `PLIST_SUB` exportiert. Ihre Werte erscheinen dort als Pfadnamen relativ zu [.filename]#PREFIX#, falls möglich. Das bedeutet, dass [.filename]#share/doc/PORTNAME# standardmässig ersetzt wird durch `%%DOCSDIR%%` in der Packliste usw. (mehr zur Ersetzung durch die [.filename]#pkg-plist# finden Sie <<plist-sub,hier>>).

Alle installierten Dokumentationsdateien und -Verzeichnisse sollten in der [.filename]#pkg-plist# dem `%%PORTDOCS%%`-Präfix enthalten sein, zum Beispiel:

[.programlisting]
....
%%PORTDOCS%%%%DOCSDIR%%/AUTHORS
%%PORTDOCS%%%%DOCSDIR%%/CONTACT
%%PORTDOCS%%@dirrm %%DOCSDIR%%
....

Alternativ zur Auflistung der Dokumentationsdateien in der [.filename]#pkg-plist# kann in einem Port auch die Variable `PORTDOCS` gesetzt werden für eine Liste von Dateien und Shell-Globs, um diese zur endgültigen Packliste hinzuzufügen. Die Namen werden relativ zur Variable `DOCSDIR` sein. Wenn Sie also einen Port haben, welcher `PORTDOCS` benutzt, und Sie haben eine vom Standard abweichenden Platz für seine Dokumentation, dann müssen Sie die Variable `DOCSDIR` entsprechend setzen. Wenn ein Verzeichnis in `PORTDOCS` aufgeführt ist, oder von einem Shell-Glob dieser Variable abgebildet wird, dann wird der komplette Verzeichnisbaum inklusive Dateien und Verzeichnissen in der endgültigen Packliste aufgenommen. Wenn die Variable `NOPORTDOCS` gesetzt ist, dann werden die Dateien und Verzeichnisse, die in `PORTDOCS` aufgelistet sind, nicht installiert und werden auch nicht zur Packliste des Ports hinzugefügt. Wie oben gezeigt bleibt es dem Port selbst überlassen, die Dokumentation in `PORTDOCS` zu installieren. Ein typisches Beispiel für den Gebrauch von `PORTDOCS` sieht wie folgt aus:

[.programlisting]
....
PORTDOCS=       README.* ChangeLog docs/*
....

[NOTE]
====
Die Äquivalente zu `PORTDOCS` für unter `DATADIR` und `EXAMPLESDIR` installierte Dateien sind `PORTDATA` beziehungsweise `PORTEXAMPLES`.

Sie können auch [.filename]#pkg-message# benutzen, um Meldungen während der Installation anzuzeigen. Lesen Sie <<porting-message,diesen Abschnitt über den Gebrauch von [.filename]#pkg-message#>> für weitere Details. Die [.filename]#pkg-message#-Datei muss nicht zur [.filename]#pkg-plist# hinzugefügt werden.
====

[[install-subdirs]]
=== Unterverzeichnisse mit PREFIX

Lassen Sie den Port die Dateien in die richtigen Unterverzeichnisse von `PREFIX` verteilen. Einige Ports werfen alles in einen Topf und legen es im Unterverzeichnis mit dem Namen des Ports ab, was falsch ist. Ausserdem legen viele Ports alles ausser Binaries, Header-Dateien und Manualpages in ein Unterverzeichnis von [.filename]#lib#, was natürlich auch nicht der BSD-Philosophie entspricht und nicht gut funktioniert. Viele der Dateien sollten in eines der folgenden Verzeichnisse geschoben werden: [.filename]#etc# (Konfigurationsdateien), [.filename]#libexec# (intern gestartete Binärdateien), [.filename]#sbin# (Binärdateien für Superuser/Manager), [.filename]#info# (Dokumentation für Info-Browser) oder [.filename]#share# (Architektur-unabhängige Dateien). Lesen Sie hierzu man:hier[7]; weitestgehend greifen die Regeln für [.filename]#/usr# auch für [.filename]#/usr/local#. Die Ausnahme sind Ports, welche mit "news" aus dem USENET arbeiten. In diesem Falle sollte [.filename]#PREFIX/news# als Zielort für die Dateien benutzt werden.
