                          Das FreeBSD Porter-Handbuch

  The FreeBSD German Documentation Project

   Version: 46318

   Copyright (c) 2000-2015 The FreeBSD German Documentation Project

   FreeBSD ist ein eingetragenes Warenzeichen von der FreeBSD Foundation.

   UNIX ist ein eingetragenes Warenzeichen von The Open Group in den
   Vereinigten Staaten und in anderen La:ndern.

   Sun, Sun Microsystems, SunOS, Solaris, Java, JDK und OpenJDK sind
   Warenzeichen oder eingetragene Warenzeichen von Sun Microsystems, Inc. in
   den Vereinigten Staaten und in anderen La:ndern.

   Apple und QuickTime sind Warenzeichen oder eingetragene Warenzeichen von
   Apple Computer, Inc. in den Vereinigten Staaten und in anderen La:ndern.

   Macromedia und Flash sind Warenzeichen oder eingetragene Warenzeichen von
   Macromedia, Inc. in den Vereinigten Staaten und/oder in anderen La:ndern.

   Microsoft, Windows, und Windows Media sind Warenzeichen oder eingetragene
   Warenzeichen der Microsoft Corporation in den Vereinigten Staaten und/oder
   in anderen La:ndern.

   PartitionMagic ist ein eingetragenes Warenzeichen von PowerQuest
   Corporation in den Vereinigten Staaten und/oder in anderen La:ndern.

   Viele Produktbezeichnungen von Herstellern und Verka:ufern sind
   Warenzeichen. Soweit dem FreeBSD Project das Warenzeichen bekannt ist,
   werden die in diesem Buch vorkommenden Bezeichnungen mit dem Symbol (TM)
   gekennzeichnet.

   Redistribution and use in source (SGML DocBook) and 'compiled' forms
   (SGML, HTML, PDF, PostScript, RTF and so forth) with or without
   modification, are permitted provided that the following conditions are
   met:

    1. Redistributions of source code (SGML DocBook) must retain the above
       copyright notice, this list of conditions and the following disclaimer
       as the first lines of this file unmodified.

    2. Redistributions in compiled form (transformed to other DTDs, converted
       to PDF, PostScript, RTF and other formats) must reproduce the above
       copyright notice, this list of conditions and the following disclaimer
       in the documentation and/or other materials provided with the
       distribution.

  Wichtig:

   THIS DOCUMENTATION IS PROVIDED BY THE FREEBSD DOCUMENTATION PROJECT "AS
   IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
   THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
   PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FREEBSD DOCUMENTATION
   PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
   EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
   PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
   PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
   LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
   NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
   DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

   Zuletzt bearbeitet am 2015-03-05 21:37:34 von bhd.
   [ einzelne Abschnitte / komplettes Dokument ]

     ----------------------------------------------------------------------

   Inhaltsverzeichnis

   1. Einfu:hrung

   2. Einen neuen Port erstellen

   3. Einen neuen Port erstellen

                3.1. Das Makefile schreiben

                3.2. Die Beschreibungsdateien erstellen

                3.3. Die Checksummendatei erzeugen

                3.4. Den Port testen

                3.5. Ihren Port mit portlint u:berpru:fen

                3.6. Den neuen Port einreichen

   4. Einen Port in aller Ruhe erstellen

                4.1. Die Funktionsweise

                4.2. Den originalen Quelltext besorgen

                4.3. Den Port bearbeiten

                4.4. Fehlerbehebung (Patches)

                4.5. Konfigurieren

                4.6. Handhabung von Benutzereingaben

   5. Die Konfiguration des Makefile

                5.1. Der originale Quelltext

                5.2. Bezeichnungen

                5.3. Kategorisierung

                5.4. Die Distributionsdateien

                5.5. MAINTAINER

                5.6. COMMENT

                5.7. Abha:ngigkeiten (dependencies)

                5.8. MASTERDIR

                5.9. Manualpages

                5.10. Info-Dateien

                5.11. Makefile-Optionen

                5.12. Die Festlegung des Arbeitsverzeichnisses

                5.13. Konfliktbehandlung

                5.14. Installation von Dateien

   6. Besonderheiten

                6.1. Shared-Libraries

                6.2. Ports mit beschra:nkter Verbreitung

                6.3. Build-Mechanismen

                6.4. Benutzung von GNU autotools

                6.5. Benutzung von GNU gettext

                6.6. Die Benutzung von perl

                6.7. Benutzung von X11

                6.8. Benutzung von GNOME

                6.9. Benutzung von Qt

                6.10. Benutzung von KDE

                6.11. Benutzung von Java

                6.12. Webanwendungen, Apache und PHP

                6.13. Python benutzen

                6.14. Benutzung von Tcl/Tk

                6.15. Emacs benutzen

                6.16. Ruby benutzen

                6.17. SDL verwenden

                6.18. wxWidgets verwenden

                6.19. Verwendung von Lua

                6.20. Xfce verwenden

                6.21. Mozilla verwenden

                6.22. Benutzung von Datenbanken

                6.23. Starten und Anhalten von Diensten (rc Skripten)

                6.24. Hinzufu:gen von Benutzern und Gruppen

                6.25. Von Kernelquellen abha:ngige Ports

   7. Fortgeschrittene pkg-plist-Methoden

                7.1. A:nderungen an pkg-plist mit Hilfe von make-Variablen

                7.2. Leere Verzeichnisse

                7.3. Konfigurationsdateien

                7.4. Dynamische oder statische Paketliste

                7.5. Automatisiertes Erstellen von Paketlisten

   8. Die pkg-* Dateien

                8.1. pkg-message

                8.2. pkg-install

                8.3. pkg-deinstall

                8.4. pkg-req

                8.5. A:ndern der Namen der pkg-* Dateien

                8.6. Nutzung von SUB_FILES und SUB_LIST

   9. Ihren Port testen

                9.1. make describe ausfu:hren

                9.2. Portlint

                9.3. Port Tools

                9.4. PREFIX und DESTDIR

                9.5. Die Tinderbox

   10. Einen existierenden Port aktualisieren

                10.1. Patches mit CVS erstellen

                10.2. Die Dateien UPDATING und MOVED

   11. Sicherheit der Ports

                11.1. Warum Sicherheit so wichtig ist

                11.2. Sicherheitslu:cken schliessen

                11.3. Die Community informiert halten

   12. Was man machen respektive vermeiden sollte

                12.1. Einfu:hrung

                12.2. WRKDIR

                12.3. WRKDIRPREFIX

                12.4. Unterschiedliche Betriebssysteme und
                Betriebssystemversionen

                12.5. __FreeBSD_version Werte

                12.6. Etwas hinter die bsd.port.mk-Anweisung schreiben

                12.7. Benutzen Sie die exec-Anweisung in Wrapper-Skripten

                12.8. Aufgaben vernu:nftig lo:sen

                12.9. Beru:cksichtigen Sie sowohl CC als auch CXX

                12.10. Beru:cksichtigen Sie CFLAGS

                12.11. Threading-Bibliotheken

                12.12. Ru:ckmeldungen

                12.13. README.html

                12.14. Einen Port durch BROKEN, FORBIDDEN oder IGNORE als
                nicht installierbar markieren

                12.15. Kennzeichnen eines Ports zur Entfernung durch
                DEPRECATED oder EXPIRATION_DATE

                12.16. Vermeiden Sie den Gebrauch des .error-Konstruktes

                12.17. Verwendung von sysctl

                12.18. Erneutes Ausliefern von Distfiles

                12.19. Verschiedenes

   13. Beispiel eines Makefile

   14. Auf dem Laufenden bleiben

                14.1. FreshPorts

                14.2. Die Webschnittstelle zum Quelltext-Repository

                14.3. Die FreeBSD Ports-Mailingliste

                14.4. Der Cluster zum Bauen von FreeBSD-Ports auf
                pointyhat.FreeBSD.org

                14.5. Der FreeBSD Ports-Distfile-Scanner

                14.6. Das FreeBSD Ports-Monitoring-System

   Tabellenverzeichnis

   5.1. Beliebte magic MASTER_SITES-Makros

   5.2. Die USE_*-Varibalen

   5.3. Ha:ufige WITH_* und WITHOUT_*-Variablen

   6.1. Port-Variablen im Zusammenhang mit gmake

   6.2. Variablen fu:r Ports, die configure benutzen

   6.3. Variablen fu:r Ports, die scons benutzen

   6.4. Variablen fu:r Ports, die perl benutzen

   6.5. Variablen fu:r Ports, die X benutzen

   6.6. Variablen bei Abha:ngigkeit von einzelnen Teilen von X11

   6.7. Variablen fu:r Ports, die Qt beno:tigen

   6.8. Zusa:tzliche Variablen fu:r Ports, die Qt 4.xi benutzen

   6.9. Verfu:gbare Qt4-Bibliothekskomponenten

   6.10. Verfu:gbare Qt4-Tool-Komponenten

   6.11. Verfu:gbare Qt4-Plugin-Komponenten

   6.12. Variablen fu:r Ports, die KDE 3 benutzen

   6.13. Verfu:gbare KDE 4-Komponenten

   6.14. Variablen, die von Ports, die Java benutzen, gesetzt werden mu:ssen

   6.15. Bereitgestellte Variablen fu:r Ports, die Java benutzen

   6.16. Konstanten, die fu:r Ports, welche Java benutzen, definiert sind

   6.17. Variablen fu:r Ports, die Apache verwenden

   6.18. Nu:tzliche Variablen fu:r Ports von Apache-Modulen

   6.19. Variablen fu:r Ports, die PHP verwenden

   6.20. Nu:tzliche Variablen fu:r Ports, die Python verwenden

   6.21. A:usserst nu:tzliche Variablen fu:r Ports, die Tcl/Tk benutzen

   6.22. Nu:tzliche Variablen fu:r Ports, die Ruby verwenden

   6.23. Ausgewa:hlte read-only-Variablen fu:r Ports, die Ruby verwenden

   6.24. Variablen, um die wxWidgets-Version festzulegen

   6.25. Verfu:gbare wxWidgets-Versionen

   6.26. Spezifikationen der wxWidgets-Versionen

   6.27. Variablen zur Festlegung der bevorzugten wxWidgets-Version

   6.28. Verfu:gbare wxWidgets-Komponenten

   6.29. Verfu:gbare Typen von wxWidgets-Abha:ngigkeiten

   6.30. Standardtypen der wxWidgets-Abha:ngigkeiten

   6.31. Variablen, um Unicode in den wxWidgets-Versionen auszuwa:hlen

   6.32. Vordefinierte Variablen fu:r Ports, die wxWidgets verwenden

   6.33. Zula:ssige Werte fu:r WX_CONF_ARGS

   6.34. Variablen, um die Lua-Version festzulegen

   6.35. Verfu:gbare Lua-Versionen

   6.36. Spezifikationen der Lua-Versionen

   6.37. Variablen zur Festlegung der bevorzugten Lua-Version

   6.38. Verfu:gbare Lua-Komponenten

   6.39. Verfu:gbare Typen von Lua-Abha:ngigkeiten

   6.40. Standardtypen fu:r Lua-Abha:ngigkeiten

   6.41. Vordefinierte Variablen fu:r Ports, die Lua verwenden

   6.42. Variablen fu:r Ports, die Mozilla verwenden

   6.43. Variablen fu:r Ports, die Datenbanken benutzen

   10.1. Von cvs update verwendete Pra:fixe

   12.1. __FreeBSD_version-Werte

   Liste der Beispiele

   5.1. Vereinfachtes Beispiel fu:r den Gebrauch von MASTER_SITES:n mit einer
   Datei pro Webseite

   5.2. Vereinfachtes Beispiel fu:r den Gebrauch von MASTER_SITES:n mit mehr
   als einer Datei pro Webseite

   5.3. Ausfu:hrliches Beispiel von MASTER_SITES:n in MASTER_SITE_SUBDIR

   5.4. Ausfu:hrliches Beispiel von MASTER_SITES:n mit Komma-Operator,
   mehreren Dateien, mehreren Webseiten und mehreren Unterverzeichnissen

   5.5. Ausfu:hrliches Beispiel von MASTER_SITES:n mit
   MASTER_SITE_SOURCEFORGE

   5.6. Vereinfachte Nutzung von MASTER_SITES:n mit PATCH_SITES.

   5.7. Nutzung von ALWAYS_KEEP_DISTFILES.

   5.8. Einfache Anwendung von OPTIONS

   5.9. Veraltete Anwendung von OPTIONS

   5.10. Falsche Behandlung einer Option

   5.11. Korrekte Behandlung einer Option

   6.1. Beispiel fu:r USE_XORG

   6.2. Benutzung von X11-bezogenen Variablen in einem Port

   6.3. Qt4-Komponenten auswa:hlen

   6.4. USE_KDE4-Beispiel

   6.5. Beispiel eines Makefiles fu:r eine PEAR Klasse

   6.6. Auswahl von wxWidgets-Komponenten

   6.7. Installierte wxWidgets-Versionen und -Komponenten feststellen

   6.8. Verwendung von wxWidgets-Variablen in Kommandos

   6.9. Auswahl der Lua-Version

   6.10. Auswahl von Lua-Komponenten

   6.11. Installierte Lua-Versionen und- Komponenten feststellen

   6.12. Einem Port mitteilen, in welchem Verzeichnis Lua liegt

   6.13. Verwendung von Lua-Variablen in Kommandos

   12.1. Wie vermeidet man die Verwendung von .error

                             Kapitel 1. Einfu:hrung

   Die Ports-Sammlung von FreeBSD ist der gebra:uchlichste Weg, um
   Anwendungen ("Ports") unter FreeBSD zu installieren. Wie alles andere in
   FreeBSD auch, ist sie hauptsa:chlich das Ergebnis der Arbeit von
   Freiwilligen. Es ist wichtig, diesen Aspekt beim Lesen im Hinterkopf zu
   behalten.

   In FreeBSD kann jeder einen neuen Port einsenden oder sich dazu bereit
   erkla:ren, einen bereits vorhandenen Port zu pflegen, sofern der Port
   derzeit keinen Maintainer hat - dazu sind keine besonderen Rechte no:tig.

                     Kapitel 2. Einen neuen Port erstellen

   Sie sind also daran interessiert, einen neuen Port zu erstellen oder einen
   vorhandenen zu aktualisieren? Grossartig!

   Die folgenden Kapitel beinhalten einige Richtlinien, um einen neuen Port
   fu:r FreeBSD zu erstellen. Wenn Sie einen vorhandenen Port auf den
   neuesten Stand bringen wollen, sollten Sie mit Kapitel 10, Einen
   existierenden Port aktualisieren fortfahren.

   Wenn Ihnen dieses Dokument nicht detailliert genug ist, sollten Sie einen
   Blick in /usr/ports/Mk/bsd.port.mk werfen. Das Makefile jedes Ports bindet
   diese Datei ein. Auch wenn Sie nicht ta:glich mit Makefiles arbeiten,
   sollten Sie gut damit zurecht kommen, da die Datei gut dokumentiert ist
   und Sie eine Menge Wissen daraus erlangen ko:nnen. Zusa:tzlich ko:nnen Sie
   speziellere Fragen an die FreeBSD ports-Mailingliste stellen.

  Anmerkung:

   Nur ein Bruchteil der Variablen (VAR), die von Ihnen gesetzt werden
   ko:nnen, finden hier Erwa:hnung. Die meisten von ihnen (wenn nicht sogar
   alle) sind am Anfang von /usr/ports/Mk/bsd.port.mk erla:utert. Beachten
   Sie bitte, dass diese Datei eine nicht standardkonforme
   Tabulator-Einstellung verwendet. Emacs und Vim sollten diese Einstellung
   jedoch automatisch beim O:ffnen der Datei setzen. Sowohl vi(1) als auch
   ex(1) ko:nnen mit dem Befehl :set tabstop=4 dazu gebracht werden, die
   Datei richtig anzuzeigen, wenn sie geo:ffnet wird.

   Sind Sie auf der Suche nach einer neuen Aufgabe? Dann sehen Sie sich bitte
   die Ports-Wunschliste an und pru:fen Sie, ob Sie an einem dieser Ports
   arbeiten ko:nnen.

                     Kapitel 3. Einen neuen Port erstellen

   Inhaltsverzeichnis

   3.1. Das Makefile schreiben

   3.2. Die Beschreibungsdateien erstellen

   3.3. Die Checksummendatei erzeugen

   3.4. Den Port testen

   3.5. Ihren Port mit portlint u:berpru:fen

   3.6. Den neuen Port einreichen

   Dieser Abschnitt beschreibt, wie Sie schnell einen neuen Port erstellen
   ko:nnen. In vielen Fa:llen ist dies allerdings nicht ausreichend, dann
   werden Sie in diesem Buch weiterlesen mu:ssen.

   Als Erstes besorgen Sie sich das Original-Tarball (komprimiertes Archiv)
   und legen es im DISTDIR ab, welches standardma:ssig /usr/ports/distfiles
   ist.

  Anmerkung:

   Im Folgenden wird angenommen, dass die Software unvera:ndert kompiliert
   werden konnte, dass also keinerlei A:nderungen no:tig waren, um den Port
   auf Ihrem FreeBSD-Rechner zum Laufen zu bringen. Falls Sie A:nderungen
   vornehmen mussten, werden Sie auch den na:chsten Abschnitt beachten
   mu:ssen.

3.1. Das Makefile schreiben

   Ein minimales Makefile sieht in etwa so aus:

 # New ports collection makefile for:   oneko
 # Date created:        5 December 1994
 # Whom:                asami
 #
 # $FreeBSD$
 #

 PORTNAME=      oneko
 PORTVERSION=   1.1b
 CATEGORIES=    games
 MASTER_SITES=  ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/

 MAINTAINER=    asami@FreeBSD.org
 COMMENT=       A cat chasing a mouse all over the screen

 MAN1=          oneko.1
 MANCOMPRESSED= yes
 USE_IMAKE=     yes

 .include <bsd.port.mk>

   Versuchen Sie es zu verstehen. Machen Sie sich keine Gedanken um die
   $FreeBSD$-Zeile, diese wird automatisch vom CVS eingefu:gt, wenn der Port
   in den Haupt-Ports-Tree importiert wird. Ein detailliertes Beispiel finden
   Sie im Abschnitt sample Makefile.

3.2. Die Beschreibungsdateien erstellen

   Es gibt zwei Beschreibungsdateien, die fu:r jeden Port beno:tigt werden,
   ob sie tatsa:chlich im Paket enthalten sind oder nicht. Dies sind
   pkg-descr und pkg-plist. Der pkg- Pra:fix unterscheidet sie von anderen
   Dateien.

  3.2.1. pkg-descr

   Diese entha:lt eine la:ngere Beschreibung des Ports. Einer oder mehrere
   Absa:tze, die kurz und pra:gnant erkla:ren, was der Port macht, sind
   ausreichend.

  Anmerkung:

   pkg-descr entha:lt keine Anleitung oder detaillierte Beschreibung wie der
   Port benutzt oder kompiliert wird! Bitte seien Sie vorsichtig, wenn Sie
   aus dem README oder der Manualpage kopieren ; Diese sind oft keine
   pra:gnanten Beschreibungen des Ports oder sie sind in einem ungu:nstigen
   Format (Manualpages haben z.B. bu:ndige Zwischenra:ume). Wenn es fu:r die
   portierte Software eine offizielle Webseite gibt, sollten Sie diese hier
   angeben. Fu:gen Sie hierzu eine der Webseiten mit dem Pra:fix WWW: ein,
   damit automatische Werkzeuge korrekt arbeiten.

   Das folgende Beispiel zeigt wie Ihre pkg-descr aussehen sollte:

 This is a port of oneko, in which a cat chases a poor mouse all over
 the screen.
  :
 (etc.)

 WWW: http://www.oneko.org/

  3.2.2. pkg-plist

   Diese Datei entha:lt eine Liste aller Dateien, die von diesem Port
   installiert werden. Sie wird auch die "Packliste" genannt, da das Paket
   durch die hier aufgefu:hrten Dateien erstellt wird. Die Pfadangaben sind
   relativ zum Installationspra:fix (fu:r gewo:hnlich /usr/local oder
   /usr/X11R6). Wenn Sie die MANn-Variablen verwenden (was Sie auch machen
   sollten), fu:hren Sie hier keine Manualpages auf. Wenn der Port wa:hrend
   der Installation Verzeichnisse erstellt, stellen Sie sicher entsprechende
   @dirrm-Zeilen einzufu:gen, um die Verzeichnisse zu entfernen, wenn das
   Paket gelo:scht wird.

   Hier ist ein kleines Beispiel:

 bin/oneko
 lib/X11/app-defaults/Oneko
 lib/X11/oneko/cat1.xpm
 lib/X11/oneko/cat2.xpm
 lib/X11/oneko/mouse.xpm
 @dirrm lib/X11/oneko

   Fu:r weitere Details zur Packliste lesen Sie in der pkg_create(1)
   Manualpage nach.

  Anmerkung:

   Es wird empfohlen alle Dateinamen in dieser Datei alphabetisch sortiert zu
   halten. Das erlaubt Ihnen die A:nderungen bei einem Upgrade Ihres Ports
   deutlich einfacher zu U:berpru:fen.

  Anmerkung:

   Eine Packlist von Hand zu erzeugen kann eine sehr mu:hsame Aufgabe sein.
   Wenn der Port eine grosse Anzahl Dateien installiert, kann es Zeit sparen,
   eine Packliste automatisch zu erstellen.

   Es gibt nur einen Fall, in dem pkg-plist weggelassen werden kann. Wenn der
   Port nur eine handvoll Dateien und Verzeichnisse installiert, ko:nnen
   diese in den Variablen PLIST_FILES und PLIST_DIRS im Makefile aufgelistet
   werden. Zum Beispiel ko:nnten wir im obigen Beispiel ohne pkg-plist fu:r
   den oneko-Port auskommen, indem wir die folgenden Zeilen ins Makefile
   einfu:gen:

 PLIST_FILES=    bin/oneko \
                 lib/X11/app-defaults/Oneko \
                 lib/X11/oneko/cat1.xpm \
                 lib/X11/oneko/cat2.xpm \
                 lib/X11/oneko/mouse.xpm
 PLIST_DIRS=     lib/X11/oneko

   Natu:rlich sollte PLIST_DIRS ungesetzt bleiben, wenn der Port keine
   eigenen Verzeichnisse installiert.

   Der Preis fu:r diese Art die Dateien eines Ports anzugeben ist, dass man
   keine Befehlsfolgen wie in pkg_create(1) nutzen kann. Deshalb ist es nur
   fu:r einfache Ports geeignet und macht diese noch einfacher. Gleichzeitig
   bringt es den Vorteil die Anzahl der Dateien in der Ports-Sammlung zu
   reduzieren. Deshalb ziehen Sie bitte diese Vorgehensweise in Erwa:gung,
   bevor Sie pkg-plist benutzen.

   Spa:ter werden wir uns ansehen, wie pkg-plist und PLIST_FILES benutzt
   werden ko:nnen, um anspruchsvollere Aufgaben zu erfu:llen.

3.3. Die Checksummendatei erzeugen

   Geben Sie einfach make makesum ein. Die Regeln von Make sorgen dafu:r,
   dass die Datei distinfo automatisch erstellt wird.

   Wenn sich die Checksumme einer heruntergeladenen Datei regelma:ssig
   a:ndert und Sie sicher sind, dass Sie der Quelle trauen ko:nnen (weil sie
   z.B. von einer Hersteller-CD oder ta:glich erstellter Dokumentation
   stammt), sollten Sie diese Dateien in der Variable IGNOREFILES angeben.
   Dann wird die Checksumme fu:r diese Datei bei make makesum nicht
   berechnet, sondern auf IGNORE gesetzt.

3.4. Den Port testen

   Sie sollten sicherstellen, dass die Port-Regeln genau das einhalten, was
   Sie von ihnen erwarten, auch beim Erzeugen eines Pakets aus dem Port. Dies
   sind die wichtigen Punkte, die Sie u:berpru:fen sollten.

     * pkg-plist entha:lt nichts, das nicht von Ihrem Port installiert wurde.

     * pkg-plist entha:lt alles, was von Ihrem Port installiert wurde.

     * Ihr Port kann mit Hilfe von make reinstall mehrmals installiert
       werden.

     * Ihr Port ra:umt bei der Deinstallation hinter sich auf.

   Prozedur 3.1. Empfohlene Testreihenfolge
    1. make install

    2. make package

    3. make deinstall

    4. pkg_add Paket-Name

    5. make deinstall

    6. make reinstall

    7. make package

   Stellen Sie bitte sicher, dass wa:hrend make package und make deinstall
   keine Warnungen ausgegeben werden. Nach Schritt 3 u:berpru:fen Sie bitte,
   ob alle neuen Verzeichnisse korrekt entfernt wurden. Und versuchen Sie die
   Software nach Schritt 4 zu benutzen, um sicherzustellen, dass sie korrekt
   funktioniert, wenn diese aus einem Paket installiert wird.

   Der gru:ndlichste Weg diese Schritte zu automatisieren ist eine Tinderbox
   zu installieren. Diese verwaltet Jails, in denen Sie alle oben genannten
   Schritte durchfu:hren ko:nnen, ohne den Zustand Ihres laufenden Systems zu
   vera:ndern. Mehr Informationen hierzu enta:lt ports/ports-mgmt/tinderbox

3.5. Ihren Port mit portlint u:berpru:fen

   Bitte verwenden Sie portlint, um festzustellen, ob Ihr Port unseren
   Richtlinien entspricht. Das Programm ports-mgmt/portlint ist Teil der
   Ports-Sammlung. Stellen Sie vor allem sicher, dass das Makefile in der
   richtigen Form und das Paket passend benannt ist.

3.6. Den neuen Port einreichen

   Bevor Sie den neuen Port einreichen, lesen Sie bitte unbedingt den
   Abschnitt DOs and DON'Ts.

   Nun, da Sie mit Ihrem Port zufrieden sind, mu:ssen Sie ihn nur noch in den
   Haupt-Ports-Tree von FreeBSD einbringen, damit alle daran teilhaben
   ko:nnen. Wir beno:tigen nicht Ihr work-Verzeichnis oder Ihr
   pkgname.tgz-Paket - diese ko:nnen Sie nun lo:schen. Wenn Ihr Port
   beispielsweise oneko heisst, wechseln Sie in das Verzeichnis, in dem sich
   das Verzeichnis oneko befindet und fu:hren den Befehl shar `find oneko` >
   oneko.shar aus.

   Fu:gen Sie Ihre Datei oneko.shar einem Fehlerbericht an und senden Sie
   diesen mit Hilfe des Programms send-pr(1) (unter Bug Reports and General
   Commentary finden Sie weitere Informationen u:ber send-pr(1)). Ordnen Sie
   den Fehlerbericht bitte in die Kategorie Ports mit der Klasse
   Change-Request ein (Markieren Sie den Bericht nicht als vertraulich
   (confidential)!). Fu:gen Sie bitte eine kurze Beschreibung des Programms,
   das Sie portiert haben, in das "Beschreibungs"-Feld des Problemberichts
   und die shar-Datei in das "Fix"-Feld ein (bespielsweise eine kurze Version
   des COMMENT).

  Anmerkung:

   Sie ko:nnen uns die Arbeit um einiges vereinfachen, wenn Sie eine gute
   Beschreibung in der Zusammenfassung des Problemberichtes verwenden. Wir
   bevorzugen etwas wie "Neuer Port: <Kategorie>/<Portname><Kurzbeschreibung
   des Ports>" fu:r neue Ports. Wenn Sie sich an dieses Schema halten, ist
   die Chance, dass sich jemand bald Ihren Bericht ansieht, deutlich besser.

   Noch einmal: Bitte fu:gen Sie nicht das distfile der Originalquelle, das
   work-Verzeichnis oder das Paket, das Sie mit make package erstellt haben,
   ein. Und verwenden Sie shar(1) fu:r neue Ports (und NICHT diff(1)).

   Haben Sie bitte etwas Geduld, nachdem Sie den Port eingereicht haben.
   Manchmal kann es einige Monate dauern, bevor ein Port in FreeBSD
   eingefu:gt wird, obwohl es wahrscheinlich nur ein paar Tage dauert. Sie
   ko:nnen sich die Liste der PRs, die darauf warten, in FreeBSD committet zu
   werden, ansehen.

   Nachdem wir einen Blick auf Ihren Port geworfen haben, werden wir, wenn
   no:tig, bei Ihnen nachfragen und ihn in die Ports-Sammlung u:bernehmen.
   Ihr Name taucht dann auch in der Liste der Additional FreeBSD Contributors
   und in anderen Dateien auf. Ist das nicht toll?! :-)

                 Kapitel 4. Einen Port in aller Ruhe erstellen

   Inhaltsverzeichnis

   4.1. Die Funktionsweise

   4.2. Den originalen Quelltext besorgen

   4.3. Den Port bearbeiten

   4.4. Fehlerbehebung (Patches)

   4.5. Konfigurieren

   4.6. Handhabung von Benutzereingaben

   Ok, das war nicht ganz einfach und der Port hat einige Vera:nderungen
   erfordert, um funktionieren zu ko:nnen. In diesem Abschnitt werden wir
   Schritt fu:r Schritt erkla:ren, wie man den funktionierenden Port den
   Vorgaben der Ports entsprechend anpasst.

4.1. Die Funktionsweise

   Beginnen wir mit der Abfolge der Ereignisse, die eintreten, wenn der
   Nutzer das erste make in Ihrem Portsverzeichnis ausfu:hrt. Sie empfinden
   es fu:r das Versta:ndnis vielleicht hilfreich bsd.port.mk in einem anderen
   Fenster offen zu haben, wa:hrend Sie diesen Abschnitt lesen.

   Aber machen Sie sich keine Sorgen, falls Sie nicht wirklich verstehen, was
   bsd.port.mk macht, die Wenigsten begreifen dies... :>

    1. Das Target fetch wird aufgerufen. Es ist dafu:r verantwortlich
       sicherzustellen, dass der Tarball lokal im DISTDIR verfu:gbar ist.
       Falls fetch die beno:tigten Dateien in DISTDIR nicht finden kann,
       durchsucht es die URL MASTER_SITES, welche im Makefile gesetzt ist,
       ebenso wie unsere Haupt-FTP-Seite unter
       ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/ , wo wir genehmigte
       Distfiles als Backup aufbewahren. Danach wird versucht, so eine
       direkte Internetverbindung besteht, dass genannte Distfile mit FETCH
       herunterzuladen. Falls dies gelingt, wird die Datei in DISTDIR fu:r
       weitere Nutzung abgelegt und fa:hrt fort.

    2. Das Target extract wird aufgerufen. Es sucht nach den Distfiles Ihres
       Ports (normalerweise ein gzip-komprimierter Tarball) in DISTDIR und
       entpackt diese in ein tempora:res Unterverzeichnis, welches von WRKDIR
       festgelegt wird (standardma:ssig work).

    3. Das Target patch wird aufgerufen. Zuerst werden alle in PATCHFILES
       festgelegten Patches eingespielt. Anschliessend werden, falls Patches
       der Form patch-* in PATCHDIR (standardma:ssig das
       files-Unterverzeichnis) gefunden werden, diese in alphabetischer
       Reihenfolge eingespielt.

    4. Das Target configure wird aufgerufen. Dieses kann viele verschiedene
       Dinge machen.

         1. Existiert scripts/configure, so wird es aufgerufen.

         2. Falls HAS_CONFIGURE oder GNU_CONFIGURE gesetzt sind, wird
            WRKSRC/configure ausgefu:hrt.

         3. Falls USE_IMAKE gesetzt ist, wird XMKMF (standardma:ssig xmkmf
            -a) ausgefu:hrt.

    5. Das Target build wird aufgerufen. Es ist fu:r das Wechseln in das
       private Arbeitsverzeichnis (WRKSRC) und das Bauen des Ports
       zusta:ndig. Ist USE_GMAKE gesetzt, so wird GNU make verwendet, sonst
       das System-make.

   Die oben genannten Schritte sind die Standardaktionen. Zusa:tzlich ko:nnen
   Sie pre- irgendwas oder post-irgendwas als Targets definieren oder
   Skripten mit diesen Namen in das scripts-Unterverzeichnis legen. Sie
   werden dann vor bzw. nach den Standardaktionen aufgerufen.

   Angenommen Sie haben das Target post-extract in Ihrem Makefile definiert
   und eine Datei pre-build im scripts Unterverzeichnis, so wird das Target
   post-extract nach dem normalen Entpacken aufgerufen und das Skript
   pre-build ausgefu:hrt, bevor die vordefinierten Bau-Regeln abgearbeitet
   sind. Es wird empfohlen, dass Sie Makefile-Targets verwenden, falls die
   Aktionen es erlauben, da es so fu:r jemanden einfacher sein wird
   herauszufinden, was fu:r eine nicht-standardma:ssige Aktion der Port
   beno:tigt.

   Die Standardaktionen werden aus den Targets bsd.port.mk do-irgendwas
   u:bernommen. Zum Beispiel sind die Befehle zum Entpacken eines Ports im
   Target do-extract zu finden. Falls Sie mit einem vorgegebenen Target nicht
   zufrieden sind, ko:nnen Sie es vera:ndern, indem Sie das Target
   do-irgendwas in Ihrem Makefile neu definieren.

  Anmerkung:

   Die "Haupt"-Targets (z.B. extract, configure usw.) machen nicht mehr als
   sicherzustellen, dass bis hierhin alle Abschnitte abgeschlossen sind, um
   danach die eigentlichen Targets oder Skripte aufzurufen. Und es ist nicht
   beabsichtigt, dass diese gea:ndert werden. Falls Sie das Entpacken
   vera:ndern wollen, vera:ndern Sie do-extract, aber niemals die Art, wie
   extract arbeitet!

   Jetzt, da Sie verstehen, was geschieht, wenn der Benutzer make eingibt,
   lassen Sie uns durch die empfohlenen Schritte gehen, um den perfekten Port
   zu erstellen.

4.2. Den originalen Quelltext besorgen

   Normalerweise liegt der original Quelltext als gepackte Datei (foo.tar.gz
   oder foo.tar.Z) vor. Kopieren Sie diese nach DISTDIR. Nutzen Sie, soweit
   mo:glich, immer die Quellen aus dem Hauptzweig.

   Es ist notwendig die Variable MASTER_SITES anzupassen, um anzugeben, wo
   sich der originale Quelltext befindet. In bsd.sites.mk finden sich
   hilfreiche Definitionen fu:r die gebra:uchlichsten Seiten. Bitte nutzen
   Sie diese Seiten und die zugeho:rigen Definitionen, soweit dies mo:glich
   ist. Damit wird vermieden, immer und immer wieder dieselben Informationen
   zu wiederholen. Da die Hauptseiten regelma:ssig angepasst werden mu:ssen,
   vereinfacht dieses Vorgehen die Pflege der Dateien fu:r jeden Beteiligten.

   Falls keine zuverla:ssige und gut erreichbare FTP/HTTP-Seite zu finden
   ist, oder nur Seiten auffindbar sind, die keinen Standards entsprechen,
   sollte eine Kopie des Quelltextes auf einer zuverla:ssigen Seite abgelegt
   werden. Dies ko:nnte z.B. die eigene Internetseite sein.

   Ist kein geeigneter Ort zum Ablegen des Quelltextes auffindbar, ist es
   mo:glich diesen "intern" auf ftp.FreeBSD.org abzulegen; dies sollte jedoch
   als letzte Mo:glichkeit angesehen werden. Das Distfile muss in diesem Fall
   in ~/public_distfiles/ eines freefall-Accounts abgelegt werden. Bitten Sie
   den Committer Ihres Ports dies zu erledigen. Er wird ausserdem
   MASTER_SITES nach MASTER_SITE_LOCAL und MASTER_SITE_SUBDIR auf den
   freefall-Benutzernamen angepasst.

   Sollte sich das Distfile des Ports regelma:ssig ohne Versionsanpassungen
   des Autors a:ndern, sollte u:berlegt werden, das Disfile auf der eigenen
   Internetseite abzulegen und diese in der Liste der MASTER_SITES an die
   erste Stelle zu setzen. Falls mo:glich, sollte der Autor des Ports gebeten
   werden, dies zu erledigen; hieru:ber wird die Kontrolle des Quelltextes
   verbessert. Wird eine eigene Version des Quelltextes auf eigenen
   Internetseiten verfu:gbar gemacht, verhindert dies Warnungen von checksum
   mismatch und reduziert den Arbeitsaufwand der Maintainer der FTP-Seiten.
   Auch wenn nur eine Quelle fu:r den Quelltext des Ports zur Verfu:gung
   steht, ist es empfohlen, ein Backup auf einer weiteren Seite abzulegen und
   diese als zweiten Eintrag in MASTER_SITES aufzunehmen.

   Sind fu:r den Port zusa:tzlich aus dem Internet verfu:gbare Patches
   erforderlich, sollten diese ebenfalls in DISTDIR abgelegt werden. Sollten
   diese Patches von anderer Quelle als der Hauptseite des Ports stammen, ist
   das kein Grund zur Sorge. Es gibt Wege diesem Umstand gerecht zu werden
   (beachten Sie die unten stehende Beschreibung zu PATCHFILES ).

4.3. Den Port bearbeiten

   Entpacken Sie eine Kopie des Tarballs in ein privates Verzeichnis und
   nehmen Sie alle A:nderungen vor, die no:tig sind, um den Port unter einer
   aktuellen FreeBSD-Version kompilieren zu ko:nnen. Protokollieren Sie
   sorgfa:ltig alle Schritte, die Sie vornehmen, da Sie den Prozess in Ku:rze
   automatisieren werden. Alles, auch das Entfernen, Hinzufu:gen oder
   Bearbeiten von Dateien, sollte von einem automatisierten Skript oder einer
   Patch-Datei machbar sein, wenn Ihr Port fertig ist.

   Falls Ihr Port bedeutende Interaktionen/Vera:nderungen durch den Benutzer
   beno:tigt, um ihn zu Kompilieren oder zu Installieren, sollten Sie einen
   Blick auf Larry Walls klassische Configure-Skripte werfen oder vielleicht
   etwas A:hnliches selbst erstellen. Das Ziel der Ports-Sammlung ist es,
   jeden Port so "plug-and-play-fa:hig" wie mo:glich fu:r den Endbenutzer zu
   machen, wa:hrend ein Minimum an Speicherplatz gebraucht wird.

  Anmerkung:

   Solange nicht anders angegeben wird von Patch-Dateien, Skripten und
   anderen Dateien, die Sie erstellt und der FreeBSD Ports-Sammlung
   hinzugefu:gt haben, angenommen, dass Sie unter den standardma:ssigen
   BSD-Copyright-Bedingungen stehen.

4.4. Fehlerbehebung (Patches)

   Bei der Vorbereitung eines Ports ko:nnen die Dateien, die hinzugefu:gt
   oder vera:ndert wurden, mittels diff(1) abgefangen werden, um Sie spa:ter
   an patch(1) zu u:bergeben. Jeder Patch, der dem Quelltext u:bergeben
   werden soll, sollte in einer Datei patch-* abgelegt werden, wobei * dem
   Pfadnamen der zu korrigierenden Datei entspricht, wie er auch in
   patch-Imakefile oder im patch-src-config.h erscheint. Diese Dateien
   sollten in PATCHDIR (normalerweise files) abgelegt sein, von wo sie
   automatisch u:bernommen werden. Alle Patches mu:ssen sich relativ zur
   WRKSRC-Variable (normalerweise dem Verzeichnis, in dem sich der Quelltext
   des Ports entpackt und wo auch der Bau stattfindet) befinden.

   Um Korrekturen und Updates zu vereinfachen, sollte es vermieden werden,
   mehr als einen Patch fu:r eine Datei zu nutzen (z.B. patch-file und
   patch-file2, welche beide WRKSRC/foobar.c vera:ndern). Beachten Sie, dass,
   falls der Pfad einer zu korrigierenden Datei einen Unterstrich (_)
   entha:lt, der Patch stattdessen zwei Unterstriche im Namen haben muss. Zum
   Beispiel muss der Patch, der eine Datei namens src/freeglut_joystick.c
   korrigieren soll, patch-src-freeglut__joystick.c genannt werden.

   Fu:r die Benennung der Patches sollten nur die Zeichen [-+._a-zA-Z0-9]
   genutzt werden. Bitte verwenden Sie keine weiteren Zeichen als die
   angegebenen. Die Namensvergabe sollte nicht patch-aa oder patch-ab etc.
   entsprechen, erwa:hnen Sie immer den Pfad und Dateinamen.

   RCS-Zeichenketten sollten vermieden werden, da CVS diese verstu:mmeln
   wu:rde, sobald wir diese Dateien in die Ports-Sammlung einpflegen. Wenn
   wir die Dateien wieder abrufen wa:ren diese vera:ndert und der Patch
   wu:rde fehlschlagen. RCS-Zeichenketten sind in Dollar-Zeichen ($)
   eingefu:gte Zeichen und beginnen u:blicherweise mit $Id oder $RCS.

   Die Option rekursiv (-r) zu nutzen diff(1), um Patches zu erstellen, ist
   zula:ssig, jedoch sollte der Patch anschliessend gepru:ft werden, um
   Unno:tiges aus dem Patch zu entfernen. Im Einzelnen bedeutet dies, dass
   Diffs zwischen zwei Backup-Dateien, Makefiles oder wenn der Port Imake
   oder GNU configure usw. nutzt, u:berflu:ssig sind und entfernt werden
   sollten. Falls es es notwendig war, configure.in zu bearbeiten und es soll
   autoconf zum Neuerstellen von configure genutzt werden, sollten die Diffs
   aus configure nicht genutzt werden (diese werden oft einige tausend Zeilen
   gross!); - hier sollte USE_AUTOTOOLS=autoconf:261 definiert und das Diff
   aus configure.in genutzt werden.

   Zusa:tzlich sollte man unno:tige Markup-A:nderungen in Patches/A:nderungen
   mo:glichst vermeiden. In der Open Source-Welt teilen sich Projekte ha:ufig
   grosse Teile des Quellcodes. Allerdings verwenden die einzelnen Projekte
   oft unterschiedliche Programmierstile und Vorgaben fu:r Einru:ckungen.
   Wenn man also einen funktionierenden Teil einer Funktion aus einem Projekt
   verwendet, um ein a:hnliches Problem in einem anderen Projekt zu lo:sen,
   sollte man besonders vorsichtig sein, weil sich ansonsten die
   CVS-A:nderungseintra:ge mit u:berflu:ssigen Eintra:gen fu:llen, die nur
   das Markup des Quellcodes betreffen, ohne dass sich an der Funktion des
   eigentlichen Quellcode etwas a:ndert ("withspace-only changes"). Solche
   A:nderungen vergro:ssern nicht nur das CVS-Repository, sondern erschweren
   es auch die Ursache fu:r eventuell auftretende Probleme zu finden.

   War es notwendig eine Datei zu entfernen, wird dies besser mittels des
   post-extract-Targets als u:ber den Patch selbst realisiert.

   Ein einfacher Austausch kann direkt u:ber das Makefile des Ports umgesetzt
   werden, indem der in-place-Modus von sed(1) genutzt wird. Dies ist sehr
   hilfreich, wenn variable Werte korrigiert werden sollen. Beispiel:

 post-patch:
       @${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g' ${WRKSRC}/README
           @${REINPLACE_CMD} -e 's|-pthread|${PTHREAD_LIBS}|' ${WRKSRC}/configure
      

   Relativ ha:ufig ergibt sich die Situation, in der die portierte Software
   die CR/LF-Konventionen fu:r Zeilenenden nutzt (dies ist bei unter
   Windows(R) entwickelter Software ha:ufig der Fall). Dies kann bei weiteren
   Patches Probleme (Compiler-Warnungen, Fehlermeldungen bei der Ausfu:hrung
   von Skripten wie z.B. /bin/sh^M not found) und anderes ergeben. Um schnell
   alle Dateien von CR/LF nach LF zu konvertieren, kann USE_DOS2UNIX=yes in
   das Makefile des Ports geschrieben werden. Hierzu kann eine Liste der zu
   konvertierenden Dateien erstellt werden:

 USE_DOS2UNIX=    util.c util.h

   Sollen Gruppen von Dateien u:ber verschiedene Unterverzeichnisse
   konvertiert werden, kann DOS2UNIX_REGEX genutzt werden, dessen Argumente
   find-kompatible, regula:re Ausdru:cke sind. Mehr zur Formatierung findet
   sich in re_format(7). Diese Option ist beim Konvertieren aller Dateien mit
   definierter Endung, z.B. aller Dateien im Quellcode, wobei bina:re Dateien
   unberu:hrt bleiben, sinnvoll:

 USE_DOS2UNIX=    yes
       DOS2UNIX_REGEX=  .*\.(c|cpp|h)

   Wenn Sie einen Patch zu einer bereits existierenden Datei erstellen
   wollen, ko:nnen Sie von ihr eine Kopie mit der Endung .orig erstellen und
   anschliessend die Originaldatei bearbeiten. Das make-Ziel makepatch fu:hrt
   dann zu einer entsprechenden Patch-Datei im Verzeichnis files des Ports.

4.5. Konfigurieren

   Fu:gen Sie alle zusa:tzlichen Vera:nderungsbefehle Ihrem Skript configure
   hinzu und speichern Sie es im scripts-Unterverzeichnis. Wie vorstehend
   schon erwa:hnt, ko:nnen Sie dies auch mit den Targets Makefile und/oder
   Skripte mit dem Namen pre-configure oder post-configure erledigen.

4.6. Handhabung von Benutzereingaben

   Sollte der Port Eingaben vom Benutzer beno:tigen, muss IS_INTERACTIVE im
   Makefile des Ports gesetzt werden. Dies erlaubt "overnight builds" Ihren
   Port zu u:berspringen, falls der Nutzer die Variable BATCH setzt (setzt
   der Nutzer hingegen die Variable INTERACTIVE, werden nur Ports gebaut, die
   Interaktion vom Nutzer erwarten). Dies erspart den Rechnern, welche
   kontinuierlich Ports bauen, eine Menge Zeit (siehe unten).

   Zudem ist es empfohlen, falls sinnvolle Vorgaben fu:r interaktive Optionen
   gesetzt sind, die PACKAGE_BUILDING-Variable zu pru:fen und das interaktive
   Skript abzuschalten. Dies macht es uns mo:glich, Pakete fu:r CDROMs und
   FTP-Server zu bauen.

                   Kapitel 5. Die Konfiguration des Makefile

   Inhaltsverzeichnis

   5.1. Der originale Quelltext

   5.2. Bezeichnungen

   5.3. Kategorisierung

   5.4. Die Distributionsdateien

   5.5. MAINTAINER

   5.6. COMMENT

   5.7. Abha:ngigkeiten (dependencies)

   5.8. MASTERDIR

   5.9. Manualpages

   5.10. Info-Dateien

   5.11. Makefile-Optionen

   5.12. Die Festlegung des Arbeitsverzeichnisses

   5.13. Konfliktbehandlung

   5.14. Installation von Dateien

   Das Konfigurieren des Makefile ist sehr einfach und wir schlagen vor, dass
   Sie zuna:chst einen Blick auf vorhandene Beispiele werfen. Zusa:tzlich
   gibt es ein 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 Makefile
   erstellen:

5.1. Der originale Quelltext

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

   Im schlimmsten Fall ko:nnen Sie einfach Ihre eigene Vorgabe mittels
   do-extract erzeugen und die Standardvorgabe u:berschreiben; aber dies
   sollte in den wenigsten Fa:llen, wenn u:berhaupt, notwendig sein.

5.2. Bezeichnungen

   Der erste Teil des Makefile beschreibt die Versionsnummer des Ports und
   fu:hrt ihn in der richtigen Kategorie auf.

  5.2.1. PORTNAME und PORTVERSION

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

  5.2.2. PORTREVISION und PORTEPOCH

    5.2.2.1. PORTREVISION

   Die PORTREVISION-Variable ist ein streng monoton wachsender Wert, welcher
   auf 0 zuru:ckgesetzt wird, nachdem PORTVERSION erho:ht wurde (d.h. jedes
   Mal, wenn ein offizielles Release erfolgt). Sie wird an den Namen des
   Pakets angeha:ngt, wenn sie ungleich 0 ist. A:nderungen an PORTREVISION
   werden von automatisierten Werkzeugen (z.B. pkg_version(1)) genutzt, um
   anzuzeigen, dass ein neues Paket verfu:gbar ist.

   PORTREVISION sollte jedes Mal erho:ht werden, wenn eine A:nderung am Port
   erfolgt, die betra:chtliche Auswirkungen auf den Inhalt oder Struktur des
   aus dem Port erzeugten Pakets zur Folge hat.

   Beispiele dafu:r, wann PORTREVISION erho:ht werden sollte:

     * Hinzufu:gen von Patches, welche Sicherheitslu:cken schliessen, Fehler
       beseitigen oder neue Funktionalita:t zum Port hinzufu:gen.

     * A:nderungen am Makefile des Ports, welche compile-time-Optionen
       hinzufu:gen oder entfernen.

     * A:nderungen bezu:glich Packliste oder am Verhalten wa:hrend der
       Installation des Pakets (d.h. A:nderungen an einem Skript, welches
       Ausgangsdaten fu:r das Paket erzeugt, wie z.B. SSH-Hostschlu:ssel).

     * Versionssprung einer Shared-Library, welche eine Abha:ngigkeit dieses
       Ports ist (In diesem Fall wu:rde ein Anwender bei der Installation des
       alten Pakets scheitern, falls er eine neue Version der Abha:ngigkeit
       bereits installiert hat, weil nach der alten Bibliothek libfoo.x
       anstatt nach libfoo.(x+1)) gesucht wird).

     * Schleichende A:nderungen am Distfile, welche bedeutende funktionale
       A:nderungen verursachen, d.h. A:nderungen des Distfile erfordern eine
       Korrektur an distinfo, ohne dass damit zusammenha:ngend die
       PORTVERSION vera:ndert wird, obwohl ein diff -ru zwischen der alten
       und der neuen Version bedeutende Vera:nderungen am Code nachweist.

   Beispiele fu:r A:nderungen, welche keine Erho:hung von PORTREVISION
   erfordern:

     * Stilistische A:nderungen am Grundgeru:st des Ports ohne funktionale
       A:nderungen am daraus resultierenden Paket.

     * A:nderungen an der Variable MASTER_SITES oder andere funktionale
       A:nderungen, welche das resultierende Paket nicht vera:ndern.

     * Marginale Patches am Distfile wie die Korrektur von Tippfehlern,
       welche nicht wichtig genug sind, um dem Benutzer die Bu:rde eines
       Upgrades aufzuerlegen.

     * Build fixes, die ein Paket erst kompilierbar machen, welches ohne
       diese A:nderungen vorher nicht erzeugt werden konnte (solange die
       A: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 erho:hen, wenn das Paket vorher nicht erstellt werden
       konnte.

   Als Faustregel gilt: Stellen Sie sich die Frage, ob die durchgefu:hrte
   A:nderung am Port jedem hilft (entweder aufgrund einer Verbesserung,
   Beseitigung eines Fehlers, oder der Annahme, dass das neue Paket
   u:berhaupt erst funktioniert) und wa:gen Sie es gegen den Umstand ab, dass
   jedermann, der seine Ports-Sammlung regelma:ssig auf dem neuesten Stand
   ha:lt, zu einer Aktualisierung gezwungen wird. Falls Sie die Frage positiv
   beantworten sollten, erho:hen Sie die Variable PORTREVISION.

    5.2.2.2. PORTEPOCH

   Von Zeit zu Zeit geschieht es, dass irgendjemand (Drittanbieter von
   Software oder FreeBSD Ports Committer) etwas Dummes tut und eine Version
   einer Software vero:ffentlicht, deren Versionsnummer niedriger ist als die
   der vorherigen. Ein Beispiel hierfu:r ist ein Port, der von foo-20000801
   auf foo-1.0 gea:ndert wird (der Erstere wird fa:lschlicherweise als neue
   Version behandelt, weil 2000801 ein numerisch gro:sserer Wert ist als 1).

   In Situationen wie diesen sollte die Variable PORTEPOCH erho:ht werden.
   Wenn PORTEPOCH gro:sser als 0 ist, wird sie an den Namen des Pakets
   angeha:ngt, wie in Abschnitt 0 oberhalb bereits beschrieben. PORTEPOCH
   darf niemals verringert oder auf 0 gesetzt werden, weil der Vergleich des
   Pakets mit einem fru:heren Zeitpunkt scheitern wu:rde (d.h. das Paket
   wu: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 gro:sser erkannt, als das
   implizit angenommene Suffix ,0 im fru:heren Paket.

   Das Entfernen oder Zuru:cksetzen von PORTEPOCH fu:hrt zu unendlichem
   A:rger. Wenn Sie die obigen Ausfu:hrungen nicht vollsta:ndig verstanden
   haben, lesen Sie es bitte unbedingt nochmals bis Sie es vollsta:ndig
   verinnerlicht haben, oder fragen Sie vor jeder A:nderung auf den
   Mailinglisten nach!

   Es wird erwartet, dass PORTEPOCH fu:r die weitaus u:berwiegende Zahl der
   Ports nicht verwendet wird und der verantwortungsvolle und vorausschauende
   Umgang mit PORTVERSION macht es meist u:berflu:ssig, falls ein spa:teres
   Release die Versionsstruktur a:ndern sollte. Vorsicht ist geboten, wenn
   ein Release einer Drittanbieter-Software ohne eine offizielle
   Versionsnummer vero: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 fu:hrt, wenn das na:chste
   "offizielle" Release erscheint.

   Wenn z.B. ein Snapshot zum Datum 20000917 vero:ffentlicht wird und die
   vorherige Version der Software war 1.2, dann sollte der Snapshot die
   PORTVERSION 1.2.20000917 oder a:hnlich erhalten und nicht 20000917, damit
   das nachfolgende Release, angenommen 1.3, immer noch einen gro:sseren
   numerischen Wert aufweist.

    5.2.2.3. Beispiel fu:r den Gebrauch von PORTREVISION und PORTEPOCH

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

 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 erho:ht.

 PORTNAME=       gtkmumble
 PORTVERSION=    0.10
 PORTREVISION=   1

   PKGNAME wird zu gtkmumble-0.10_1

   Eine neue Version wird vom Software-Drittanbieter vero: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 spa:t). Da die neue
   Unterversion 2 numerisch kleiner ist als die vorherige Version 10, muss
   PORTEPOCH erho: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 zuru:ckgesetzt (oder aus dem Makefile entfernt).

 PORTNAME=       gtkmumble
 PORTVERSION=    0.2
 PORTEPOCH=      1

   PKGNAME wird zu gtkmumble-0.2,1

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

 PORTNAME=       gtkmumble
 PORTVERSION=    0.3
 PORTEPOCH=      1

   PKGNAME wird zu gtkmumble-0.3,1

  Anmerkung:

   Falls PORTEPOCH mit diesem Upgrade auf 0 zuru:ckgesetzt worden wa:re, dann
   wu:rde jemand, der das Paket gtkmumble-0.10_1 installiert ha: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.

  5.2.3. PKGNAMEPREFIX und PKGNAMESUFFIX

   Zwei optionale Variablen, PKGNAMEPREFIX und PKGNAMESUFFIX, werden
   verknu:pft mit PORTNAME und PORTVERSION, um PKGNAME zu bilden als
   ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION} . Stellen Sie
   bitte unbedingt sicher, dass diese Variablen den Richtlinien fu:r einen
   guten Paketnamen entsprechen. Insbesondere du: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!

  5.2.4. LATEST_LINK

   Die Umgebungsvariable LATEST_LINK wird wa:hrend der Paketerstellung
   verwendet, um einen Kurznamen festzulegen, der danach von pkg_add -r
   genutzt werden kann. Dadurch wird es beispielsweise mo: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 Fa:llen ko:nnen mehrere Versionen einer Applikation
   gleichzeitig in der Ports-Sammlung sein. Das index build- und das package
   build-System mu: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
   Fa:llen sollte die optionale Variable LATEST_LINK auf einen
   unterschiedlichen Wert fu:r alle Ports gesetzt werden mit Ausnahme des
   "Haupt-Ports". Beispiele hierfu:r sind die lang/gcc46 und lang/gcc-Ports
   und die www/apache*-Familie. Wenn Sie die Umgebungsvariable NO_LATEST_LINK
   setzen, wird kein Link erzeugt, was fu:r alle Versionen (aber nicht fu:r
   die "Hauptversion") nu:tzlich sein kann. Beachten Sie bitte, dass die
   Frage der Auswahl der "wichtigsten" Version ("am popula:rsten", "am besten
   Unterstu:tzt", "zuletzt gepatcht" usw.) ausserhalb der Mo:glichkeiten
   dieses Handbuches liegt. Wir sagen Ihnen nur, wie Sie die anderen Ports
   spezifizieren, nachdem Sie den "Haupt-Port" erkoren haben.

  5.2.5. Namensregeln fu:r Pakete

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

   Der Paketname soll aussehen wie
   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.

    1. FreeBSD bemu:ht sich ausserordentlich, die Landessprachen seiner
       Nutzer zu unterstu:tzen. Die language-Variable soll eine Abku:rzung
       mit 2 Buchstaben sein der Sprachen gema:ss ISO-639, falls der Port
       fu:r eine bestimmte Sprache spezifisch ist. Beispiele hierfu:r sind ja
       fu:r Japanisch, ru fu:r Russisch, vi fu:r Vietnamesisch, zh fu:r
       Chinesisch, ko fu:r Koreanisch und de fu:r Deutsch.

       Sollte der Port spezifisch sein fu:r eine gewisse Region innerhalb
       eines Sprachraumes, dann fu:gen Sie bitte auch den La:ndercode mit 2
       Buchstaben hinzu. Beispiele sind en_US fu:r nordamerikanisches
       Englisch und fr_CH fu:r schweizerisches Franzo:sisch.

       Der language-Teil muss in der PKGNAMEPREFIX-Variable gesetzt werden.

    2. Der erste Buchstabe des name-Teils muss kleingeschrieben werden (der
       Rest des Namens kann Grossbuchstaben enthalten. Daher seien Sie bitte
       umsichtig, wenn Sie den Namen einer Software konvertieren, welche
       Grossbuchstaben entha: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.

    3. 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 textproc/libxml2 oder
       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
       www/apache*-Ports. In diesem Falle werden unterschiedliche Versionen
       (und unterschiedliche Indexeintra:ge) unterschieden durch die Werte
       von PKGNAMEPREFIX, PKGNAMESUFFIX und LATEST_LINK.

    4. Falls der Port mit verschiedenen, fest kodierten Vorgaben
       (u: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 hierfu:r sind Papiergro:ssen und Font-Einheiten.

       Der -compiled.specifics-Teil muss in der Variablen PKGNAMESUFFIX
       gesetzt werden.

    5. Die Versionszeichenfolge sollte einen Bindestrich (-) am Schluss haben
       und eine von Punkten getrennte Liste von Integer-Zahlen und
       kleingeschriebenen Buchstaben sein. Es ist nicht zula: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 u:ber keine Haupt- oder Unterversionsnummern verfu:gt.
       Wenn die Versionsbezeichnung der Software Zeichenketten wie "alpha",
       "beta", "rc" oder "pre" entha: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 Vero:ffentlichung auf
       jeden Fall kleiner als yyyy sein wird.

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

 Softwarename   PKGNAMEPREFIX PORTNAME PKGNAMESUFFIX PORTVERSION      Grund      
mule-2.2.2      (leer)        mule     (leer)        2.2.2       Keine A:nderung 
                                                                 erforderlich    
                                                                 keine           
EmiClock-1.0.2  (leer)        emiclock (leer)        1.0.2       Grossbuchstaben 
                                                                 fu:r einzelne   
                                                                 Applikationen   
                                                                 Keine           
rdist-1.3alpha  (leer)        rdist    (leer)        1.3.a       Zeichenketten   
                                                                 wie alpha       
                                                                 erlaubt         
                                                                 keine           
es-0.9-beta1    (leer)        es       (leer)        0.9.b1      Zeichenketten   
                                                                 wie beta        
                                                                 erlaubt         
                                                                 keine           
mailman-2.0rc3  (leer)        mailman  (leer)        2.0.r3      Zeichenketten   
                                                                 wie rc erlaubt  
                                                                 Was sollte denn 
v3.3beta021.src (leer)        tiff     (leer)        3.3         das eigentlich  
                                                                 sein?           
                                                                 Versionsstring  
tvtwm           (leer)        tvtwm    (leer)        pl11        zwingend        
                                                                 erforderlich    
                                                                 Versionsstring  
piewm           (leer)        piewm    (leer)        1.0         zwingend        
                                                                 erforderlich    
                                                                 pl nur erlaubt, 
xvgr-2.10pl1    (leer)        xvgr     (leer)        2.10.1      wenn keine      
                                                                 Versionsnummer  
                                                                 vorhanden       
gawk-2.15.6     ja-           gawk     (leer)        2.15.6      Japanische      
                                                                 Sprachversion   
                                                                 Papergro:sse    
psutils-1.13    (leer)        psutils  -letter       1.13        beim Paketbau   
                                                                 fix kodiert     
                                                                 Paket fu:r 300  
pkfonts         (leer)        pkfonts  300           1.0         DPI             
                                                                 Schriftarten    

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

5.3. Kategorisierung

  5.3.1. CATEGORIES

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

   Diese Liste legt auch fest, an welcher Stelle in der Ports-Sammlung der
   Port eingefu: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 unten fu:r
   weitere Informationen daru:ber, wie man die richtige Kategorie bestimmt.

  5.3.2. Aktuelle Liste der Kategorien

   Hier ist die aktuelle Liste der Kategorien. Die mit einem Asterisk (*)
   bezeichneten sind virtuelle Kategorien, also solche, welche u:ber kein
   eigenes Unterverzeichnis in der Ports-Sammlung verfu:gen. Sie werden nur
   als Sekunda:rkategorien benutzt und sind nur fu:r Suchzwecke eingerichtet
   worden.

  Anmerkung:

   Fu:r nicht-virtuelle Kategorien finden Sie eine einzeilige Beschreibung in
   der Variable COMMENT im Makefile des jeweiligen Unterverzeichnisses.

     Kategorie            Beschreibung                    Anmerkung           
   accessibility Ports fu:r behinderte                                        
                 Menschen.                      
   afterstep*    Ports fu:r den AfterStep                                     
                 Window Manager.                
   arabic        Arabische                                                    
                 Sprachunterstu:tzung.          
   archivers     Archivierungswerkzeuge.                                      
   astro         Ports fu:r Astronomie.                                       
   audio         Sound-Unterstu:tzung.                                        
   benchmarks    Benchmarking-Werkzeuge.                                      
   biology       Software fu:r Biologie.                                      
   cad           CAD-Werkzeuge.                                               
   chinese       Chinesische                                                  
                 Sprachunterstu:tzung.          
   comms         Kommunikationsprogramme.       Hauptsa:chlich Software fu:r  
                                                serielle Schnittstellen.      
   converters    Zeichensatz-Konverter.                                       
   databases     Datenbanken.                                                 
                 Dinge, die vor der Erfindung                                 
   deskutils     des Computers auf dem           
                 Schreibtisch waren.            
                                                Legen Sie keine Bibliotheken  
                                                hier ab, nur weil es          
   devel         Entwicklungs-Werkzeuge.        Bibliotheken sind, es sei     
                                                denn, sie geho:ren wirklich   
                                                nirgendwo anders hin.         
   dns           DNS-bezogene Software.                                       
   docs*         Meta-Ports fu:r die                                          
                 FreeBSD-Dokumentation.         
                                                Spezielle Editoren geho:ren   
                                                in Ihre jeweilige Kategorie,  
   editors       allgemeine Editoren.           (z.B. geho:rt ein             
                                                mathematischer Formeleditor   
                                                in math).                     
   elisp*        Emacs-lisp-Ports.                                            
                                                Terminal-Emulatoren geho:ren  
                                                nicht hierher; X-basierende   
   emulators     Emulatoren fu:r andere         geho:ren zu x11 und           
                 Betriebssysteme.               text-basierende zu comms oder 
                                                misc, abha:ngig von deren     
                                                genauer Funktionalita:t.      
   finance       Finanz-Software und                                          
                 a:hnliches.                    
   french        Franzo:sische                                                
                 Sprachunterstu:tzung.          
                                                Falls Ihr Port sowohl FTP als 
   ftp           FTP Client- und                auch HTTP unterstu:tzt,       
                 Server-Werkzeuge.              stellen Sie ihn in ftp mit    
                                                der Zweitkategorie www.       
   games         Spiele.                                                      
   geography*    geografische Software.                                       
   german        Deutsche Sprachunterstu:tzung.                               
   gnome*        Ports fu:r GNOME                                             
   gnustep*      Software fu:r GNUstep.                                       
   graphics      grafische Werkzeuge.                                         
   hamradio*     Software fu:r Amateurfunk.                                   
   haskell*      Software fu:r die                                            
                 Haskell-Programmiersprache.    
   hebrew        Hebra:ische                                                  
                 Sprachunterstu:tzung.          
   hungarian     Ungarische                                                   
                 Sprachunterstu:tzung.          
   ipv6*         IPv6-bezogene Software.                                      
   irc           Internet Relay Chat                                          
                 (IRC)-Werkzeuge.               
   japanese      Japanische                                                   
                 Sprachunterstu:tzung.          
                                                Die java-Kategorie sollte     
                                                nicht die Einzige fu:r einen  
                                                Port sein mit Ausnahme der    
                 Software fu:r die              direkt nur mit der            
   java          Java(TM)-Programmiersprache.   Programmiersprache            
                                                zusammenha:ngenden            
                                                Applikationen. Porter sollten 
                                                java nicht als Hauptkategorie 
                                                eines Ports wa:hlen.          
   kde*          Ports fu:r das K Desktop                                     
                 Environment (KDE)-Projekt.     
   kld*          Kernelmodule.                                                
   korean        Koreanische                                                  
                 Sprachunterstu:tzung.          
   lang          Programmiersprachen.                                         
   linux*        Linux-Applikationen und                                      
                 -Werkzeuge.                    
   lisp*         Software fu:r die                                            
                 Lisp-Programmiersprache.       
   mail          Mail-Software.                                               
                 Numerische Berechnungen und                                  
   math          andere mathematische            
                 Werkzeuge.                     
   mbone*        MBone-Applikationen.                                         
                                                Hauptsa:chlich Werkzeuge, die 
                                                nicht anderswo hingeho:ren.   
                                                Versuchen Sie, falls irgend   
   misc          Verschiedene Werkzeuge.        mo:glich, eine bessere        
                                                Kategorie fu:r Ihren Port zu  
                                                finden als misc, weil Ports   
                                                hier leicht untergehen.       
   multimedia    Multimedia-Software.                                         
   net           Verschiedene                                                 
                 Netzwerk-Software.             
   net-im        Instant Messaging-Software.                                  
   net-mgmt      Netzwerk-Management-Software.                                
   net-p2p       Peer to                                                      
                 peer-Netzwerkprogramme.        
   news          USENET News-Software.                                        
   palm          Software fu:r Palm(TM).                                      
   parallel*     Applikationen fu:r paralleles                                
                 Rechnen.                       
   pear*         Ports fu:r das Pear                                          
                 PHP-Framework.                 
   perl5*        Ports, welche Perl Version 5                                 
                 beno:tigen.                    
   plan9*        Verschiedene Programme von                                   
                 Plan9.                         
   polish        Polnische                                                    
                 Sprachunterstu:tzung.          
                 Hilfsprogramme fu:r das                                      
   ports-mgmt    Installieren und Entwickeln     
                 von FreeBSD Ports und Paketen. 
   portuguese    Portugiesische                                               
                 Sprachunterstu:tzung.          
                                                Desktop                       
   print         Drucker-Software.              Vero:ffentlichungs-Werkzeuge  
                                                (DTP, Betrachter etc.)        
                                                geho:ren auch hierher.        
   python*       Software fu:r Python.                                        
   ruby*         Software fu:r Ruby.                                          
   rubygems*     Ports fu:r RubyGems-Pakete.                                  
   russian       Russische                                                    
                 Sprachunterstu:tzung.          
   scheme*       Software fu:r die                                            
                 Scheme-Programmiersprache.     
                 Wissenschaftliche Programme,                                 
   science       die in keine andere Kategorie   
                 passen wie z.B. astro, biology 
                 und math.                      
   security      Security-Werkzeuge.                                          
   shells        Shells.                                                      
   spanish*      Spanische                                                    
                 Sprachunterstu:tzung.          
   sysutils      System-Werkzeuge.                                            
   tcl*          Ports, welche Tcl beno:tigen.                                
                                                Dies beinhaltet nicht         
   textproc      Textverarbeitungsprogramme.    DTP-Werkzeuge, diese geho:ren 
                                                in print.                     
   tk*           Ports, welche Tk beno:tigen.                                 
   ukrainian     Ukrainische                                                  
                 Sprachunterstu:tzung.          
   vietnamese    Vietnamesische                                               
                 Sprachunterstu:tzung.          
   windowmaker*  Ports fu:r den WindowMaker                                   
                 Window-Manager.                
   www           Software fu:r das World Wide   HTML-Werkzeuge geho:ren auch  
                 Web (WWW).                     hierher.                      
                                                Diese Kategorie ist nur fu:r  
                                                Software, welche direkt X     
                                                unterstu:tzt. Fu:gen Sie      
                                                keine normalen                
                                                X-Applikationen hinzu. Die    
                                                meisten davon geho:ren in     
   x11           X-Window-System und            eine andere x11-*-Kategorie   
                 dergleichen.                   (siehe unten). Falls Ihr Port 
                                                eine X-Applikation ist, dann  
                                                definieren Sie bitte USE_XLIB 
                                                (impliziert durch USE_IMAKE)  
                                                und fu:gen ihn der            
                                                entsprechenden Kategorie      
                                                hinzu.                        
   x11-clocks    X11-Uhren.                                                   
   x11-drivers   X11-Treiber.                                                 
   x11-fm        X11-Dateimanager.                                            
   x11-fonts     X11-Schriftarten und                                         
                 Werkzeuge.                     
   x11-servers   X11-Server.                                                  
   x11-themes    X11-Themes.                                                  
   x11-toolkits  X11-Toolkits.                                                
   x11-wm        X11-Window-Manager.                                          
   xfce*         Ports in Zusammenhang mit                                    
                 Xfce.                          
   zope*         Zope-Unterstu:tzung.                                         

  5.3.3. Wa:hlen der richtigen Kategorie

   Da viele der Kategorien sich u:berlappen, mu:ssen Sie oft festlegen,
   welches die prima: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 (prima:re) Kategorie muss eine physische (keine virtuelle,
       siehe oben) sein. Dies ist notwendig damit Pakete erstellt werden
       ko:nnen. Die nachfolgenden Kategorien ko: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 japanese x11-fonts enthalten.

     * Spezifische Kategorien werden vor weniger spezifischen Kategorien
       aufgelistet. Ein HTML-Editor sollte z.B. als www editors aufgefu:hrt
       werden und nicht umgekehrt. Genauso sollten Sie keinen Port unter net
       auffu:hren, wenn er zu irc, mail, news, security oder www passt, da
       net in diesen Kategorien bereits implizit eingeschlossen ist.

     * x11 wird nur als sekunda:re Kategorie benutzt, wenn die prima:re
       Kategorie eine sprachspezifische ist. Keinesfalls sollten Sie x11 in
       die Kategorie-Zeile einer X-Applikation setzen.

     * Emacs modes geho:ren in die gleiche Kategorie wie die vom jeweiligen
       mode unterstu:tzte Applikation und nicht in editors. Ein Emacs mode
       z.B. fu:r das Editieren von Quelltext einer bestimmten
       Programmiersprache geho:rt zur Kategorie lang.

     * Fu:r Ports, die vom Benutzer ladbare Kernelmodule installieren, sollte
       die virtuelle Kategorie kld in die CATEGORIES-Zeile aufgenommen
       werden.

     * 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 ko:nnen!

     * Falls Ihr Port wirklich in keine andere Kategorie passt, verwenden Sie
       bitte misc.

   Falls Sie sich u:ber die Kategorie im Unklaren sind, hinterlassen Sie
   bitte einen Kommentar in Ihrem per send-pr(1) eingereichten Bericht, damit
   wir diese Frage vor dem Import diskutieren ko:nnen. Falls Sie ein
   Committer sind, schicken Sie bitte eine Nachricht an FreeBSD ports, damit
   die Frage im Vorhinein ero:rtert werden kann. Neue Ports werden zu ha:ufig
   falsch kategorisiert und werden sofort wieder verschoben. Das bla:ht das
   Master Source Repository unno:tig auf.

  5.3.4. Eine neue Kategorie vorschlagen

   Da die Ports-Sammlung u:ber viele Jahre gewachsen ist, wurden viele neue
   Kategorien hinzugefu:gt. Neue Kategorien ko:nnen virtuell (ohne eigenes
   Unterverzeichnis in der Ports-Sammlung) oder physisch sein. Der
   nachfolgende Text fu:hrt einige Punkte auf, welche bei der Neueinfu:hrung
   einer physischen Kategorie beachtet werden mu:ssen, damit Sie dies bei
   einem eventuellen Vorschlag Ihrerseits beru:cksichtigen ko:nnen.

   Unsere bestehende Maxime ist die Vermeidung der Neuanlage von physischen
   Kategorien, solange nicht eine grosse Zahl von Ports zugeordnet werden
   ko:nnen oder falls ihr nicht Ports zugeho:ren wu:rden, welche eine logisch
   abgegrenzte Gruppe von limitiertem o:ffentlichem Interesse zugeho:ren
   wu:rden (zum Beispiel neue Sprachkategorien) oder vorzugsweise beides.

   Die Erkla:rung dafu:r ist, dass eine Neuanlage einer physischen Kategorie
   einen erheblichen Arbeitsaufwand sowohl fu:r die Committer als auch
   diejenigen Nutzer bedeutet, welche die A:nderungen der Ports-Sammlung
   nachvollziehen. Zusa:tzlich verursachen Vorschla:ge fu:r neue Kategorien
   oftmals Kontroversen (natu:rlich deswegen, weil es keinen klaren Konsens
   daru:ber gibt, welche Kategorie als "zu gross" betrachtet werden muss noch
   ob sich bestimmte Kategorien zur einfachen Suche eignen (und wie viele
   Kategorien u:berhaupt ideal wa:ren) und so weiter).

   Hier ist das Prozedere:

    1. Schlagen Sie die neue Kategorie auf FreeBSD ports vor. Sie sollten
       eine detaillierte Begru:ndung fu:r die neue Kategorie beifu:gen
       einschliesslich einer Erkla:rung, warum Sie meinen, die existierenden
       Kategorien seien nicht ausreichend. Zeigen Sie ausserdem eine Liste
       der zu verschiebenden Ports (falls neue Ports in GNATS auf ihren
       commit warten, die in diese Kategorie passen wu:rden. Listen Sie diese
       bitte auch mit auf). Sind Sie der Maintainer oder Einreicher dieser
       Ports, erwa:hnen Sie es bitte. Es verleiht Ihrem Vorschlag mehr
       Gewicht.

    2. Nehmen Sie an der Diskussion teil.

    3. Falls es Unterstu:tzung fu:r Ihren Vorschlag geben sollte, reichen Sie
       bitte einen PR ein, welcher die Begru:ndung und die Liste der
       betroffenen Ports entha:lt, die verschoben werden mu:ssen.
       Idealerweise sollte der PR Patches fu:r Folgendes enthalten:

          * Makefiles fu:r die neuen Ports nach dem Repocopy

          * Makefile fu:r die neue Kategorie

          * Makefile fu:r die alten Kategorien der betroffenen Ports

          * Makefiles fu:r Ports, welche von den alten Ports abha:ngen

          * Fu:r zusa:tzliches Ansehen sorgen Sie, wenn Sie die anderen
            Dateien, die gea:ndert werden mu:ssen, beifu:gen wie in der
            Direktive des Committer's Guide beschrieben.

    4. Da es die Ports-Infrastruktur beeinflusst und nicht nur die
       Durchfu:hrung von Repocopies und mo:glicherweise sogar
       Regressionstests auf dem Build Cluster durchgefu:hrt werden mu:ssen,
       sollte der PR dem Ports Management Team Ports Management Team
       <portmgr@FreeBSD.org> zugeordnet werden.

    5. Sobald der PR besta:tigt wurde muss ein Committer den Rest der
       Prozedur durchfu:hren, welche im Committers Guide beschrieben ist.

   Das Vorschlagen einer neuen virtuellen Kategorie ist a:hnlich, aber
   wesentlich weniger aufwendig, weil keine Ports verschoben werden mu:ssen.
   In diesem Falle mu:ssen nur die Patches an den PR beigefu:gt werden,
   welche die neue Kategorie zur Variable CATEGORIES der betroffenen Ports
   hinzufu:gen.

  5.3.5. Vorschlagen einer Neuorganisation aller Kategorien

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

5.4. Die Distributionsdateien

   Der zweite Teil des Makefile beschreibt die Dateien, welche
   heruntergeladen werden mu:ssen, um den Port zu bauen und wo diese Dateien
   zu finden sind.

  5.4.1. DISTVERSION/DISTNAME

   DISTNAME ist der Name der Applikation wie er von den Autoren vergeben
   wurde. DISTNAME hat als Vorgabe ${PORTNAME}-${PORTVERSION} also
   u: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
   work/${DISTNAME} ist.

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

                DISTVERSION                          PORTVERSION              
   0.7.1d                                0.7.1.d                              
   10Alpha3                              10.a3                                
   3Beta7-pre2                           3.b7.p2                              
   8:f_17                                8f.17                                

  Anmerkung:

   PKGNAMEPREFIX und PKGNAMESUFFIX beeinflussen DISTNAME nicht. Beachten Sie
   bitte auch, dass Sie DISTNAME unvera:ndert lassen sollten, falls WRKSRC
   denselben Wert hat wie 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 mo:glicherweise EXTRACT_SUFX) zu
   setzen.

  5.4.2. 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 Schra:gstrich (/) am Ende!

   Die make-Makros werden versuchen, diese Festlegung fu: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 aufzufu:hren,
   vorzugsweise auf verschiedenen Kontinenten. Dies ist ein Schutz gegen
   Probleme bei gro:sseren Ausfa:llen im Internet. Wir planen sogar
   Unterstu:tzung einzubauen, die automatisch einen Server in der Na:he zum
   Herunterladen bestimmt. Die Verfu:gbarkeit von vielen Webseiten wird
   dieses Vorhaben betra:chtlich erleichtern.

   Falls der originale Tarball Teil eines popula:ren Archivs ist, wie
   SourceForge, GNU oder Perl CPAN, ko:nnen Sie mo: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:

 MASTER_SITES=         ${MASTER_SITE_GNU}
 MASTER_SITE_SUBDIR=   make

   Oder verwenden Sie ein kondensiertes Format:

 MASTER_SITES=   GNU/make

   Diese Variablen werden in /usr/ports/Mk/bsd.sites.mk definiert. Es werden
   sta:ndig neue Eintra:ge hinzugefu:gt, daher stellen Sie bitte unbedingt
   sicher, dass Sie die neueste Version verwenden, bevor Sie einen Port
   einschicken.

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

 MASTER_SITES=   SF

   Ist das Ergebnis nicht korrekt, ko:nnen Sie diesen Wert auch
   u:berschreiben.

 MASTER_SITES=   SF/stardict/WyabdcRealPeopleTTS/${PORTVERSION}

   Tabelle 5.1. Beliebte magic MASTER_SITES-Makros

    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}                            

  5.4.3. EXTRACT_SUFX

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

   Ist die Distributionsdatei zum Beispiel im Stil von foo.tgz anstatt des
   normalen foo.tar.gz benannt, wu:rden Sie schreiben:

 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.

  Anmerkung:

   Sie mu:ssen niemals beide Variablen EXTRACT_SUFX und DISTFILES setzen.

  5.4.4. DISTFILES

   Manchmal haben die zu ladenden Dateien keinerlei A:hnlichkeit mit dem
   Namen des Ports. Es ko:nnte z.B. source.tar.gz oder a:hnlich heissen. In
   anderen Fa:llen ko:nnte der Quelltext in mehreren Archiven sein und alle
   mu:ssen heruntergeladen werden.

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

 DISTFILES=     source1.tar.gz source2.tar.gz

   Wenn nicht ausdru:cklich gesetzt, verwendet DISTFILES als Vorgabe
   ${DISTNAME}${EXTRACT_SUFX}.

  5.4.5. EXTRACT_ONLY

   Falls nur einige der DISTFILES extrahiert werden mu: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.

 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.

 EXTRACT_ONLY=

  5.4.6. PATCHFILES

   Falls Ihr Port zusa:tzliche Patches beno:tigt, welche per FTP oder HTTP
   verfu:gbar sind, dann setzen Sie PATCHFILES auf den Namen der Dateien und
   PATCH_SITES auf die URL des Verzeichnisses, das diese Patches entha:lt
   (das Format ist das gleiche wie MASTER_SITES).

   Falls ein Patch wegen einiger zusa: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 zusa:tzliches foozolix-1.0/ vor ihren Dateinamen aufweisen, dann
   setzen Sie bitte PATCH_DIST_STRIP=-p1.

   Ku:mmern Sie sich nicht darum, ob die Patches komprimiert sind. Sie werden
   automatisch dekomprimiert, wenn die Dateinamen auf .gz oder .Z enden.

   Falls der Patch zusammen mit anderen Dateien in einem gezippten Tarball
   verteilt wird (z.B. mit Dokumentation), dann ko:nnen Sie nicht PATCHFILES
   verwenden. In diesem Fall fu: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 bsd.port.mk
   wird automatisch diese Dateien nutzen. Kopieren Sie niemals Patch-Dateien
   in das PATCHDIR-Verzeichnis, weil es mo:glicherweise nicht beschreibbar
   ist.

  Anmerkung:

   Der Tarball wird zusammen mit dem anderen Quelltext extrahiert werden.
   Eine ausdru: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 u:berschreiben, was
   bereits im Verzeichnis vorhanden ist. Vergessen Sie auch nicht den
   kopierten Patch im Target von pre-clean zu entfernen.

  5.4.7. Verschiedene Distributionsdateien oder Patches von verschiedenen Seiten
  und Verzeichnissen (MASTER_SITES:n)

   (Betrachten Sie es als in irgendeiner Form "fortgeschrittenes Thema".
   Neulinge sollten mo:glicherweise diesen Abschnitt beim ersten Lesen
   u:berspringen).

   Dieser Abschnitt stellt Informationen u:ber die Mechanismen zum
   Herunterladen von Dateien zur Verfu: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 verfu:gt u:ber eine sehr
   elegante Option innerhalb der Variablen DISTFILES und PATCHFILES. Sowohl
   Dateien als auch Patches ko:nnen mit angeha:ngten :n-Bezeichnern versehen
   werden wobei n in beiden Fa:llen [0-9] sein kann und eine
   Gruppenzugeho:rigkeit anzeigt. Ein Beispiel hierfu:r ist:

 DISTFILES=      alpha:0 beta:1

   In OpenBSD wird die Datei alpha mit der Variable MASTER_SITES0 verknu:pft
   anstatt dem in FreeBSD gebra:uchlichen MASTER_SITES und beta mit
   MASTER_SITES1.

   Das ist eine sehr interessante Mo:glichkeit, die endlose Suche nach der
   richtigen Download-Seite zu verku:rzen.

   Stellen Sie sich zwei Dateien in DISTFILES und 20 Webseiten in der
   Variable MASTER_SITES vor. Alle Seiten sind erschreckend langsam, beta
   findet sich auf allen Seiten in MASTER_SITES und alpha kann nur auf der
   zwanzigsten Seite gefunden werden. Wa:re es nicht reine Verschwendung,
   wenn der Maintainer alle Seiten zuvor u:berpru:fen mu:sste? Kein guter
   Start fu:r das wundervolle Wochenende!

   U:bertragen Sie diesen Umstand auf noch mehr DISTFILES und mehr
   MASTER_SITES. Ganz sicher wu:rde unser "distfiles survey master" die
   Erleichterung sehr zu scha:tzen wissen, die eine solche Verringerung der
   Netzwerkbelastung bringen wu:rde.

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

    5.4.7.1. 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 fu:r die
   meisten Szenarien ausreichend. Falls Sie weitere Informationen beno:tigen,
   sollten Sie den na:chsten Abschnitt lesen.

   Einige Programme bestehen aus mehreren Dateien, welche von verschiedenen
   Webseiten heruntergeladen werden mu:ssen. Zum Beispiel besteht Ghostscript
   aus dem Kern des Programms und einer grossen Zahl von Treiberdateien, die
   vom Drucker des Benutzers abha:ngen. Einige dieser Treiberdateien werden
   mit der Kernapplikation mitgeliefert aber viele mu:ssen von verschiedenen
   Webseiten heruntergeladen werden.

   Um das zu unterstu:tzen, muss jeder Eintrag in DISTFILES mit einem Komma
   und einem "tag name" abgeschlossen werden. Jeder in MASTER_SITES
   aufgefu: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, source1.tar.gz und source2.tar.gz, welche von zwei
   verschiedenen Webseiten heruntergeladen werden mu:ssen. Das Makefile des
   Port wu:rde Zeilen enthalten wie in Beispiel 5.1, "Vereinfachtes Beispiel
   fu:r den Gebrauch von MASTER_SITES:n mit einer Datei pro Webseite".

   Beispiel 5.1. Vereinfachtes Beispiel fu:r den Gebrauch von MASTER_SITES:n
   mit einer Datei pro Webseite

 MASTER_SITES=   ftp://ftp.example1.com/:source1 \
         ftp://ftp.example2.com/:source2
 DISTFILES=      source1.tar.gz:source1 \
         source2.tar.gz:source2

   Verschiedene Dateien ko:nnen die gleiche Marke aufweisen. Ausgehend vom
   vorherigen Beispiel nehmen wir an, dass es noch eine dritte Datei gibt
   (source3.tar.gz), welche von ftp.example2.com heruntergeladen werden soll.
   Das Makefile wu:rde dann aussehen wie Beispiel 5.2, "Vereinfachtes
   Beispiel fu:r den Gebrauch von MASTER_SITES:n mit mehr als einer Datei pro
   Webseite".

   Beispiel 5.2. Vereinfachtes Beispiel fu:r den Gebrauch von MASTER_SITES:n
   mit mehr als einer Datei pro Webseite

 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

    5.4.7.2. Ausfu:hrliche Information

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

    1. Elemente ko:nnen nachstehend bezeichnet werden mit :n wobei n in
       diesem Falle [^:,]+ ist. Das heisst n ko:nnte theoretisch jede
       alphanumerische Zeichenkette sein, aber wir beschra:nken sie auf
       [a-zA-Z_][0-9a-zA-Z_]+ fu:r diesen Moment.

       Zudem ist die Zeichenkette case sensitive; d.h. n unterscheidet sich
       von N.

       Allerdings du:rfen die folgenden Wo:rter nicht gebraucht werden, da
       sie spezielle Bedeutungen haben: default, all und ALL (diese Wo:rter
       werden intern genutzt in Punkt ii). Ausserdem ist DEFAULT ein
       reserviertes Wort (beachten Sie 3).

    2. Elemente mit angeha:ngtem :n geho:ren zur Gruppe n, :m geho:rt zur
       Gruppe m und so weiter.

    3. Elemente ohne Anha:ngsel sind gruppenlos, d.h. sie geho:ren alle zu
       der speziellen Gruppe DEFAULT. Falls sie an irgendeinem Element
       DEFAULT ha:ngen, ist dies u:berflu:ssig, es sei denn Sie wollen, dass
       ein Element sowohl zu DEFAULT als auch anderen Gruppen gleichzeitig
       geho:rt (beachten Sie 5).

       Die folgenden Beispiele sind gleichwertig, aber das erste Beispiel ist
       vorzuziehen:

 MASTER_SITES=   alpha

 MASTER_SITES=   alpha:DEFAULT

    4. Gruppen sind nicht ausschliessend, d.h. ein Element kann mehreren
       Gruppen gleichzeitig angeho:ren und eine Gruppe wiederum kann entweder
       mehrere Elemente oder u:berhaupt keine aufweisen. Wiederholte Elemente
       sind schlicht nur wiederholte Elemente.

    5. Wenn Sie wollen, dass ein Element gleichzeitig zu mehreren Gruppen
       geho:rt, dann ko:nnen Sie diese durch ein Komma (,) trennen.

       Anstatt jedes Mal ein anderes Anha:ngsel zu verwenden und
       Wiederholungen aufzufu:hren, ko:nnen Sie mehrere Gruppen auf einmal in
       einem einzigen Anha:ngsel bestimmen. Zum Beispiel markiert :m,n,o ein
       Element, welches zu den Gruppen m, n und o geho:rt.

       Alle folgenden Beispiele sind gleichwertig, aber das erste Beispiel
       ist vorzuziehen:

 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

    6. Alle Webseiten in einer Gruppe werden gema:ss MASTER_SORT_AWK
       sortiert. Alle Gruppen innerhalb von MASTER_SITES und PATCH_SITES
       werden genauso sortiert.

    7. 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:

         a. Elemente mit MASTER_SITES, PATCH_SITES, MASTER_SITE_SUBDIR und
            PATCH_SITE_SUBDIR mu:ssen mit einem Schra:gstrich beendet werden
            ( /). Falls Elemente zu irgendwelchen Gruppen geho:ren, muss :n
            direkt nach dem Trenner / stehen. Der MASTER_SITES:n-Mechanismus
            verla:sst sich auf das Vorhandensein des Trennzeichens /, um
            verwirrende Elemente zu vermeiden in denen :n ein zula:ssiger
            Bestandteil des Elementes ist und das Auftreten von :n die Gruppe
            n anzeigt. Aus Kompatibilita:tsgru:nden (da der /-Trenner sowohl
            in MASTER_SITE_SUBDIR als auch PATCH_SITE_SUBDIR-Elementen nicht
            erforderlich ist) wird, falls das auf das Anha:ngsel folgende
            na:chste Zeichen kein / ist, auch :n als gu:ltiger Teil des
            Elementes behandelt anstatt als Gruppenzusatz, selbst wenn ein
            Element ein angeha:ngtes :n aufweist. Beachten Sie sowohl
            Beispiel 5.3, "Ausfu:hrliches Beispiel von MASTER_SITES:n in
            MASTER_SITE_SUBDIR" als auch Beispiel 5.4, "Ausfu:hrliches
            Beispiel von MASTER_SITES:n mit Komma-Operator, mehreren Dateien,
            mehreren Webseiten und mehreren Unterverzeichnissen".

            Beispiel 5.3. Ausfu:hrliches Beispiel von MASTER_SITES:n in
            MASTER_SITE_SUBDIR

 MASTER_SITE_SUBDIR=     old:n new/:NEW

               * Verzeichnisse innerhalb der Gruppe DEFAULT -> old:n

               * Verzeichnisse innerhalb der Gruppe NEW -> new

            Beispiel 5.4. Ausfu:hrliches Beispiel von MASTER_SITES:n mit
            Komma-Operator, mehreren Dateien, mehreren Webseiten und mehreren
            Unterverzeichnissen

 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 fu:hrt zu einem fein granulierten
            Herunterladen. Die Webseiten werden in der exakten Reihenfolge
            ihrer Nutzung aufgelistet.

               * 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

               * file2 wird genauso heruntergeladen wie file1, da sie zur
                 gleichen Gruppe geho:ren

                    * MASTER_SITE_OVERRIDE

                    * http://site1/directory-trial:1/

                    * http://site1/directory-one/

                    * http://site1/directory/

                    * http://site2/

                    * http://site7/

                    * MASTER_SITE_BACKUP

               * file3 wird heruntergeladen von

                    * MASTER_SITE_OVERRIDE

                    * http://site3/

                    * MASTER_SITE_BACKUP

               * file4 wird heruntergeladen von

                    * MASTER_SITE_OVERRIDE

                    * http://site4/

                    * http://site5/

                    * http://site6/

                    * http://site7/

                    * http://site8/directory-one/

                    * MASTER_SITE_BACKUP

               * file5 wird heruntergeladen von

                    * MASTER_SITE_OVERRIDE

                    * MASTER_SITE_BACKUP

               * file6 wird heruntergeladen von

                    * MASTER_SITE_OVERRIDE

                    * http://site8/

                    * MASTER_SITE_BACKUP

    8. Wie gruppiere ich eine der speziellen Variablen aus bsd.sites.mk, d.h.
       MASTER_SITE_SOURCEFORGE?

       Lesen Sie Beispiel 5.5, "Ausfu:hrliches Beispiel von MASTER_SITES:n
       mit MASTER_SITE_SOURCEFORGE".

       Beispiel 5.5. Ausfu:hrliches Beispiel von MASTER_SITES:n mit
       MASTER_SITE_SOURCEFORGE

 MASTER_SITES=   http://site1/ ${MASTER_SITE_SOURCEFORGE:S/$/:sourceforge,TEST/}
 DISTFILES=      something.tar.gz:sourceforge

       something.tar.gz wird von allen Webseiten innerhalb von
       MASTER_SITE_SOURCEFORGE heruntergeladen.

    9. 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
       Beispiel 5.6, "Vereinfachte Nutzung von MASTER_SITES:n mit
       PATCH_SITES.". sehen ko:nnen.

       Beispiel 5.6. Vereinfachte Nutzung von MASTER_SITES:n mit PATCH_SITES.

 PATCH_SITES=    http://site1/ http://site2/:test
 PATCHFILES=     patch1:test

    5.4.7.3. Was a:ndert sich fu:r die Ports? Was a:ndert sich nicht?

   i. Alle bestehenden Ports bleiben gleich. Der Code fu:r MASTER_SITES:n
      wird nur aktiviert, falls es Elemente mit angeha:ngtem :n entsprechend
      den zuvor erwa:hnten Syntax-Regeln wie in 7 gezeigt gibt.

   ii. 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 Beispiel 5.4, "Ausfu:hrliches Beispiel von
            MASTER_SITES:n mit Komma-Operator, mehreren Dateien, mehreren
            Webseiten und mehreren Unterverzeichnissen".

          * 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 a:lteren
            Versionen) geben nur die Elemente der Gruppe DEFAULT zuru:ck.
            Beziehungsweise sie fu: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 U:berpru:fung
            von MASTER_SITES oder PATCH_SITES vorzuziehen. Zudem ist nicht
            garantiert, dass das direkte U:berpru:fen in zuku:nftigen
            Versionen funktionieren wird. Sehen Sie B fu:r weitere
            Informationen zu diesen neuen Port-Targets.

   iii. Neue Port-Targets

          A. 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. zuru:ckgeben.

          B. Es gibt das neue Target master-sites-all und patch-sites-all,
             welche die Arbeit der alten Targets master-sites und patch-sites
             u:bernehmen. Sie geben die Elemente aller Gruppen zuru:ck,als
             wu:rden sie zur gleichen Gruppe geho: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 fu:r
             master-sites-all und patch-sites-all.

  5.4.8. DIST_SUBDIR

   Verhindern Sie, dass Ihr Port das Verzeichnis /usr/ports/distfiles in
   Unordnung bringt. Falls Ihr Port eine ganze Reihe von Dateien
   herunterladen muss oder eine Datei entha:lt, die einen Namen hat, der
   mo:glicherweise mit anderen Ports in Konflikt stehen ko:nnte
   (d.h.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 /usr/ports/distfiles auf
   /usr/ports/distfiles/DIST_SUBDIR a:ndern und stellt tatsa:chlich alle fu:r
   Ihren Port beno:tigten Dateien in dieses Unterverzeichnis.

   Es wird zusa:tzlich nach dem Unterverzeichnis mit dem gleichen Namen auf
   der Sicherung der Hauptseite auf ftp.FreeBSD.org suchen (das
   ausdru:ckliche Setzen von DISTDIR in Ihrem Makefile wird dies nicht
   gewa:hrleisten, also nutzen Sie bitte DIST_SUBDIR).

  Anmerkung:

   Dies hat keine Auswirkungen auf die Variable MASTER_SITES, die Sie in
   Ihrem Makefile definieren.

  5.4.9. ALWAYS_KEEP_DISTFILES

   Falls Ihr Port bina:re Distfiles benutzt und eine Lizenz aufweist, die
   verlangt, dass das der Quelltext in Form bina: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 beno:tigen generell diese Dateien nicht, daher ist es ein gutes
   Konzept, nur dann die Distfiles zu DISTFILES hinzuzufu:gen, wenn
   PACKAGE_BUILDING definiert ist.

   Beispiel 5.7. Nutzung von ALWAYS_KEEP_DISTFILES.

 .if defined(PACKAGE_BUILDING)
 DISTFILES+=             foo.tar.gz
 ALWAYS_KEEP_DISTFILES=  yes
 .endif

   Wenn Sie zusa:tzliche Dateien zu DISTFILES hinzufu:gen, dann beachten Sie
   bitte, dass Sie diese auch in distinfo auffu:hren. Zudem werden die
   zusa:tzlichen Dateien normalerweise ebenso in WRKDIR extrahiert, was fu:r
   einige Ports zu unbeabsichtigten Seiteneffekten fu:hren mag und spezielle
   Behandlung erfordert.

5.5. MAINTAINER

   Fu:gen Sie hier Ihre E-Mailadresse ein. Bitte. :-)

   Beachten Sie bitte, dass nur eine einzelne E-Mailadresse ohne Kommentar in
   der Variable MAINTAINER zula:ssig ist. Das Format sollte
   user@hostname.domain sein. Bitte fu:gen Sie keinen beschreibenden Text wie
   z.B. Ihren wirklichen Namen ein, dies verwirrt lediglich bsd.port.mk.

   Der Maintainer ist dafu:r verantwortlich, dass der Port aktuell gehalten
   wird und er sorgt dafu:r, dass der Port korrekt arbeitet. Fu:r eine
   detaillierte Beschreibung der Verantwortlichkeiten eines Maintainers
   beachten Sie bitte den Abschnitt Die Herausforderung fu:r einen
   Port-Maintainer.

   A: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
   o:ffentliche Feiertage) zustimmt, dann wird dies als Maintainer-Timeout
   betrachtet und eine Aktualisierung kann ohne ausdru: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 Ports Management Team
   <portmgr@FreeBSD.org> oder das Security Officer Team
   <security-officer@FreeBSD.org> betreut wird. Es du:rfen niemals committs
   ohne vorherige Zustimmung an solchen Ports vorgenommen werden!

   Wir behalten uns das Recht vor, die Einreichungen eines Maintainers ohne
   ausdru:ckliche Zustimmung zu a:ndern, falls wir der Auffassung sind, dass
   dadurch die Einhaltung von Richtlinien und stilistischen Vorgaben fu:r die
   Ports-Sammlung besser erfu:llt wird. Zudem ko:nnen gro:ssere A:nderungen
   an der Infrastruktur der Ports zu A:nderungen an einem bestimmten Port
   ohne Zustimmung des Maintainers fu:hren. Diese A:nderungen beeinflussen
   niemals die Funktionalita:t eines Ports.

   Das Ports Management Team <portmgr@FreeBSD.org> beha: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
   Team <security-officer@FreeBSD.org> beha:lt sich das Recht vor, jede
   Maintainerschaft aus Sicherheitsgru:nden aufzuheben oder ausser Kraft zu
   setzen.

5.6. COMMENT

   Dies ist eine einzeilige Beschreibung des Ports. Bitte fu:gen Sie nicht
   den Paketnamen (oder die Version der Software) in den Kommentar ein. Der
   Kommentar soll mit einem Grossbuchstaben beginnen und ohne Punkt enden.
   Hier ist ein Beispiel:

 COMMENT=       A cat chasing a mouse all over the screen

   Die COMMENT-Variable soll unmittelbar nach der MAINTAINER-Variable im
   Makefile stehen.

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

5.7. Abha:ngigkeiten (dependencies)

   Viele Ports ha:ngen von anderen Ports ab. Dies ist ein sehr praktisches
   und nettes Feature der meisten Unix-a:hnlichen Betriebssysteme, FreeBSD
   nicht ausgeschlossen. Es erlaubt, dass ha:ufig vorkommende Abha:ngigkeiten
   nicht mit jedem Port oder Paket zusammen ausgeliefert werden mu:ssen, da
   viele Ports diese gemeinsam benutzen. Es gibt sieben Variablen, die
   benutzt werden ko:nnen, um sicherzustellen, dass alle beno:tigten Teile
   auf dem Rechner des Nutzers sind. Zusa:tzlich gibt es einige vordefinierte
   Variablen fu:r Abha:ngigkeiten in ha:ufigen Fa:llen und einige, welche das
   Verhalten der Abha:ngigkeiten bestimmen.

  5.7.1. LIB_DEPENDS

   Diese Variable spezifiziert die Shared-Libraries, von denen der Port
   abha: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 verfu:gbar, und target das Target in diesem
   Verzeichnis angeben. Zum Beispiel wird

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

   auf eine jpeg-Bibliothek mit der Hauptversionsnummer 9 pru:fen, in das
   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
   hierfu:r ist install).

  Anmerkung:

   Der lib-Teil ist ein regula:rer Ausdruck, welcher die Ausgabe von ldconfig
   -r ausgewertet. Werte wie intl.[5-7] und intl sind zula:ssig. Das erste
   Muster, intl.[5-7], stimmt u:berein mit: intl.5, intl.6 oder intl.7. Das
   zweite Muster, intl, stimmt u:berein mit jeder Version der
   intl-Bibliothek.

   Die Abha:ngigkeit wird zwei Mal u:berpru:ft, einmal innerhalb des
   extract-Target und dann innerhalb des install-Target. Zudem wird der Name
   der Abha:ngigkeit in das Paket eingefu:gt, damit pkg_add(1) es automatisch
   installiert, falls es nicht auf dem Rechner des Nutzers ist.

  5.7.2. RUN_DEPENDS

   Diese Variable legt Bina:rdateien oder Dateien, von denen der Port
   abha:ngt, fu:r die Laufzeit fest. Es ist eine Liste von
   path:dir[:target]-Tupeln, wobei path der Name der Bina: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; u:berpru:ft. Andernfalls wird angenommen,
   dass es eine Bina:rdatei ist und which -s wird benutzt, um zu
   u:berpru:fen, ob das Programm im Pfad vorhanden ist.

   Zum Beispiel wird

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

   u:berpru:fen, ob die Datei oder das Verzeichnis /usr/local/etc/innd
   existiert und es erstellen und installieren aus dem
   news/inn-Unterverzeichnis der Ports-Sammlung, falls es nicht gefunden
   wird. Es wird zudem u:berpru:ft, ob die Bina:rdatei namens xmlcatmgr im
   Suchpfad vorhanden ist und danach zum Unterverzeichnis textproc/xmlcatmgr
   in Ihrer Ports-Sammlung wechseln, es bauen und installieren, falls es
   nicht gefunden wird.

  Anmerkung:

   In diesem Fall ist innd eine Bina:rdatei. Falls sich eine Bina:rdatei an
   einem ungewo:hnlichen Platz befindet, der nicht im Suchpfad ist, dann
   sollten Sie die volle Pfadangabe verwenden.

  Anmerkung:

   Der offizielle Suchpfad PATH, welcher im Ports Cluster benutzt wird, ist

 /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin

   Die Abha:ngigkeit wird innerhalb des install-Target u:berpru:ft. Zudem
   wird der Name der Abha:ngigkeit in das Paket u:bernommen, damit 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 ha:ufig vor, dass RUN_DEPENDS genau dasselbe entha: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:

 RUN_DEPENDS= ${BUILD_DEPENDS}

   Jedoch kann eine solche Zuweisung dazu fu:hren, dass die Liste der
   Laufzeitabha:ngigkeiten mit u:berflu:ssigen Eintra:gen belastet wird, die
   sich nicht in der urspru:nglichen Liste BUILD_DEPENDS des Ports befanden,
   da sich make(1) bei der Auswertung solcher Zuweisungen tra:ge verha:lt.
   Stellen Sie sich ein Makefile mit USE_*-Variablen vor, die von
   ports/Mk/bsd.*.mk verarbeitet werden, um initiale Bauabha:ngigkeiten
   zusammenzutragen. Zum Beispiel fu:gt USE_GMAKE=yes devel/gmake zu
   BUILD_DEPENDS hinzu. Um zu verhindern, dass solche zusa:tzlichen
   Abha: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:

 RUN_DEPENDS:=  ${BUILD_DEPENDS}

  5.7.3. BUILD_DEPENDS

   Diese Variable legt Bina:rdateien oder Dateien fest, die dieser Port zur
   Erstellung beno:tigt. Wie RUN_DEPENDS ist es eine Liste von
   path:dir[:target]-Tupeln. Zum Beispiel wird

  BUILD_DEPENDS=
           unzip:${PORTSDIR}/archivers/unzip

   u:berpru:fen, ob eine Bina:rdatei unzip vorhanden ist und in das
   Unterverzeichnis archivers/unzip Ihrer Ports-Sammlung wechseln und sie
   erstellen und installieren, falls sie nicht gefunden wird.

  Anmerkung:

   "Erstellen" bedeutet hier alles von der Extraktion bis zur Kompilierung.
   Die Abha:ngigkeit wird im extract-Target u:berpru:ft. Der target-Teil kann
   weggelassen werden, falls er identisch mit der Variable DEPENDS_TARGET
   ist.

  5.7.4. FETCH_DEPENDS

   Diese Variable legt eine Bina:rdatei oder Datei fest, welche der Port
   beno:tigt, um heruntergeladen werden zu ko:nnen. Wie die vorherigen beiden
   Variablen ist er eine Liste von path:dir[:target]-Tupeln. Zum Beispiel
   wird

  FETCH_DEPENDS=
           ncftp2:${PORTSDIR}/net/ncftp2

   u:berpru:fen, ob eine Bina:rdatei namens ncftp2 vorhanden ist, in das
   Unterverzeichnis net/ncftp2 Ihrer Ports-Sammlung wechseln, sie erstellen
   und installieren, falls sie nicht gefunden wird.

   Die Abha:ngigkeit wird innerhalb des fetch-Target u:berpru:ft. Der
   target-Teil kann weggelassen werden, falls er identisch mit der Variable
   DEPENDS_TARGET ist.

  5.7.5. EXTRACT_DEPENDS

   Diese Variable spezifiziert eine Bina:rdatei oder eine Datei, welche
   dieser Port fu:r die Extraktion beno:tigt. Wie die vorherigen Variablen
   ist er eine Liste von path:dir[:target]-Tupeln. Zum Beispiel wird

 EXTRACT_DEPENDS=
           unzip:${PORTSDIR}/archivers/unzip

   u:berpru:fen, ob eine Bina:rdatei namens unzip vorhanden ist, in das
   Unterverzeichnis archivers/unzip Ihrer Ports-Sammlung wechseln, sie
   erstellen und installieren, falls sie nicht gefunden wird.

   Die Abha:ngigkeit wird innerhalb des extract-Target u:berpru:ft. Der
   target-Teil kann weggelassen werden, falls er identisch mit der Variable
   DEPENDS_TARGET ist.

  Anmerkung:

   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
   Abschnitt 5.7.7, "USE_* " beschrieben zum Laufen gebracht werden kann.

  5.7.6. PATCH_DEPENDS

   Diese Variable legt eine Bina:rdatei oder eine Datei fest, welche dieser
   Port zum Patchen beno:tigt. Wie die vorhergehenden Variablen ist diese
   eine Liste von path:dir[:target]-Tupeln. Zum Beispiel wird

  PATCH_DEPENDS=
           ${NONEXISTENT}:${PORTSDIR}/java/jfc:extract
          

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

   Die Abha:ngigkeit wird innerhalb des patch-Target u:berpru:ft. Der
   target-Teil kann entfallen, falls er identisch mit der Variable
   DEPENDS_TARGET ist.

  5.7.7. USE_*

   Es gibt eine Reihe von Variablen, um gebra:uchliche Abha:ngigkeiten
   einzukapseln, die viele Ports aufweisen. Obwohl Ihre Verwendung optional
   ist, ko:nnen sie helfen die U:bersichtlichkeit des Makefile eines Ports zu
   erho:hen. Jede von ihnen ist im Stil von USE_*. Der Gebrauch dieser
   Variablen ist beschra:nkt auf das Makefile eines Ports und
   ports/Mk/bsd.*.mk. Es ist nicht entworfen worden, um durch den Nutzer
   setzbare Optionen einzukapseln; benutzen Sie WITH_* und WITHOUT_* fu:r
   diese Zwecke.

  Anmerkung:

   Es ist immer falsch, irgendeine USE_*-Variable in der /etc/make.conf zu
   setzen. Zum Beispiel wu:rde das Setzen von

 USE_GCC=3.4

   eine Abha:ngigkeit fu:r GCC34 fu:r jeden Port einschliesslich GCC34 selbst
   hinzufu:gen!

   Tabelle 5.2. Die USE_*-Varibalen

     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 fu:r die Erstellung.                   
                Der Port erfordert cdrecord entweder von sysutils/cdrtools    
   USE_CDRTOOLS oder sysutils/cdrtools-cjk, abha:ngig davon, was der Nutzer   
                vorgibt.                                                      
                Dieser Port beno: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    
   USE_GCC      Version spezifiziert werden. Der gcc aus dem Basissystem wird 
                genutzt, wenn er die erforderliche Version erfu:llt,          
                andernfalls wird eine geeignete Version des gcc aus den Ports 
                kompiliert und die Variablen CC und CXX werden angepasst.     

   Variablen zugeho:rig zu gmake und dem configure-Skript werden in
   Abschnitt 6.3, "Build-Mechanismen" beschrieben, wa:hrenddessen autoconf,
   automake und libtool in Abschnitt 6.4, "Benutzung von GNU autotools"
   beschrieben sind. Perl-spezifische Variablen werden in Abschnitt 6.6, "Die
   Benutzung von perl" behandelt. X11-Variablen sind aufgelistet in
   Abschnitt 6.7, "Benutzung von X11". Abschnitt 6.8, "Benutzung von GNOME"
   behandelt GNOME-bezogene Variablen und Abschnitt 6.10, "Benutzung von KDE"
   KDE-bezogene Variablen. Abschnitt 6.11, "Benutzung von Java" dokumentiert
   Java-Variablen, wa:hrend Abschnitt 6.12, "Webanwendungen, Apache und
   PHP"Informationen zu Apache, PHP und PEAR-Modulen entha:lt. Python wird in
   Abschnitt 6.13, "Python benutzen" und Ruby in Abschnitt 6.16, "Ruby
   benutzen" ero:rtert. Abschnitt 6.17, "SDL verwenden" stellt Variablen fu:r
   SDL-Programme zur Verfu:gung und Abschnitt 6.20, "Xfce verwenden" entha:lt
   schliesslich Variablen fu:r Xfce.

  5.7.8. Minimale Version einer Abha:ngigkeit

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

 p5-Spiffy>=0.26:${PORTSDIR}/devel/p5-Spiffy

   Das erste Feld entha:lt einen abha:ngigen Paketnamen, welcher einem
   Eintrag in der Paketdatenbank entsprechen muss und einen Vergleich mit
   einer Paketversion. Die Abha:ngigkeit wird erfu:llt, wenn p5-Spiffy-0.26
   oder eine neuere Version auf dem System installiert ist.

  5.7.9. Anmerkungen zu Abha:ngigkeiten

   Wie vorstehend beschrieben ist das Vorgabe-Target DEPENDS_TARGET, wenn
   eine Abha:ngigkeit beno:tigt wird. Die Vorgabe hierfu:r ist install. Dies
   ist eine Nutzer-Variable; sie wird niemals im Makefile eines Ports
   definiert. Falls Ihr Port einen besonderen Weg beno:tigt, um mit einer
   Abha:ngigkeit umzugehen, dann benutzen Sie bitte den :target-Teil der
   *_DEPENDS-Variablen, anstatt DEPENDS_TARGET zu a:ndern.

   Falls Sie make clean schreiben, werden dessen Abha:ngigkeiten auch
   gesa: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 Abha:ngigkeiten hat, das sehr viel
   Zeit fu:r einen rebuild beno:tigt wie KDE, GNOME oder Mozilla.

   Um von einem anderen Port bedingungslos abha: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 beno:tigen. Sie ko:nnen auch oft Kompilierzeit sparen, wenn Sie das
   Target festlegen. Zum Beispiel wird

 BUILD_DEPENDS=   ${NONEXISTENT}:${PORTSDIR}/graphics/jpeg:extract

   immer zum jpeg-Port wechseln und ihn extrahieren.

  5.7.10. Zirkula:re Abha:ngigkeiten sind fatal

  Wichtig:

   Fu:hren Sie niemals irgendwelche zirkula:ren Abha:ngigkeiten in der
   Ports-Sammlung ein!

   Die Struktur fu:r die Erstellung von Ports dulde keinerlei zirkula:re
   Abha: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 A: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
   mo:glicherweise eine Menge A:rger.

5.8. MASTERDIR

   Falls Ihr Port wegen einer Variable, die verschiedene Werte annimmt (z.B.
   Auflo:sung oder Papiergro:sse), leicht unterschiedliche Versione von
   Paketen erzeugen muss, dann legen Sie bitte ein Unterverzeichnis pro Paket
   an, um es fu:r den Nutzer einfacher begreiflich zu machen, was zu machen
   ist. Aber versuchen Sie dabei so viele Dateien wie mo:glich zwischen
   diesen Ports gemeinsam zu nutzen. Normalerweise beno:tigen Sie nur ein
   sehr kurzes Makefile in allen ausser einem Unterverzeichnis, wenn Sie
   Variablen intelligent nutzen. In diesem einzigen Makefile ko:nnen Sie
   MASTERDIR verwenden, um anzugeben, wo der Rest der Dateien liegt. Benutzen
   Sie bitte auch eine Variable fu:r PKGNAMESUFFIX, damit die Pakete
   unterschiedliche Namen haben werden.

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

 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

   japanese/xdvi300 verfu:gt ebenfalls u:ber alle Patches, Paket-Dateien usw.
   Wenn Sie make eintippen, wird der Port die Standardvorgabe fu:r die
   Auflo:sung nehmen (300) und den Port ganz normal erstellen.

   Genauso wie fu:r alle anderen Auflo:sungen ist dies das vollsta:ndige
   xdvi118/Makefile:

 RESOLUTION=     118
 MASTERDIR=      ${.CURDIR}/../xdvi300

 .include "${MASTERDIR}/Makefile"

   (xdvi240/Makefile und xdvi400/Makefile sind a:hnlich). Die
   MASTERDIR-Definition teilt dem bsd.port.mk mit, dass die normalen
   Unterverzeichnisse wie FILESDIR und SCRIPTDIR unter xdvi300 gefunden
   werden ko:nnen. Die RESOLUTION=118-Zeile wird die RESOLUTION=300-Zeile in
   xdvi300/Makefile u:berschreiben und der Port wird mit einer Auflo:sung von
   118 erstellt.

5.9. Manualpages

   Die Variablen MAN[1-9LN] werden automatisch jede Manualpage zur pkg-plist
   hinzufu:gen (dies bedeutet, dass Sie Manualpages nicht in der pkg-plist
   auflisten du:rfen, lesen Sie bitte Erstellung der PLIST fu:r weitere
   Details). Sie veranlassen zudem den Installationsabschnitt dazu, die
   Manualpages zu Komprimieren oder zu Dekomprimieren abha:ngig vom gesetzten
   Wert der Variable NO_MANCOMPRESS in /etc/make.conf.

   Falls Ihr Port versucht verschiedene Namen fu:r Manualpages unter
   Zuhilfenahme von Symlinks oder Hardlinks zu installieren, mu:ssen Sie die
   Variable MLINKS nutzen, um diese zu identifizieren. Der von Ihrem Port
   installierte Link wird von bsd.port.mk gelo:scht und wieder eingefu:gt, um
   sicherzustellen, dass er auf die korrekte Datei zeigt. Jede Manualpage,
   welche in MLINKS aufgefu:hrt ist, darf nicht in der pkg-plist aufgenommen
   werden.

   Falls die Manualpages wa:hrend der Installation komprimiert werden sollen,
   mu: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
   bsd.port.mk nichts Besonderes auszufu: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 mu:ssen es nicht explizit angeben,
   ausser die Standardvorgabe ist fu:r Ihren Port nicht passend.

   Wenn Ihr Port den man tree irgendwo anders als in der Variable PREFIX
   verankert, ko: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 ko:nnen Sie
   mittels der Variable MANsectPREFIX (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.

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

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

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

   ${MANPREFIX}/man/man8/alt-name.8.gz kann zusa:tzlich von Ihrem Port
   installiert werden, oder auch nicht. Unabha:ngig davon wird ein Symlink
   erstellt, welcher die Manualpages foo(1) und alt-name(8) einbindet.

   Falls nur manche Manualpages u:bersetzt sind, ko:nnen Sie einige dynamisch
   vom MANLANG-Inhalt erzeugte Variablen nutzen:

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

   Dies fu:hrt zu folgender Liste von Dateien:

 ${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

5.10. Info-Dateien

   Falls Ihr Paket GNU-Info-Dateien installiert, sollten diese in der
   INFO-Variablen augelistet sein (ohne das angeha:ngte .info) mit einem
   Eintrag fu:r jedes Dokument. Von diesen Dateien wird angenommen, dass sie
   nach PREFIX/INFO_PATH installiert werden. Sie ko:nnen INFO_PATH a:ndern,
   falls Ihr Paket einen anderen Ort vorsieht. Jedoch wird dies nicht
   empfohlen. Die Eintra:ge enthalten nur den relativen Pfad zu
   PREFIX/INFO_PATH. Zum Beispiel installiert lang/gcc34 Info-Dateien nach
   PREFIX/INFO_PATH/gcc34, wobei INFO etwa so aussieht:

 INFO= gcc34/cpp gcc34/cppinternals gcc34/g77 ...

   Entsprechende Installations-/Deinstalltions-Codes werden vor der
   Paket-Registrierung automatisch der vorla:ufigen pkg-plist hinzugefu:gt.

5.11. Makefile-Optionen

   Einige gro:ssere Applikationen ko:nnen mit einer Reihe von
   Konfigurationen, die zusa:tzliche Funktionalita:ten hinzufu:gen, erstellt
   werden, falls eine oder mehrere Bibliotheken oder Applikationen verfu:gbar
   sind. Dazu geho:ren die Auswahl von natu: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
   Verfu:gung, damit der Autor des Ports bestimmen kann, welche Konfiguration
   erstellt werden soll.

  5.11.1. KNOBS (Einstellungen)

    5.11.1.1. WITH_* und WITHOUT_*

   Diese Variablen sind entworfen worden, um vom System-Administrator gesetzt
   zu werden. Es gibt viele, die in 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.

  Anmerkung:

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

  Anmerkung:

   Falls nicht anderweitig festgelegt, werden diese Variablen nur dahingehend
   u:berpru:ft, ob sie gesetzt sind oder nicht - nicht darauf, ob sie auf
   bestimmte Werte wie YES oder NO gesetzt sind.

   Tabelle 5.3. Ha:ufige WITH_* und WITHOUT_*-Variablen

       Variable                             Bedeutung                         
                     Falls gesetzt, bedeutet sie, dass eine                   
   WITHOUT_NLS       Internationalisierung nicht beno:tigt wird, was          
                     Kompilierzeit sparen kann. Als Vorgabe wird              
                     Internationalisierung gebraucht.                         
   WITH_OPENSSL_BASE Nutze die Version von OpenSSL aus dem Basissystem.       
                     Installiert die Version von OpenSSL aus                  
   WITH_OPENSSL_PORT security/openssl, auch wenn das Basissystem auf          
                     aktuellem Stand ist.                                     
                     Falls der Port mit oder ohne Unterstu:tzung fu:r X       
                     erstellt werden kann, dann sollte normalerweise mit      
   WITHOUT_X11       X-Unterstu:tzung erstellt werden. Falls die Variable     
                     gesetzt ist, soll die Version ohne X-Unterstu:tzung      
                     erstellt werden.                                         

    5.11.1.2. Benennung von Knobs (Einstellungen)

   Um die Anzahl der Knobs niedrig zu halten und zum Vorteil des Anwenders,
   wird empfohlen, dass Porter a:hnliche Namen fu:r Knobs verwenden. Eine
   Liste der beliebtesten Knobs kann in der KNOBS-Datei eingesehen werden.

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

  5.11.2. OPTIONS

    5.11.2.1. Hintergrund

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

   Wenn der Anwender make config benutzt (oder ein make build das erste Mal
   laufen la:sst) wird das Framework auf /var/db/ports/portname/options die
   Einstellungen pru: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 ko:nnen. Dann wird die options-Datei
   gespeichert und die ausgewa:hlten Variablen werden bei der Erstellung des
   Ports benutzt.

   Falls eine neue Version des Ports OPTIONS hinzufu: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 Lo:schen.

    5.11.2.2. Syntax

   Die Syntax fu:r die OPTIONS-Variable lautet:

 OPTIONS=    OPTION    "descriptive text" default ...

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

   OPTIONS-Definitionen mu:ssen vor der Einbindung von bsd.port.options.mk
   erscheinen. Die WITH_* und WITHOUT_*-Variablen ko:nnen nur nach der
   Einbindung von bsd.port.options.mk getestet werden. bsd.port.pre.mk kann
   auch stattdessen eingebunden werden und wird immer noch von vielen Ports
   eingebunden, die vor der Einfu:hrung von bsd.port.options.mk erstellt
   wurden. Jedoch wirken manche Variablen nicht wie gewohnt nach der
   Einbindung von bsd.port.pre.mk, typischerweise USE_*-Optionen.

   Beispiel 5.8. Einfache Anwendung von OPTIONS

 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>

   Beispiel 5.9. Veraltete Anwendung von OPTIONS

 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>

  5.11.3. 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 mo:chten,
   ausdru:cklich durch Verwendung von --without-xxx oder --disable-xxx in der
   Variable CONFIGURE_ARGS einzeln ab.

   Beispiel 5.10. Falsche Behandlung einer Option

 .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 fu:gt ihre Funktionen
   in die Bina:rdatei ein. Falls der Nutzer sich nun entschliesst libfoo von
   seinem System zu entfernen, dann wird das Ports-System nicht protestieren
   (es wurde keine Abha:ngigkeit von libfoo eingetragen), aber die
   Applikation bricht ab.

   Beispiel 5.11. Korrekte Behandlung einer Option

 .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.

5.12. 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:

 PORTNAME=      foo
 PORTVERSION=   1.0

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

   Es gibt eine Reihe von Variablen, die Sie u:berschreiben ko:nnen, falls
   dies nicht der Fall sein sollte.

  5.12.1. 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 foo (und nicht foo-1.0)
   extrahiert wurde, wu:rden Sie schreiben:

 WRKSRC=      ${WRKDIR}/foo

   oder mo:glicherweise

 WRKSRC=      ${WRKDIR}/${PORTNAME}
          

  5.12.2. NO_WRKSUBDIR

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

 NO_WRKSUBDIR= yes

5.13. Konfliktbehandlung

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

  Anmerkung:

   CONFLICTS setzt automatisch die Variable IGNORE, die ausfu:hrlicher in
   Abschnitt 12.14, "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-Eintra:ge in den anderen Ports fu:r einige Monate
   beizubehalten, um Nutzer zu unterstu:tzen, die ihre Ports nur sporadisch
   aktualisieren.

  5.13.1. CONFLICTS_INSTALL

   Falls Ihr Paket nicht mit anderen Paketen koexistieren kann (wegen
   Dateikonflikten, Laufzeit-Inkompatibilita:ten usw.), fu:hren Sie bitte die
   anderen Paketnamen in der Variable CONFLICTS_INSTALL auf. Sie ko:nnen hier
   Shell-Globs wie * und ? verwenden. Paketnamen sollten in der gleichen
   Weise aufgeza:hlt werden, wie sie in /var/db/pkg auftauchen. Bitte stellen
   Sie sicher, dass CONFLICTS nicht mit dem Paket des Ports selbst
   u:bereinstimmt, da ansonsten das Erzwingen der Installation durch
   FORCE_PKG_REGISTER nicht la:nger funktionieren wird.

  5.13.2. 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
   ko:nnen hier Shell-Globs wie * und ? verwenden. Paketnamen sollten in der
   gleichen Weise aufgeza:hlt werden, wie sie in /var/db/pkg auftauchen. Die
   CONFLICTS_BUILD-Pru:fung erfolgt vor dem Bau des Ports. Baukonflikte
   werden im erzeugten Paket nicht verzeichnet.

  5.13.3. 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 ko:nnen hier Shell-Globs wie * und ? verwenden.
   Paketnamen sollten in der gleichen Weise aufgeza:hlt werden, wie sie in
   /var/db/pkg auftauchen. Bitte stellen Sie sicher, dass CONFLICTS_INSTALL
   nicht mit dem Paket des Ports selbst u:bereinstimmt, da ansonsten das
   Erzwingen der Installation durch FORCE_PKG_REGISTER nicht la:nger
   funktionieren wird. Die CONFLICTS-Pru:fung erfolgt vor dem Bau des Ports
   und vor der Installation des gebauten Ports.

5.14. Installation von Dateien

  5.14.1. INSTALL_* macros

   Nutzen Sie die Makros in bsd.port.mk, um korrekte Modi und Eigentu:mer von
   Dateien in Ihren *-install-Targets sicherzustellen.

     * INSTALL_PROGRAM ist ein Befehl, um bina:re Bina:rdateien zu
       installieren.

     * INSTALL_SCRIPT ist ein Befehl, um ausfu:hrbare Skripte zu
       installieren.

     * INSTALL_LIB ist ein Befehl zur Installation Shared-Libraries.

     * INSTALL_KLD ist ein Befehl, mit dem Kernelmodule installiert werden
       ko: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 grundsa:tzlich alle install-Befehle mit ihren passenden Flags.

  5.14.2. Zerlegen von Bina:rdateien und Shared-Libraries

   Zerlegen Sie keine Bina:rdateien manuell, wenn Sie es nicht mu:ssen. Alle
   Binaries sollten gestripped werden; allerdings vermag das
   INSTALL_PROGRAM-Makro gleichzeitig eine Bina:rdatei zu installieren und zu
   strippen (beachten Sie den na:chsten Abschnitt). Das Makro INSTALL_LIB
   erledigt das gleiche fu:r Shared-Libraries.

   Wenn Sie eine Datei strippen mu: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:

 post-install:
     ${STRIP_CMD} ${PREFIX}/bin/xdl

   Nutzen Sie file(1) fu:r die installierte Applikation, um zu u:berpru:fen,
   ob eine Bina:rdatei gestripped ist oder nicht. Wenn es nicht meldet not
   stripped, dann ist es bereits gestripped. Zudem wird strip(1) nicht ein
   bereits gestripptes Programm nochmals versuchen zu strippen, sondern wird
   stattdessen einfach sauber beenden.

  5.14.3. Installation eines ganzen Verzeichnisbaums inklusive Dateien

   Manchmal muss man eine grosse Zahl von Dateien unter Erhalt ihrer
   hierarchischen Struktur installieren, d.h. Kopieraktionen u:ber einen
   ganzen Verzeichnisbaum von WRKSRC zu einem Zielverzeichnis unter PREFIX.

   Fu: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 ausfu:hrbar markieren und damit passend fu:r die
   Installation in PREFIX/bin vorbereiten. Das zweite Makro, COPYTREE_SHARE,
   setzt keine Ausfu:hrungsberechtigungen auf Dateien und ist daher geeignet
   fu:r die Installation von Dateien im Target von PREFIX/share.

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

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

 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
   summer-Unterverzeichnis eines DATADIR installieren.

   Zusa:tzliche find-Argumente ko:nnen mit dem dritten Argument an die
   COPYTREE_*-Makros u:bergeben werden. Um zum Beispiel alle Dateien aus dem
   1. Beispiel ohne die Makefiles zu installieren, kann man folgenden Befehl
   benutzen.

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

   Beachten Sie bitte, dass diese Makros die installierten Dateien nicht zur
   pkg-plist hinzufu:gen, Sie mu:ssen sie immer noch selbst auflisten.

  5.14.4. Installation zusa:tzlicher Dokumentation

   Falls Ihre Software zusa:tzlich zu den u:blichen Manualpages und
   Info-Seiten weitere Dokumentation hat und Sie diese fu:r nu:tzlich halten,
   dann installieren Sie sie unter PREFIX/share/doc. Dies kann wie vorstehend
   im Target des post-install geschehen.

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

   Machen Sie die Installation von der Variablen NOPORTDOCS abha:ngig, damit
   die Nutzer sie in /etc/make.conf abschalten ko:nnen:

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

   Hier einige praktische Variablen und wie sie standardma:ssig bei
   Verwendung im Makefile expandiert werden:

     * DATADIR wird expandiert zu PREFIX/share/PORTNAME.

     * DATADIR_REL wird expandiert zu share/PORTNAME.

     * DOCSDIR wird expandiert zu PREFIX/share/doc/PORTNAME.

     * DOCSDIR_REL wird expandiert zu share/doc/PORTNAME.

     * EXAMPLESDIR wird expandiert zu PREFIX/share/examples/PORTNAME.

     * EXAMPLESDIR_REL wird expandiert zu share/examples/PORTNAME.

  Anmerkung:

   NOPORTDOCS behandelt nur zusa:tzliche Dokumentation, die in DOCSDIR
   installiert ist. Fu: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 PREFIX, falls mo:glich. Das bedeutet, dass
   share/doc/PORTNAME standardma:ssig ersetzt wird durch %%DOCSDIR%% in der
   Packliste usw. (mehr zur Ersetzung durch die pkg-plist finden Sie hier).

   Alle installierten Dokumentationsdateien und -Verzeichnisse sollten in der
   pkg-plist dem %%PORTDOCS%%-Pra:fix enthalten sein, zum Beispiel:

 %%PORTDOCS%%%%DOCSDIR%%/AUTHORS
 %%PORTDOCS%%%%DOCSDIR%%/CONTACT
 %%PORTDOCS%%@dirrm %%DOCSDIR%%

   Alternativ zur Auflistung der Dokumentationsdateien in der pkg-plist kann
   in einem Port auch die Variable PORTDOCS gesetzt werden fu:r eine Liste
   von Dateien und Shell-Globs, um diese zur endgu:ltigen Packliste
   hinzuzufu: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 fu:r seine Dokumentation, dann mu:ssen Sie
   die Variable DOCSDIR entsprechend setzen. Wenn ein Verzeichnis in PORTDOCS
   aufgefu:hrt ist, oder von einem Shell-Glob dieser Variable abgebildet
   wird, dann wird der komplette Verzeichnisbaum inklusive Dateien und
   Verzeichnissen in der endgu: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 hinzugefu:gt. Wie oben gezeigt
   bleibt es dem Port selbst u:berlassen, die Dokumentation in PORTDOCS zu
   installieren. Ein typisches Beispiel fu:r den Gebrauch von PORTDOCS sieht
   wie folgt aus:

 PORTDOCS=       README.* ChangeLog docs/*

  Anmerkung:

   Die A:quivalente zu PORTDOCS fu:r unter DATADIR und EXAMPLESDIR
   installierte Dateien sind PORTDATA beziehungsweise PORTEXAMPLES.

   Sie ko:nnen auch pkg-message benutzen, um Meldungen wa:hrend der
   Installation anzuzeigen. Lesen Sie diesen Abschnitt u:ber den Gebrauch von
   pkg-message fu:r weitere Details. Die pkg-message-Datei muss nicht zur
   pkg-plist hinzugefu:gt werden.

  5.14.5. 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 lib, was natu:rlich auch nicht der
   BSD-Philosophie entspricht und nicht gut funktioniert. Viele der Dateien
   sollten in eines der folgenden Verzeichnisse geschoben werden: etc
   (Konfigurationsdateien), libexec (intern gestartete Bina:rdateien), sbin
   (Bina:rdateien fu:r Superuser/Manager), info (Dokumentation fu:r
   Info-Browser) oder share (Architektur-unabha:ngige Dateien). Lesen Sie
   hierzu hier(7); weitestgehend greifen die Regeln fu:r /usr auch fu:r
   /usr/local. Die Ausnahme sind Ports, welche mit "news" aus dem USENET
   arbeiten. In diesem Falle sollte PREFIX/news als Zielort fu:r die Dateien
   benutzt werden.

                           Kapitel 6. Besonderheiten

   Inhaltsverzeichnis

   6.1. Shared-Libraries

   6.2. Ports mit beschra:nkter Verbreitung

   6.3. Build-Mechanismen

   6.4. Benutzung von GNU autotools

   6.5. Benutzung von GNU gettext

   6.6. Die Benutzung von perl

   6.7. Benutzung von X11

   6.8. Benutzung von GNOME

   6.9. Benutzung von Qt

   6.10. Benutzung von KDE

   6.11. Benutzung von Java

   6.12. Webanwendungen, Apache und PHP

   6.13. Python benutzen

   6.14. Benutzung von Tcl/Tk

   6.15. Emacs benutzen

   6.16. Ruby benutzen

   6.17. SDL verwenden

   6.18. wxWidgets verwenden

   6.19. Verwendung von Lua

   6.20. Xfce verwenden

   6.21. Mozilla verwenden

   6.22. Benutzung von Datenbanken

   6.23. Starten und Anhalten von Diensten (rc Skripten)

   6.24. Hinzufu:gen von Benutzern und Gruppen

   6.25. Von Kernelquellen abha:ngige Ports

   Es gibt einige Dinge mehr, die zu beachten sind, wenn man einen Port
   erstellt. Dieser Abschnitt erkla:rt die wichtigsten.

6.1. Shared-Libraries

   Wenn Ihr Port eine oder mehrere Shared-Libraries installiert, dann
   definieren Sie bitte eine USE_LDCONFIG make-Variable, die bsd.port.mk
   anweisen wird, ${LDCONFIG} -m auf das Verzeichnis, in das die neue Library
   installiert wird (normalerweise PREFIX/lib), wa:hrend des
   post-install-Targets anzuwenden, um sie im Shared-Library-Cache zu
   registrieren. Diese Variable, wenn definiert, wird auch dafu:r sorgen,
   dass ein entsprechendes @exec /sbin/ldconfig -m und @unexec /sbin/ldconfig
   -R-Paar zu Ihrer pkg-plist-Datei hinzugefu:gt wird, sodass ein Benutzer,
   der das Paket installiert, die Bibliothek danach sofort benutzen kann und
   das System nach deren Deinstallation nicht glaubt, die Bibliothek wa:re
   noch da.

 USE_LDCONFIG= yes

   Wenn no:tig, ko:nnen Sie das Standardverzeichnis ausser Kraft setzen,
   indem Sie den USE_LDCONFIG Wert auf eine Liste von Verzeichnissen setzen,
   in die Shared Libraries installiert werden sollen. Wenn Ihr Port z.B.
   diese Bibliotheken nach PREFIX/lib/foo und PREFIX/lib/bar installiert,
   ko:nnten Sie folgendes in Ihrem Makefile benutzen:

 USE_LDCONFIG= ${PREFIX}/lib/foo ${PREFIX}/lib/bar

   Bitte u:berpru:fen Sie dies genau. Oft ist das u:berhaupt nicht no:tig
   oder kann durch -rpath oder das Setzen von LD_RUN_PATH wa:hrend des
   Linkens umgangen werden (s. lang/moscow_ml fu:r ein Beispiel), oder durch
   einen Shell-Wrapper, der LD_LIBRARY_PATH setzt, bevor er die Bina:rdatei
   ausfu:hrt, wie es www/seamonkey tut.

   Wenn Sie 32-Bit Libraries auf 64-Bit Systemen installieren, benutzen Sie
   stattdessen USE_LDCONFIG32.

   Versuchen Sie Shared-Library-Versionsnummern im libfoo.so.0 Format zu
   halten. Unser Runtime-Linker ku:mmert sich nur um die Major (erste)
   Nummer.

   Wenn sich die Major-Library-Versionsnummer wa:hrend der Aktualisierung zu
   einer neuen Portversion erho:ht, sollte auch die PORTREVISION aller Ports,
   die die Shared-Library linken, erho:ht werden, damit diese mit der neuen
   Version der Bibliothek neu kompiliert werden.

6.2. Ports mit beschra:nkter Verbreitung

   Lizenzen variieren und manche geben Restriktionen vor, wie die Applikation
   gepackt werden oder ob sie gewinnorientiert verkauft werden kann, usw.

  Wichtig:

   Es liegt in Ihrer Verantwortung als Porter die Lizenzbestimmungen der
   Software zu lesen und sicherzustellen, dass das FreeBSD-Projekt nicht
   haftbar gemacht wird fu:r Lizenzverletzungen durch Weiterverbreitung des
   Quelltextes oder kompilierter Binaries u:ber FTP/HTTP oder CD-ROM. Im
   Zweifelsfall kontaktieren Sie bitte die FreeBSD ports.

   In solchen Situationen ko:nnen die in den folgenden Abschnitten
   beschriebenen Variablen gesetzt werden.

  6.2.1. NO_PACKAGE

   Diese Variable zeigt an, dass wir keine bina:ren Pakete dieser Applikation
   erzeugen du:rfen - z.B. wenn die Lizenz die Weiterverteilung von bina:ren
   Paketen oder Paketen verbietet, die aus vera:ndertem Quelltext erzeugt
   wurden.

   Die DISTFILES des Ports du:rfen allerdings frei u:ber FTP/HTTP Mirrors
   weiterverbreitet werden. Sie du:rfen auch auf CD-ROM (oder a:hnlichen
   Medien) weiterverbreitet werden - es sei denn, NO_CDROM ist ebenfalls
   gesetzt.

   NO_PACKAGE sollte auch benutzt werden, wenn das bina:re Paket nicht
   allgemein brauchbar ist und die Applikation immer aus dem Quelltext
   kompiliert werden sollte. Zum Beispiel, wenn die Applikation konfigurierte
   Informationen u:ber den Rechner/Installationsort bei der Installation
   einkompiliert bekommt, setzen Sie NO_PACKAGE.

   NO_PACKAGE sollte auf eine Zeichenkette gesetzt werden, die den Grund
   beschreibt, warum kein Paket erzeugt werden soll.

  6.2.2. NO_CDROM

   Diese Variable gibt an, dassobwohl wir bina:re Pakete erzeugen
   du:rfen - wir weder diese Pakete noch die DISTFILES des Ports auf einer
   CD-ROM (oder a:hnlichen Medien) verkaufen du:rfen. Die DISTFILES des Ports
   du:rfen allerdings immer noch auf FTP/HTTP Mirrors.

   Wenn diese Variable und auch NO_PACKAGE gesetzt ist, dann werden nur die
   DISTFILES des Ports erha:ltlich sein - und das nur mittels FTP/HTTP.

   NO_CDROM sollte auf eine Zeichenkette gesetzt werden, die den Grund
   beschreibt, warum der Port nicht auf CD-ROM weiterverbreitet werden kann.
   Das sollte z.B. gemacht werden, wenn die Lizenz des Ports nur fu:r
   "nichtkommerzielle Zwecke" gilt.

  6.2.3. NOFETCHFILES

   Dateien, die in der Variable NOFETCHFILES aufgelistet sind, sind von
   keiner der MASTER_SITES abrufbar. Ein Beispiel solch einer Datei ist eine
   selbige, welche vom Anbieter auf CD-ROM bereitgestellt wird.

   Werkzeuge, die das Vorhandensein dieser Dateien auf den MASTER_SITES
   u:berpru:fen, sollten diese Dateien ignorieren und sie nicht melden.

  6.2.4. RESTRICTED

   Setzen Sie diese Variable, wenn die Lizenz der Applikation weder das
   Spiegeln der DISTFILES der Applikation noch das Weiterverbreiten von
   bina:ren Paketen in jedweder Art erlaubt.

   NO_CDROM oder NO_PACKAGE sollten nicht zusammen mit RESTRICTED gesetzt
   werden, weil letztere Variable die anderen beiden impliziert.

   RESTRICTED sollte auf eine Zeichenkette gesetzt werden, die den Grund
   beschreibt, warum der Port nicht weiterverbreitet werden kann.
   Typischerweise besagt dies, dass der Port proprieta:re Software entha:lt
   und der Benutzer die DISTFILES manuell herunterladen
   muss - mo:glicherweise erst nachdem er sich fu:r die Software registriert
   oder die Bedingungen eines Endbenutzer-Lizenzvertrags (EULA) akzeptiert
   hat.

  6.2.5. RESTRICTED_FILES

   Wenn RESTRICTED oder NO_CDROM gesetzt ist, ist diese Variable auf
   ${DISTFILES} ${PATCHFILES} voreingestellt, sonst ist sie leer. Wenn nicht
   jede dieser Dateien beschra:nkt ist, dann fu:hren Sie die betroffenen
   Dateien in dieser Variable auf.

   Beachten Sie, dass der Porter fu:r jede aufgefu:hrte Distributionsdatei
   einen Eintrag zu /usr/ports/LEGAL hinzufu:gen sollte, der genau
   beschreibt, was die Beschra:nkung mit sich bringt.

6.3. Build-Mechanismen

  6.3.1. Paralleles Bauen von Ports

   Das Ports-Framework von FreeBSD unterstu:tzt das parallele Bauen von
   Ports, indem es mehrere make-Instanzen ausfu:hrt, damit SMP-Systeme ihre
   gesamte CPU-Rechenleistung ausnu:tzen ko:nnen und so das Bauen von Ports
   schneller und effektiver werden kann.

   Dies ermo:glicht der Parameter -jX an make(1), wenn Code von
   Drittanbietern kompiliert wird. Leider ko:nnen nicht alle Ports wirklich
   gut mit dem Parallelbau umgehen. Deshalb ist es erforderlich, dass dieses
   Feature explizit durch MAKE_JOBS_SAFE=yes irgendwo unterhalb des
   Abschnitts fu:r Abha:ngigkeiten im Makefile aktiviert wird.

   Eine weitere Mo:glichkeit im Umgang mit dieser Option besteht fu:r den
   Maintainer darin, MAKE_JOBS_UNSAFE=yes zu setzen. Diese Variable wird dann
   verwendet, wenn ein Port bekannterweise mit -jX nicht gebaut werden kann,
   der Benutzer jedoch fu:r alle Ports den Mehrprozessorbau durch
   FORCE_MAKE_JOBS=yes in /etc/make.conf erzwingt.

  6.3.2. make, gmake und imake

   Wenn Ihr Port GNU make benutzt, dann setzen Sie bitte USE_GMAKE=yes.

   Tabelle 6.1. Port-Variablen im Zusammenhang mit gmake

   Variable                       Bedeutung                      
   USE_GMAKE Der Port beno:tigt gmake fu:r den Build.            
   GMAKE     Der ganze Pfad zu gmake, wenn es nicht im PATH ist. 

   Wenn Ihr Port eine X-Applikation ist, die Makefile-Dateien aus
   Imakefile-Dateien mit imake erzeugt, dann setzen Sie USE_IMAKE=yes. Das
   sorgt dafu:r, dass die Konfigurationsphase automatisch ein xmkmf -a
   ausfu:hrt. Wenn das Flag -a ein Problem fu:r Ihren Port darstellt, setzen
   Sie XMKMF=xmkmf. Wenn der Port imake benutzt, aber das install.man-Target
   nicht versteht, dann sollte NO_INSTALL_MANPAGES=yes gesetzt werden.

   Wenn das Makefile im Quelltext Ihres Ports etwas anderes als all als
   Haupt-Build-Target hat, setzen Sie ALL_TARGET entsprechend. Das Gleiche
   gilt fu:r install und INSTALL_TARGET.

  6.3.3. configure Skript

   Wenn Ihr Port ein configure-Skript benutzt, um Makefile-Dateien aus
   Makefile.in-Dateien zu erzeugen, setzen Sie GNU_CONFIGURE=yes. Wenn Sie
   dem configure-Skript zusa:tzliche Argumente u:bergeben wollen (das
   Vorgabeargument ist --prefix=${PREFIX} --infodir=${PREFIX}/${INFO_PATH}
   --mandir=${MANPREFIX}/man --build=${CONFIGURE_TARGET}), setzen Sie diese
   zusa:tzlichen Argumente in CONFIGURE_ARGS. Zusa:tzliche Umgebungsvariablen
   ko:nnen u:berdie Variable CONFIGURE_ENV u:bergeben werden.

   Tabelle 6.2. Variablen fu:r Ports, die configure benutzen

       Variable                             Bedeutung                         
   GNU_CONFIGURE    Der Port benutzt ein configure-Skript, um das Bauen       
                    vorzubereiten.                                            
                    Wie GNU_CONFIGURE, nur dass kein                          
   HAS_CONFIGURE    Standard-Konfigurations-Target zu CONFIGURE_ARGS          
                    hinzugefu:gt wird.                                        
   CONFIGURE_ARGS   Zusa:tzliche Argumente fu:r das configure-Skript.         
   CONFIGURE_ENV    Zusa:tzliche Umgebungsvariablen fu:r die Abarbeitung des  
                    configure-Skriptes.                                       
   CONFIGURE_TARGET Ersetzt das Standard-Konfigurations-Target. Vorgabewert   
                    ist ${MACHINE_ARCH}-portbld-freebsd${OSREL}.              

  6.3.4. Benutzung von scons

   Wenn Ihr Port SCons benutzt, definieren Sie USE_SCONS=yes.

   Tabelle 6.3. Variablen fu:r Ports, die scons benutzen

      Variable                             Bedeutung                          
   SCONS_ARGS     Port-spezifische SCons-Argumente, die der SCons-Umgebung    
                  u:bergeben werden.                                          
   SCONS_BUILDENV Variablen, die in der System-Umgebung gesetzt werden        
                  sollen.                                                     
   SCONS_ENV      Variablen, die in der SCons-Umgebung gesetzt werden sollen. 
   SCONS_TARGET   Letztes Argument, das SCons u:bergeben wird - a:hnlich      
                  MAKE_TARGET.                                                

   Um SConstruct im Quelltext alles, was SCons in SCONS_ENV u:bergeben wird,
   respektieren zu lassen (das ist hauptsa:chlich CC/CXX/CFLAGS/CXXFLAGS),
   patchen Sie SConstruct, sodass das Build Environment wie folgt konstruiert
   wird:

 env = Environment(**ARGUMENTS)

   Es kann dann mit env.Append und env.Replace modifiziert werden.

6.4. Benutzung von GNU autotools

  6.4.1. Einfu:hrung

   Die verschiedenen GNU autotools stellen einen Abstraktionsmechanismus
   bereit fu:r das Kompilieren von Software fu:r eine Vielfalt von
   Betriebssystemen und Maschinenarchitekturen. Innerhalb der Ports-Sammlung
   kann ein einzelner Port diese Werkzeuge mit Hilfe eines einfachen
   Konstrukts benutzen:

 USE_AUTOTOOLS= tool:version[:operation] ...

   Als dies geschrieben wurde konnte tool eins von libtool, libltdl,
   autoconf, autoheader, automake oder aclocal sein.

   version gibt die einzelne Werkzeug-Revision an, die benutzt werden soll
   (siehe devel/{automake,autoconf,libtool}[0-9]+ fu:r mo:gliche Versionen).

   operation ist eine optionale Angabe, die modifiziert, wie das Werkzeug
   benutzt wird.

   Es ko:nnen auch mehrere Werkzeuge angegeben werden - entweder durch Angabe
   aller in einer einzigen Zeile oder durch Benutzung des +=
   Makefile-Konstrukts.

   Schliesslich gibt es das spezielle Tool, genannt autotools, das der
   Einfachheit dient indem es von alle verfu:gbaren Versionen der Autotools
   abha:ngt, was sinnvoll fu:r Cross-Development ist. Dies kann auch erreicht
   werden, indem man den Port devel/autotools installiert.

  6.4.2. libtool

   Shared-Libraries, die das GNU Build-System benutzen, verwenden
   normalerweise libtool, um die Kompilierung und Installation solcher
   Bibliotheken anzupassen. Die u:bliche Praxis ist, eine Kopie von libtool,
   die mit dem Quelltext geliefert wird, zu benutzen. Falls Sie ein externes
   libtool beno:tigen, ko:nnen Sie die Version, die von der Ports-Sammlung
   bereitgestellt wird, benutzen:

 USE_AUTOTOOLS= libtool:version[:env]

   Ohne zusa:tzliche Angaben sagt libtool:version dem Build-System, dass es
   das Konfigurationsskript mit der auf dem System installierten Kopie von
   libtool patchen soll. Die Variable GNU_CONFIGURE ist impliziert. Ausserdem
   werden einige make- und shell-Variablen zur weiteren Benutzung durch den
   Port gesetzt. Fu:r Genaueres siehe bsd.autotools.mk.

   Mit der Angabe :env wird nur die Umgebung vorbereitet.

   Schliesslich ko:nnen optional LIBTOOLFLAGS und LIBTOOLFILES gesetzt
   werden, um die ha:ufigsten Argumente und durch libtool gepatchten Dateien
   ausser Kraft zu setzen. Die meisten Ports werden das aber nicht brauchen.
   Fu:r Weiteres siehe bsd.autotools.mk.

  6.4.3. libltdl

   Einige Ports benutzen das libltdl-Bibliothekspaket, welches Teil der
   libtool-Suite ist. Der Gebrauch dieser Bibliothek macht nicht automatisch
   den Gebrauch von libtool selbst no:tig, deshalb wird ein separates
   Konstrukt zur Verfu:gung gestellt.

 USE_AUTOTOOLS= libltdl:version

   Im Moment sorgt dies nur fu:r eine LIB_DEPENDS-Abha:ngigkeit von dem
   entsprechenden libltdl-Port und wird zur Vereinfachung zur Verfu:gung
   gestellt, um Abha:ngigkeiten von den Autotools-Ports ausserhalb des
   USE_AUTOTOOLS-Systems zu eliminieren. Es gibt keine weiteren Angaben fu:r
   dieses Werkzeug.

  6.4.4. autoconf und autoheader

   Manche Ports enthalten kein Konfigurationsskript, sondern eine
   autoconf-Vorlage in der configure.ac-Datei. Sie ko:nnen die folgenden
   Zuweisungen benutzen, um autoconf das Konfigurationsskript erzeugen zu
   lassen, und auch autoheader Header-Vorlagen zur Benutzung durch das
   Konfigurationsskript erzeugen zu lassen.

 USE_AUTOTOOLS=    autoconf:version[:env]

   und

 USE_AUTOTOOLS=    autoheader:version

   welches auch die Benutzung von autoconf:version impliziert.

   A:hnlich wie bei libtool, bereitet die Angabe des optionalen :env nur die
   Umgebung fu:r weitere Benutzung vor. Ohne dieses wird der Port auch
   gepatched und erneut konfiguriert.

   Die zusa:tzlichen optionalen Variablen AUTOCONF_ARGS und AUTOHEADER_ARGS
   ko:nnen durch das Makefile des Ports ausser Kraft gesetzt werden, wenn
   erforderlich. Wie bei den libtool-A:quivalenten werden die meisten Ports
   dies aber nicht beno:tigen.

  6.4.5. automake und aclocal

   Manche Pakete enthalten nur Makefile.am-Dateien. Diese mu:ssen durch
   automake in Makefile.in-Dateien konvertiert und dann durch configure
   weiterbearbeitet werden, um schliesslich ein Makefile zu erzeugen.

   A:hnliches gilt fu:r Pakete, die gelegentlich keine aclocal.m4-Dateien
   mitliefern, welche ebenfalls zum Erstellen der Software beno:tigt werden.
   Diese ko:nnen durch aclocal erzeugt werden, welches configure.ac oder
   configure.in durchsucht.

   aclocal hat eine a:hnliche Beziehung zu automake wie autoheader zu
   autoconf - beschrieben im vorherigen Abschnitt. aclocal impliziert die
   Benutzung von automake, also haben wir:

 USE_AUTOTOOLS=    automake:version[:env]

   und

 USE_AUTOTOOLS=    aclocal:version

   was auch die Benutzung von automake:version impliziert.

   A:hnlich wie bei libtool und autoconf, bereitet die optionale Angabe :env
   nur die Umgebung zur weiteren Benutzung vor. Ohne sie wird der Port erneut
   konfiguriert.

   Wie schon autoconf und autoheader, hat sowohl automake als auch aclocal
   eine optionale Argument-Variable AUTOMAKE_ARGS bzw. ACLOCAL_ARGS, die
   durch das Makefile des Ports, falls no:tig, ausser Kraft gesetzt werden
   kann.

6.5. Benutzung von GNU gettext

  6.5.1. Grundlegende Benutzung

   Wenn Ihr Port gettext beno:tigt, setzen Sie einfach USE_GETTEXT auf yes,
   und Ihr Port bekommt die Abha:ngigkeit von devel/gettext. Der Wert von
   USE_GETTEXT kann auch die beno:tigte Version der libintl-Bibliothek
   angeben, der grundlegenden Teil von gettext - jedoch wird von der
   Benutzung dieser Funktion dringend abgeraten: Ihr Port sollte einfach nur
   mit der aktuellen Version von devel/gettext funktionieren.

   Ein ziemlich ha:ufiger Fall ist, dass ein Port gettext und configure
   benutzt. Normalerweise sollte GNU configure gettext automatisch finden
   ko:nnen. Sollte das einmal nicht funktionieren, ko:nnen Hinweise u:ber den
   Ort von gettext in CPPFLAGS und LDFLAGS wie folgt u:bergeben werden:

 USE_GETTEXT=    yes
 CPPFLAGS+=      -I${LOCALBASE}/include
 LDFLAGS+=       -L${LOCALBASE}/lib

 GNU_CONFIGURE=  yes
 CONFIGURE_ENV=  CPPFLAGS="${CPPFLAGS}" \
                 LDFLAGS="${LDFLAGS}"

   Natu:rlich kann der Code kompakter sein, wenn es keine weiteren Flags
   gibt, die configure u:bergeben werden mu:ssen:

 USE_GETTEXT=    yes
 GNU_CONFIGURE=  yes
 CONFIGURE_ENV=  CPPFLAGS="-I${LOCALBASE}/include" \
                 LDFLAGS="-L${LOCALBASE}/lib"

  6.5.2. Optionale Benutzung

   Manche Softwareprodukte erlauben die Deaktivierung von NLS - z.B. durch
   U:bergeben von --disable-nls an configure. In diesem Fall sollte Ihr Port
   gettext abha:ngig vom Status von WITHOUT_NLS benutzen. Fu:r Ports mit
   niedriger bis mittlerer Komplexita:t ko:nnen Sie sich auf das folgende
   Idiom verlassen:

 GNU_CONFIGURE=          yes

 .if !defined(WITHOUT_NLS)
 USE_GETTEXT=            yes
 PLIST_SUB+=             NLS=""
 .else
 CONFIGURE_ARGS+=        --disable-nls
 PLIST_SUB+=             NLS="@comment "
 .endif

   Der na:chste Punkt auf Ihrer Todo-Liste ist dafu:r zu sorgen, dass die
   Message-Catalog-Dateien nur bedingt in der Packliste aufgefu:hrt werden.
   Der Makefile-Teil dieser Aufgabe ist schon durch obiges Idiom erledigt.
   Das wird im Abschnitt u:ber Fortgeschrittene pkg-plist-Methoden erkla:rt.
   Kurz gesagt, jedes Vorkommen von %%NLS%% in pkg-plist wird durch
   "@comment ", wenn NLS abgeschaltet ist, oder durch eine leere
   Zeichenkette, wenn NLS aktiviert ist, ersetzt. Folglich werden die Zeilen,
   denen %%NLS%% vorangestellt ist, zu reinen Kommentaren in der endgu:ltigen
   Packliste, wenn NLS abgeschaltet ist; andernfalls wird der Prefix einfach
   nur ausgelassen. Alles, was Sie jetzt noch machen mu:ssen, ist %%NLS%% vor
   jedem Pfad zu einer Message-Catalog-Datei in pkg-plist einzufu:gen. Zum
   Beispiel:

 %%NLS%%share/locale/fr/LC_MESSAGES/foobar.mo
 %%NLS%%share/locale/no/LC_MESSAGES/foobar.mo

   In sehr komplexen Fa:llen mu:ssen Sie eventuell fortgeschrittenere
   Techniken als die hier vorgestellte benutzen - wie z.B. Dynamische
   Packlistenerzeugung.

  6.5.3. Behandlung von Message-Catalog-Verzeichnissen

   Bei der Installation von Message-Catalog-Dateien gibt es einen Punkt zu
   beachten. Ihr Zielverzeichnis, das unter LOCALBASE/share/locale liegt,
   sollte nur selten von Ihrem Port erzeugt und gelo:scht werden. Die
   Verzeichnisse fu:r die gebra:uchlichsten Sprachen sind in
   /etc/mtree/BSD.local.dist aufgelistet; das heisst, sie sind Teil des
   Systems. Die Verzeichnisse fu:r viele andere Sprachen sind Teil des Ports
   devel/gettext. Sie wollen vielleicht dessen pkg-plist zur Hand nehmen, um
   festzustellen, ob Ihr Port eine Message-Catalog-Datei fu:r eine seltene
   Sprache installiert.

6.6. Die Benutzung von perl

   Wenn MASTER_SITES auf MASTER_SITE_PERL_CPAN gesetzt ist, dann ist der
   bevorzugte Wert von MASTER_SITE_SUBDIR der Top-Level-Name der Hierarchie.
   Zum Beispiel ist der empfohlene Wert fu:r p5-Module-Name-Module. Die
   Top-Level-Hierarchie kann unter cpan.org angeschaut werden. Dies sorgt
   dafu:r, dass der Port weiter funktioniert, wenn sich der Autor des Moduls
   a:ndert.

   Die Ausnahme dieser Regel ist, dass das entsprechende Verzeichnis selber
   oder das Distfile in diesem Verzeichnis nicht existiert. In solchen
   Fa:llen ist die Benutzung der Id des Autors als MASTER_SITE_SUBDIR
   erlaubt.

   Jede der Einstellungen unten kann sowohl auf YES als auch auf eine
   Versionszeichenkette wie 5.8.0+ gesetzt werden. Wenn YES benutzt wird,
   bedeutet das, dass der Port mit jeder der unterstu:tzten Perl-Versionen
   funktioniert. Falls ein Port nur mit einer bestimmten Perl-Version
   funktioniert, kann darauf mit einer Versionszeichenkette hingewiesen
   werden, die entweder eine Mindest- (z.B. 5.7.3+), Maximal- (z.B. 5.8.0-)
   oder Absolutversion (z.B. 5.8.3) festlegt.

   Tabelle 6.4. Variablen fu:r Ports, die perl benutzen

      Variable                             Bedeutung                          
   USE_PERL5       Bedeutet, dass der Port perl 5 zum Erstellen und zum       
                   Ausfu:hren benutzt.                                        
   USE_PERL5_BUILD Bedeutet, dass der Port perl 5 zum Erstellen benutzt.      
   USE_PERL5_RUN   Bedeutet, dass der Port perl 5 zur Laufzeit benutzt.       
                   Der gesamte Pfad zu perl 5 - entweder im Basissystem oder  
   PERL            nachinstalliert u:ber einen Port - ohne die                
                   Versionsnummer. Benutzen Sie diese Variable, wenn Sie "    
                   #!"-Zeilen in Skripten ersetzen mu:ssen.                   
   PERL_CONFIGURE  Perls MakeMaker fu:r die Konfiguration benutzen. Dies      
                   impliziert USE_PERL5.                                      
   PERL_MODBUILD   Module::Build fu:r configure, build und install benutzen.  
                   Dies impliziert PERL_CONFIGURE.                            

   Nur lesbare Variablen                      Bedeutung                       
   PERL_VERSION          Die volle Version des installierten perl (z.B.       
                         5.8.9).                                              
   PERL_LEVEL            Die installierte perl-Version als ein Integer der    
                         Form MNNNPP (z.B. 500809).                           
   PERL_ARCH             Wo perl architektur abha:ngige Bibliotheken ablegt.  
                         Vorgabe ist ${ARCH}-freebsd.                         
   PERL_PORT             Name des perl-Ports, der installiert ist (z.B.       
                         perl5).                                              
                         Verzeichnis, in das die Site-spezifischen            
   SITE_PERL             perl-Pakete kommen. Dieser Wert wird zu PLIST_SUB    
                         hinzugefu:gt.                                        

  Anmerkung:

   Ports von Perl-Modulen, die keine offizielle Webseite haben, sollen in der
   WWW-Zeile ihrer pkg-descr-Datei auf cpan.org verlinken. Die bevorzugte
   URL-Form ist http://search.cpan.org/dist/Module-Name/ (inklusive des Slash
   am Ende).

6.7. Benutzung von X11

  6.7.1. X.Org-Komponenten

   Die X11-Implementierung, welche die Ports-Sammlung bereitstellt, ist
   X.Org. Wenn Ihre Applikation von X-Komponenten abha:ngt, listen Sie die
   beno:tigten Komponenten in USE_XORG auf. Als dies geschrieben wurde,
   wurden die folgenden Komponenten bereitgestellt:

   bigreqsproto compositeproto damageproto dmx dmxproto evieproto fixesproto
   fontcacheproto fontenc fontsproto fontutil glproto ice inputproto kbproto
   libfs oldx printproto randrproto recordproto renderproto resourceproto
   scrnsaverproto sm trapproto videoproto x11 xau xaw xaw6 xaw7 xaw8 xbitmaps
   xcmiscproto xcomposite xcursor xdamage xdmcp xevie xext xextproto
   xf86bigfontproto xf86dgaproto xf86driproto xf86miscproto xf86rushproto
   xf86vidmodeproto xfixes xfont xfontcache xft xi xinerama xineramaproto
   xkbfile xkbui xmu xmuu xorg-server xp xpm xprintapputil xprintutil xpr oto
   xproxymngproto xrandr xrender xres xscrnsaver xt xtrans xtrap xtst xv xvmc
   xxf86dga xxf86misc xxf86vm.

   Die aktuelle Liste finden Sie immer in /usr/ports/Mk/bsd.xorg.mk.

   Das Mesa Projekt ist ein Versuch, eine freie OpenGL Implementierung
   bereitzustellen. Sie ko:nnen eine Abha:ngigkeit von verschiedenen
   Komponenten diese Projektes in der Variable USE_GL spezifizieren.
   ouml;gliche Optionen sind: glut, glu, glw, glew, gl und linux. Fu:r
   Abwa:rtskompatibilita:t gilt der Wert yes als glu.

   Beispiel 6.1. Beispiel fu:r USE_XORG

 USE_XORG=   xrender xft xkbfile xt xaw
 USE_GL=     glu

   Viele Ports definieren USE_XLIB, was dafu:r sorgt, dass der Port von allen
   (rund 50) Bibliotheken abha:ngt. Diese Variable existiert, um
   Abwa:rtskompatibilita:t sicherzustellen (sie stammt noch aus der Zeit vor
   dem modularem X.Org), und sollte bei neuen Ports nicht mehr benutzt
   werden.

   Tabelle 6.5. Variablen fu:r Ports, die X benutzen

                Der Port benutzt die X-Bibliotheken. Soll nicht mehr          
   USE_XLIB     verwendet werden - benutzen Sie stattdessen eine Liste von    
                Komponenten in USE_XORG.                                      
   USE_X_PREFIX Soll nicht mehr benutzt werden, ist jetzt a:quivalent zu      
                USE_XLIB und kann einfach durch letzteres ersetzt werden.     
   USE_IMAKE    Der Port benutzt imake. Impliziert USE_X_PREFIX.              
   XMKMF        Ist auf den Pfad zu xmkmf gesetzt, wenn nicht in PATH.        
                Vorgabe ist xmkmf -a.                                         

   Tabelle 6.6. Variablen bei Abha:ngigkeit von einzelnen Teilen von X11

                          Ein Port, der imake und einige andere Werkzeuge,    
   X_IMAKE_PORT           die zum Erstellen von X11 benutzt werden,           
                          bereitstellt.                                       
   X_LIBRARIES_PORT       Ein Port, der die X11-Bibliotheken bereitstellt.    
   X_CLIENTS_PORT         Ein Port, der X11-Clients bereitstellt.             
   X_SERVER_PORT          Ein Port, der den X11-Server bereitstellt.          
   X_FONTSERVER_PORT      Ein Port, der den Fontserver bereitstellt.          
   X_PRINTSERVER_PORT     Ein Port, der den Printserver bereitstellt.         
   X_VFBSERVER_PORT       Ein Port, der den virtuellen Framebuffer-Server     
                          bereitstellt.                                       
   X_NESTSERVER_PORT      Ein Port, der einen nested X-Server bereitstellt.   
   X_FONTS_ENCODINGS_PORT Ein Port, der Kodierungen fu:r Schriftarten         
                          bereitstellt.                                       
   X_FONTS_MISC_PORT      Ein Port, der verschiedene Bitmap-Schriftarten      
                          bereitstellt.                                       
   X_FONTS_100DPI_PORT    Ein Port, der 100dpi Bitmap-Schriftarten            
                          bereitstellt.                                       
   X_FONTS_75DPI_PORT     Ein Port, der 75dpi Bitmap-Schriftarten             
                          bereitstellt.                                       
   X_FONTS_CYRILLIC_PORT  Ein Port, der kyrillische Bitmap-Schriftarten       
                          bereitstellt.                                       
   X_FONTS_TTF_PORT       Ein Port, der TrueType(R)-Schriftarten              
                          bereitstellt.                                       
   X_FONTS_TYPE1_PORT     Ein Port, der Type1-Schriftarten bereitstellt.      
   X_MANUALS_PORT         Ein Port, der entwicklerorientierte Manualpages     
                          bereitstellt.                                       

   Beispiel 6.2. Benutzung von X11-bezogenen Variablen in einem Port

 # Port benutzt X11-Bibliotheken und ha:ngt vom Font-Server sowie
 # von kyrillischen Schriftarten ab.
 RUN_DEPENDS=   ${LOCALBASE}/bin/xfs:${X_FONTSERVER_PORT} \
                ${LOCALBASE}/lib/X11/fonts/cyrillic/crox1c.pcf.gz:${X_FONTS_CYRILLIC_PORT}

 USE_XORG=      x11 xpm

  6.7.2. Ports, die Motif beno:tigen

   Wenn Ihr Port eine Motif-Bibliothek beno:tigt, definieren Sie USE_MOTIF im
   Makefile. Die Standard-Motif-Implementierung ist x11-toolkits/open-motif.
   Benutzer ko:nnen stattdessen x11-toolkits/lesstif wa:hlen, indem Sie die
   WANT_LESSTIF-Variable setzen.

   Die Variable MOTIFLIB wird von bsd.port.mk auf die entsprechende
   Motif-Bibliothek gesetzt. Bitte patchen Sie den Quelltext Ihres Ports,
   sodass er u:berall ${MOTIFLIB} benutzt, wo die Motif-Bibliothek im
   Original Makefile oder Imakefile referenziert wird.

   Es gibt zwei verbreitete Fa:lle:

     * Wenn sich der Port in seinem Makefile oder Imakefile auf die
       Motif-Bibliothek als -lXm bezieht, ersetzen Sie das einfach durch
       ${MOTIFLIB}.

     * Wenn der Port in seinem Imakefile XmClientLibs benutzt, ersetzen Sie
       das durch ${MOTIFLIB} ${XTOOLLIB} ${XLIB}.

   Anmerkung: MOTIFLIB expandiert (normalerweise) zu -L/usr/X11R6/lib -lXm
   oder /usr/X11R6/lib/libXm.a - d.h. Sie mu:ssen kein -L oder -l davor
   einfu:gen.

  6.7.3. X11 Schriftarten

   Wenn Ihr Port Schriftarten fu:r das X-Window-System installiert, legen Sie
   diese nach LOCALBASE/lib/X11/fonts/local.

  6.7.4. Erzeugen eines ku:nstlichen DISPLAY durch Xvfb

   Manche Applikationen beno:tigen ein funktionierendes X11-Display, damit
   die Kompilierung funktioniert. Das stellt fu:r Systeme, die ohne Display
   laufen, ein Problem dar. Wenn die folgende Variable benutzt wird, startet
   die Bauumgebung den virtuellen Framebuffer-X-Server, und ein
   funktionierendes DISPLAY wird dem Build u:bergeben.

 USE_DISPLAY=  yes

  6.7.5. Desktop-Eintra:ge

   Desktop-Eintra:ge (Freedesktop Standard) ko:nnen in Ihrem Port einfach
   u:ber die DESKTOP_ENTRIES-Variable erzeugt werden. Diese Eintra:ge
   erscheinen dann im Applikationsmenu: von standardkonformen
   Desktop-Umgebungen wie GNOME oder KDE. Die .desktop-Datei wird dann
   automatisch erzeugt, installiert und der pkg-plist hinzugefu:gt. Die
   Syntax ist:

 DESKTOP_ENTRIES=  "NAME" "COMMENT" "ICON" "COMMAND" "CATEGORY" StartupNotify

   Die Liste der mo:glichen Kategorien ist auf der Freedesktop Webseite
   abrufbar. StartupNotify zeigt an, ob die Applikation den Status in
   Umgebungen, die Startup-Notifications kennen, lo:schen wird.

   Beispiel:

 DESKTOP_ENTRIES=  "ToME" "Roguelike game based on JRR Tolkien's work" \
                   "${DATADIR}/xtra/graf/tome-128.png" \
                   "tome -v -g" "Application;Game;RolePlaying;" \
                   false

6.8. Benutzung von GNOME

   Das FreeBSD/GNOME-Projekt benutzt seine eigene Gruppe von Variablen, um zu
   definieren, welche GNOME-Komponenten ein bestimmter Port benutzt. Eine
   umfassende Liste dieser Variablen existiert innerhalb der Webseite des
   FreeBSD/GNOME-Projektes.

6.9. Benutzung von Qt

  6.9.1. Ports, die Qt beno:tigen

   Tabelle 6.7. Variablen fu:r Ports, die Qt beno:tigen

                 Der Port benutzt das Qt-Toolkit. Mo:gliche Werte sind 3 und  
   USE_QT_VER    4; diese spezifizieren die Major Version von Qt, die benutzt 
                 werden soll. Entsprechende Parameter werden an das           
                 configure-Skript und make u:bergeben.                        
   QT_PREFIX     Entha:lt den Pfad, wohin Qt installiert ist (nur lesbare     
                 Variable).                                                   
   MOC           Entha:lt den Pfad von moc (nur lesbare Variable).            
                 Voreingestellt entsprechend des USE_QT_VER-Werts.            
                 Zusa:tzliche Compiler-Flags, die u:ber CONFIGURE_ENV an das  
   QTCPPFLAGS    Qt-Toolkit u:bergeben werden. Voreingestellt entsprechend    
                 des USE_QT_VER-Wertes.                                       
                 Zusa:tzliche Bibliotheken, die u:ber CONFIGURE_ENV fu:r das  
   QTCFGLIBS     Qt-Toolkit gelinkt werden sollen. Voreingestellt             
                 entsprechend des USE_QT_VER-Wertes.                          
   QTNONSTANDARD A:nderungen von CONFIGURE_ENV, CONFIGURE_ARGS und MAKE_ENV   
                 sollen unterdru:ckt werden.                                  

   Tabelle 6.8. Zusa:tzliche Variablen fu:r Ports, die Qt 4.xi benutzen

   QT_COMPONENTS Spezifiziert Tool- und Bibliothek-Abha:ngigkeiten fu:r Qt4.  
                 Siehe unten fu:r Details.                                    
   UIC           Entha:lt den Pfad von uic (nur lesbare Variable).            
                 Voreingestellt entsprechend des USE_QT_VER-Wertes.           
   QMAKE         Entha:lt den Pfad von qmake (nur lesbare Variable).          
                 Voreingestellt entsprechend des USE_QT_VER-Wertes.           
                 Entha:lt den Pfad der Konfigurationsdatei fu:r qmake (nur    
   QMAKESPEC     lesbare Variable). Voreingestellt entsprechend des           
                 USE_QT_VER-Wertes.                                           

   Wenn USE_QT_VER gesetzt ist, werden dem configure-Skript einige nu:tzliche
   Einstellungen u:bergeben:

 CONFIGURE_ARGS+= --with-qt-includes=${QT_PREFIX}/include \
                  --with-qt-libraries=${QT_PREFIX}/lib \
                  --with-extra-libs=${LOCALBASE}/lib \
                  --with-extra-includes=${LOCALBASE}/include
 CONFIGURE_ENV+=  MOC="${MOC}" CPPFLAGS="${CPPFLAGS} ${QTCPPFLAGS}" LIBS="${QTCFGLIBS}" \
                  QTDIR="${QT_PREFIX}" KDEDIR="${KDE_PREFIX}"

   Wenn USE_QT_VER auf 4 gesetzt ist, werden auch die folgenden Einstellungen
   u:bergeben:

 CONFIGURE_ENV+= UIC="${UIC}" QMAKE="${QMAKE}" QMAKESPEC="${QMAKESPEC}"
 MAKE_ENV+=      QMAKESPEC="${QMAKESPEC}"

  6.9.2. Komponentenauswahl (nur bei Qt 4.x)

   Wenn USE_QT_VER auf 4 gesetzt ist, ko:nnen individuelle Qt4-Tool- und
   Bibliotheksabha:ngigkeiten in der Variable QT_COMPONENTS angegeben werden.
   An jede Komponente kann _build oder _run als Suffix angeha:ngt werden, was
   eine Abha:ngigkeit zur Build- bzw. Laufzeit angibt. Ohne Suffix gilt die
   Abha:ngigkeit sowohl zur Build- als auch zur Laufzeit.
   Bibliothekskomponenten sollten normalerweise ohne Suffix angegeben werden,
   Tool-Komponenten mit _build und Plugin-Komponenten mit _run. Die
   gebra:uchlichsten Komponenten werden im Folgenden angegeben (alle
   verfu:gbaren Komponenten sind in _QT_COMPONENTS_ALL in
   /usr/ports/Mk/bsd.qt.mk aufgelistet):

   Tabelle 6.9. Verfu:gbare Qt4-Bibliothekskomponenten

      Name                             Beschreibung                           
   corelib    Kern-Bibliothek (kann weggelassen werden- es sei denn, der Port 
              benutzt nichts ausser corelib)                                  
   gui        Graphische Benutzeroberfla:chen-Bibliothek                      
   network    Netzwerk-Bibliothek                                             
   opengl     OpenGL-Bibliothek                                               
   qt3support Qt3-Kompatibilita:ts-Bibliothek                                 
   qtestlib   Modultest-Bibliothek                                            
   script     Skript-Bibliothek                                               
   sql        SQL-Bibliothek                                                  
   xml        XML-Bibliothek                                                  

   Sie ko:nnen herausfinden, welche Bibliotheken die Applikation beno:tigt,
   indem Sie nach erfolgreicher Kompilierung ldd auf die Hauptbina:rdatei
   anwenden.

   Tabelle 6.10. Verfu:gbare Qt4-Tool-Komponenten

   Name                              Beschreibung                             
   moc   meta object compiler (wird zum Build fast jeder Qt-Applikation       
         beno:tigt)                                                           
   qmake Makefile-Generator / Build-Werkzeug                                  
   rcc   Resource-Compiler (wird beno:tigt, falls die Applikation *.rc oder   
         *.qrc Dateien entha:lt)                                              
         User-Interface-Compiler (wird beno:tigt, falls die Applikation von   
   uic   Qt-Designer erzeugte *.ui Dateien entha:lt - gilt fu:r praktisch     
         jede Qt-Applikation mit einer GUI)                                   

   Tabelle 6.11. Verfu:gbare Qt4-Plugin-Komponenten

       Name                             Beschreibung                          
   iconengines  SVG-Icon-Engine Plugin (wenn die Applikation SVG-Icons        
                mitliefert)                                                   
   imageformats Bildformatplugins fu:r GIF, JPEG, MNG und SVG (wenn die       
                Applikation Bilddateien mitliefert)                           

   Beispiel 6.3. Qt4-Komponenten auswa:hlen

   In diesem Beispiel benutzt die portierte Applikation die Qt4
   GUI-Bibliothek, die Qt4-Core-Bibliothek, alle Qt4-Codeerzeugungstools und
   Qt4's Makefile Generator. Da die GUI-Bibliothek eine Abha:ngigkeit von der
   Core-Bibliothek impliziert, muss corelib nicht angegeben werden. Die
   Qt4-Codeerzeugungstools moc, uic und rcc, sowie der Makefile Generator
   qmake werden nur fu:r den Build beno:tigt, deshalb bekommen die den Suffix
   _build:

 USE_QT_VER=    4
 QT_COMPONENTS= gui moc_build qmake_build rcc_build uic_build

  6.9.3. Zusa:tzliche Besonderheiten

   Wenn die Applikation keine configure Datei, sondern eine .pro Datei hat,
   ko:nnen Sie das Folgende benutzen:

 HAS_CONFIGURE=    yes

 do-configure:
         @cd ${WRKSRC} && ${SETENV} ${CONFIGURE_ENV} \
                 ${QMAKE} -unix PREFIX=${PREFIX} texmaker.pro

   Beachten Sie die A:hnlichkeit mit der qmake-Zeile im mitgelieferten
   BUILD.sh-Skript. Die U:bergabe von CONFIGURE_ENV stellt sicher, dass qmake
   die QMAKESPEC-Variable u:bergeben bekommt, ohne die es nicht funktioniert.
   qmake erzeugt Standard-Makefiles, sodass es nicht no:tig ist ein eigenes
   neues build-Target zu schreiben.

   Qt-Applikationen sind oft so geschrieben, dass sie plattformu:bergreifend
   sind, und oft ist X11/Unix nicht die Plattform, auf der sie entwickelt
   werden. Das sorgt oft fu:r bestimmte fehlende Kleinigkeiten wie z.B.:

     * Fehlende zusa:tzliche Include-Pfade. Viele Applikationen kommen mit
       System-Tray-Icon Support- unterlassen es aber Includes oder
       Bibliotheken in den X11 Verzeichnissen zu suchen. Sie ko:nnen qmake
       u:ber die Kommandozeile sagen, es soll Verzeichnisse zu den Include-
       und Bibliotheks-Suchpfaden hinzufu:gen - z.B.:

 ${QMAKE} -unix PREFIX=${PREFIX} INCLUDEPATH+=${LOCALBASE}/include \
     LIBS+=-L${LOCALBASE}/lib sillyapp.pro

     * Falsche Installations-Pfade. Manchmal werden Daten wie Icons oder
       .desktop-Dateien per Vorgabe in Verzeichnisse installiert, die nicht
       von XDG-kompatiblen Applikationen durchsucht werden. editors/texmaker
       ist hierfu:r ein Beispiel- siehe patch-texmaker.pro im
       files-Verzeichnis dieses Ports als eine Vorlage, die zeigt, wie man
       dies direkt in der Qmake Projektdatei lo:st.

6.10. Benutzung von KDE

  6.10.1. Variablen-Definitionen (KDE 3)

   Tabelle 6.12. Variablen fu:r Ports, die KDE 3 benutzen

                   Der Port benutzt KDE-Bibliotheken. Die Variable            
   USE_KDELIBS_VER spezifiziert die Major Version von KDE, die benutzt werden 
                   soll, und impliziert USE_QT_VER der entsprechenden         
                   Version. Der einzig mo:gliche Wert ist 3.                  
                   Der Port benutzt die KDE-Base. Die Variable spezifiziert   
   USE_KDEBASE_VER die Major Version von KDE, die benutzt werden soll, und    
                   impliziert USE_QT_VER der entsprechenden Version. Der      
                   einzig mo:gliche Wert ist 3.                               

  6.10.2. Variablen-Definitionen (KDE 4)

   Falls Ihre Anwendung von KDE 4 abha:ngt, weisen Sie USE_KDE4 eine Liste
   mit beno:tigten Komponenten zu. Die am ha:ufigsten gebrauchten sind unten
   aufgelistet (_USE_KDE4_ALL in /usr/ports/Mk/bsd.kde4.mk entha:lt stets die
   aktuelle Liste):

   Tabelle 6.13. Verfu:gbare KDE 4-Komponenten

     Name                              Beschreibung                           
   akonadi   Personal Information Management (PIM)-Speicherdienst             
   automoc4  La:sst den Port das Bauwerkzeug automoc4 verwenden.              
   kdebase   Grundlegende KDE-Anwendungen (Konqueror, Dolphin, Konsole)       
   kdeexp    Experimentelle KDE-Bibliotheken (mit einer API, die als          
             non-stable eingestuft ist)                                       
   kdehier   Stellt allgemeine KDE-Verzeichnisse bereit                       
   kdelibs   Die grundlegenden KDE-Bibliotheken                               
   kdeprefix Falls in der Liste vorhanden, wird der Port unter ${KDE4_PREFIX} 
             statt ${LOCALBASE} installiert                                   
   pimlibs   PIM-Bibliotheken                                                 
   workspace Anwendungen und Bibliotheken, welche die Desktopumgebung         
             gestalten (Plasma, KWin)                                         

   KDE 4-Ports werden unter ${KDE4_PREFIX}, zur Zeit /usr/local/kde4,
   installiert, um Konflikte mit KDE 3-Ports zu verhindern. Dies wird durch
   Auflisten der Komponente kdeprefix erreicht, welche die standardma:ssig
   gesetzte Variable PREFIX u:berschreibt. Die Ports u:bernehmen jedoch,
   jeden u:ber die Umgebungsvariable MAKEFLAGS oder make-Parameter
   festgelegten Wert fu:r PREFIX.

   Es ko:nnte bei der Installation von KDE 4-Ports zu Konflikten mit KDE
   3-Ports kommen, sodass diese bei aktivierter kdeprefix-Komponente unter
   ${KDE4_PREFIX} installiert werden. Der Standardwert von KDE4_PREFIX ist
   zur Zeit /usr/local/kde4. Es ist auch mo:glich, KDE 4-Ports unter einem
   angepassten PREFIX zu installieren. Wenn PREFIX als
   MAKEFLAGS-Umgebungsvariable oder als make-Parameter gesetzt wird,
   u:berschreibt dies den von kdeprefix festgelegten Wert.

   Beispiel 6.4. USE_KDE4-Beispiel

   Dies ist ein einfaches Beispiel fu:r einen KDE 4-Port. USE_CMAKE weist den
   Port an, CMake, ein unter KDE 4-Projekten weit verbreitetes
   Konfigurationswerkzeug, zu verwenden. USE_KDE4 legt die Abha:ngigkeit von
   KDE-Bibliotheken und die Verwendung von automoc4 wa:hrend der Kompilierung
   fest. Mit Hilfe des configure-Protokolls ko:nnen die KDE-Komponenten und
   andere Abha:ngigkeiten festgestellt werden. USE_KDE4 impliziert USE_QT_VER
   nicht. Falls der Port Qt 4-Komponenten beno:tigt, sollten USE_QT_VER
   gesetzt und verlangte Komponenten festgelegt werden.

 USE_CMAKE=     yes
 USE_KDE4=      automoc4 kdelibs kdeprefix
 USE_QT_VER=    4
 QT_COMPONENTS= qmake_build moc_build rcc_build uic_build

6.11. Benutzung von Java

  6.11.1. Variablen-Definitionen

   Wenn Ihr Port ein Java(TM) Development Kit (JDK(TM)) beno:tigt, entweder
   zum Bauen, zur Laufzeit oder sogar, um das Distfile auszupacken, dann
   sollten Sie USE_JAVA setzen.

   Es gibt mehrere JDKs in der Ports-Sammlung- von verschiedenen Anbietern
   und in verschiedenen Versionen. Wenn Ihr Port eine bestimmte dieser
   Versionen beno:tigt, ko:nnen Sie definieren welche. Die aktuelle Version
   ist java/jdk16.

   Tabelle 6.14. Variablen, die von Ports, die Java benutzen, gesetzt werden
   mu:ssen

     Variable                             Bedeutung                           
   USE_JAVA     Sollte definiert sein, damit die u:brigen Variablen           
                irgendeinen Effekt haben.                                     
                Durch Leerzeichen getrennte Liste von geeigneten              
   JAVA_VERSION Java-Versionen fu:r den Port. Ein optionales "+" ermo:glicht  
                die Angabe eines Bereiches von Versionen (mo:gliche Werte:    
                1.5[+] 1.6[+] 1.7[+]).                                        
                Durch Leerzeichen getrennte Liste von geeigneten              
   JAVA_OS      JDK-Port-Betriebssystemen fu:r den Port. (erlaubte Werte:     
                native linux).                                                
                Durch Leerzeichen getrennte Liste von geeigneten              
   JAVA_VENDOR  JDK-Port-Anbietern fu:r den Port. (erlaubte Werte: freebsd    
                bsdjava sun openjdk).                                         
   JAVA_BUILD   Bedeutet, falls gesetzt, dass der ausgewa:hlte JDK-Port zu    
                den Build-Abha:ngigkeiten des Ports hinzugefu:gt werden soll. 
                Bedeutet, falls gesetzt, dass der ausgewa:hlte JDK-Port zu    
   JAVA_RUN     den Laufzeit-Abha:ngigkeiten des Ports hinzugefu:gt werden    
                soll.                                                         
                Bedeutet, falls gesetzt, dass der ausgewa:hlte JDK-Port zu    
   JAVA_EXTRACT den Extract-Abha:ngigkeiten des Ports hinzugefu:gt werden     
                soll.                                                         

   Das Folgende ist eine Liste aller Variablen, die ein Port bekommt, nachdem
   er USE_JAVA gesetzt hat:

   Tabelle 6.15. Bereitgestellte Variablen fu:r Ports, die Java benutzen

          Variable                                   Wert                          
JAVA_PORT                    Der Name des JDK-Ports (z.B. 'java/diablo-jdk16').    
                             Die volle Version des JDK Ports (z.B. '1.6.0'). Wenn  
JAVA_PORT_VERSION            Sie nur die ersten beiden Stellen dieser              
                             Versionsnummer beno:tigen, benutzen Sie               
                             ${JAVA_PORT_VERSION:C/^([0-9])\.([0-9])(.*)$/\1.\2/}. 
JAVA_PORT_OS                 Das vom JDK-Port benutzte Betriebssystem (z.B.        
                             'native').                                            
JAVA_PORT_VENDOR             Der Anbieter des JDK-Ports (z.B. 'freebsd').          
JAVA_PORT_OS_DESCRIPTION     Beschreibung des vom JDK-Port benutzten               
                             Betriebssystems (z.B. 'Native').                      
JAVA_PORT_VENDOR_DESCRIPTION Beschreibung des Anbieters des JDK-Ports (z.B.        
                             'FreeBSD Foundation').                                
JAVA_HOME                    Pfad zum Installationsverzeichnis des JDK (z.B.       
                             '/usr/local/diablo-jdk1.6.0').                        
JAVAC                        Pfad zum Java-Compiler, der benutzt werden soll (z.B. 
                             '/usr/local/diablo-jdk1.6.0/bin/javac'.               
                             Pfad zum jar-Werkzeug, das benutzt werden soll        
JAR                          (z.B.''/usr/local/diablo-jdk1.6.0/bin/jar oder        
                             '/usr/local/bin/fastjar').                            
APPLETVIEWER                 Pfad zum appletviewer-Werkzeug (z.B.                  
                             '/usr/local/diablo-jdk1.6.0/bin/appletviewer').       
                             Pfad zur java Bina:rdatei. Benutzen Sie dies, um      
JAVA                         Java-Programme auszufu:hren                           
                             (z.B.'/usr/local/diablo-jdk1.6.0/bin/java').          
JAVADOC                      Pfad zum javadoc-Werkzeug.                            
JAVAH                        Pfad zum javah-Programm.                              
JAVAP                        Pfad zum javap-Programm.                              
JAVA_KEYTOOL                 Pfad zum keytool-Werkzeug.                            
JAVA_N2A                     Pfad zum native2ascii-Werkzeug.                       
JAVA_POLICYTOOL              Pfad zum policytool Programm.                         
JAVA_SERIALVER               Pfad zum serialver-Werkzeug.                          
RMIC                         Pfad zum RMI Stub/Skeleton-Generator, rmic.           
RMIREGISTRY                  Pfad zum RMI Registry-Werkzeug, rmiregistry.          
RMID                         Pfad zum RMI Daemon rmid.                             
JAVA_CLASSES                 Pfad zum Archiv, das die JDK-Klassendateien entha:lt, 
                             ${JAVA_HOME}/jre/lib/rt.jar.                          

   Sie ko:nnen das java-debug make-Target benutzen, um Information zum
   Debuggen Ihres Ports zu erhalten. Es wird die Werte vieler der
   obenangegebenen Variablen anzeigen.

   Zusa:tzlich sind die folgenden Konstanten definiert, damit alle Java-Ports
   auf eine konsistente Art installiert werden ko:nnen:

   Tabelle 6.16. Konstanten, die fu:r Ports, welche Java benutzen, definiert
   sind

    Konstante                               Wert                              
   JAVASHAREDIR Das Basis-Verzeichnis fu:r alles, was mit Java                
                zusammenha:ngt. Standardma:ssig ${PREFIX}/share/java.         
   JAVAJARDIR   Das Verzeichnis, wohin JAR-Dateien installiert werden sollen. 
                Standardma:ssig ${JAVASHAREDIR}/classes.                      
                Das Verzeichnis, in dem JAR-Dateien, die von anderen Ports    
   JAVALIBDIR   installiert wurden, liegen. Standardma:ssig                   
                ${LOCALBASE}/share/java/classes.                              

   Die entsprechenden Eintra:ge sind sowohl in PLIST_SUB (dokumentiert in
   Abschnitt 7.1, "A:nderungen an pkg-plist mit Hilfe von make-Variablen")
   als auch in SUB_LIST definiert.

  6.11.2. Kompilieren mit Ant

   Wenn der Port mit Apache Ant kompiliert werden soll, muss er USE_ANT
   setzen. Ant wird dann als das sub-make-Kommando betrachtet. Wenn kein
   do-build-Target vom Port definiert ist, wird eine Standardvorgabe benutzt,
   die einfach Ant entsprechend MAKE_ENV, MAKE_ARGS und ALL_TARGET aufruft.
   Das a:hnelt dem USE_GMAKE-Mechanismus, der in Abschnitt 6.3,
   "Build-Mechanismen" dokumentiert ist.

  6.11.3. Optimales Verfahren

   Wenn Sie eine Java-Bibliothek portieren, sollte Ihr Port die JAR-Datei(en)
   in ${JAVAJARDIR} installieren, und alles andere unter
   ${JAVASHAREDIR}/${PORTNAME} (ausgenommen die Dokumentation - siehe unten).
   Um die Gro:sse der Packlistendatei zu reduzieren, ko:nnen die
   JAR-Datei(en) direkt im Makefile angegeben werden. Benutzen Sie einfach
   die folgende Anweisung (wobei myport.jar der Name der JAR-Datei ist, die
   als Teil des Ports installiert wird):

 PLIST_FILES+= %%JAVAJARDIR%%/myport.jar

   Beim Portieren einer Java-Applikation installiert der Port normalerweise
   alles unter einem einzigen Verzeichnis (inklusive seiner
   JAR-Abha:ngigkeiten). Die Benutzung von ${JAVASHAREDIR}/${PORTNAME} wird
   in dieser Beziehung dringend empfohlen. Es liegt im Entscheidungsbereich
   des Portierenden, ob der Port die zusa:tzlichen JAR-Abha:ngigkeiten unter
   diesem Verzeichnis installieren oder direkt die schon installierten (aus
   ${JAVAJARDIR}) benutzen soll.

   Unabha:ngig von der Art Ihres Ports (Bibliothek oder Applikation), sollte
   die zusa:tzliche Dokumentation an die gleiche Stelle installiert werden
   wie bei jedem anderen Port auch. Das JavaDoc-Werkzeug ist dafu:r bekannt
   einen unterschiedlichen Satz von Dateien abha:ngig von der Version des
   benutzten JDKs zu erstellen. Fu:r Ports, die nicht die Benutzung eines
   bestimmten JDKs vorgeben, ist es deshalb eine komplexe Aufgabe die
   Packliste (pkg-plist) festzulegen. Dies ist ein Grund, warum dringend
   angeraten wird, das PORTDOCS-Makro zu benutzen. Ausserdem, selbst wenn Sie
   den Satz von Dateien, den javadoc erzeugen wird, voraussagen ko:nnen, die
   Gro:sse der resultierenden pkg-plist befu:rwortet die Benutzung von
   PORTDOCS.

   Der Vorgabewert fu:r DATADIR ist ${PREFIX}/share/${PORTNAME}. Es ist eine
   gute Idee, DATADIR fu:r Java-Ports stattdessen auf
   ${JAVASHAREDIR}/${PORTNAME} zu setzen. In der Tat wird DATADIR automatisch
   zu PLIST_SUB (dokumentiert in Abschnitt 7.1, "A:nderungen an pkg-plist mit
   Hilfe von make-Variablen") hinzugefu:gt, d.h. Sie ko:nnen %%DATADIR%%
   direkt in pkg-plist benutzen.

   Zu der Frage, ob Java-Ports aus dem Quelltext gebaut werden, oder direkt
   bereitgestellte bina:re Distributionen benutzt werden sollten, gab es, als
   dies geschrieben wurde, keine definierte Richtlinie. Allerdings ermutigen
   Mitglieder des FreeBSD Java-Projekts Porter dazu, Ihre Ports aus dem
   Quelltext kompilieren zu lassen, wann immer dies kein Problem darstellt.

   Alle Eigenschaften, die in diesem Abschnitt pra:sentiert wurden sind in
   bsd.java.mk implementiert. Sollten Sie jemals der Meinung sein, dass Ihr
   Port ausgefeiltere Java-Unterstu:tzung beno:tigt, schauen Sie bitte erst
   in das bsd.java.mk CVS Log, weil es normalerweise immer etwas Zeit braucht
   bis die neuesten Eigenschaften dokumentiert sind. Wenn Sie glauben, dass
   der fehlende Support auch fu:r viele andere Java Ports nu:tzlich sein
   ko:nnte, wenden Sie sich bitte an die FreeBSD Java Language.

   Obwohl es eine java-Kategorie fu:r Fehlerberichte gibt, bezieht sich diese
   auf die JDK-Portierungsbemu:hungen des FreeBSD Java-Projektes. Deshalb
   sollten Sie Ihren Java-Port in der ports-Kategorie einreichen wie bei
   jeden anderen Port auch - es sei denn, die Angelegenheit, die Sie zu
   kla:ren versuchen, steht in Zusammenhang entweder mit einer
   JDK-Implementierung oder bsd.java.mk.

   Gleichermassen gibt es eine definierte Richtlinie fu:r die CATEGORIES
   eines Java-Ports, die in Abschnitt 5.3, "Kategorisierung" erkla:rt wird.

6.12. Webanwendungen, Apache und PHP

  6.12.1. Apache

   Tabelle 6.17. Variablen fu:r Ports, die Apache verwenden

                    Der Port beno:tigt Apache. Mo:gliche Werte: yes           
   USE_APACHE       (beliebige Version), 1.3, 2.0, 2.2, 2.0+, etc. - Standard 
                    ist Version 1.3.                                          
                    Der Port beno:tigt Apache 2.0. Ist diese Variable nicht   
   WITH_APACHE2     gesetzt, so beno:tigt der Port Apache 1.3. Diese Variable 
                    ist veraltet und sollte nicht mehr verwendet werden.      
   APXS             Vollsta:ndiger Pfad zu der apxs Bina:rdatei. Die Variable 
                    kann neu gesetzt werden.                                  
   HTTPD            Vollsta:ndiger Pfad zu der httpd Bina:rdatei. Die         
                    Variable kann neu gesetzt werden.                         
                    Beinhaltet die Versionsnummer des aktuell installierten   
   APACHE_VERSION   Apache (nur lesbare Variable). Diese Variable ist nach    
                    Einbinden der Datei bsd.port.pre.mk verfu:gbar. Mo:gliche 
                    Werte: 13, 20, 22.                                        
   APACHEMODDIR     Verzeichnis der Apache-Module. Diese Variable wird        
                    automatisch in pkg-plist ersetzt.                         
   APACHEINCLUDEDIR Verzeichnis der Apache Header-Dateien. Diese Variable     
                    wird automatisch in pkg-plist ersetzt.                    
   APACHEETCDIR     Verzeichnis der Apache-Konfigurationsdateien. Diese       
                    Variable wird automatisch in pkg-plist ersetzt.           

   Tabelle 6.18. Nu:tzliche Variablen fu:r Ports von Apache-Modulen

   MODULENAME    Name des Moduls. Standardwert ist PORTNAME. Beispiel:        
                 mod_hello                                                    
   SHORTMODNAME  Der geku:rzte Name des Moduls. Standardma:ssig wird der Wert 
                 von MODULENAME u:bernommen. Beispiel: hello                  
   AP_FAST_BUILD Verwende apxs zum Kompilieren und Installieren des Moduls.   
   AP_GENPLIST   Eine pkg-plist wird automatisch erzeugt.                     
   AP_INC        Verzeichnis fu:r zusa:tzliche Header-Dateien, die beim       
                 Kompilieren mitverwendet werden.                             
   AP_LIB        Verzeichnis fu:r zusa:tzliche Bibliothek-Dateien, welche     
                 beim Kompilieren mitverwendet werden.                        
   AP_EXTRAS     Zusa:tzliche Flags fu:r apxs.                                

  6.12.2. Webanwendungen

   Webanwendungen sollten nach PREFIX/www/programmname installiert werden.
   Der Einfachheit halber ist dieser Pfad sowohl im Makefile als auch in
   pkg-plist als WWWDIR verfu:gbar. Der relative Pfad PREFIX ist hingegen im
   Makefile durch die Variable WWWDIR_REL festgelegt.

   Der Benutzername und die Benutzergruppe, mit deren Rechte Webanwendungen
   laufen, sind in WWWOWN und WWWGRP festgelegt. Standardwert ist bei beiden
   www. Falls ein Port mit anderen Rechten gestartet werden soll, so sollte
   die Anweisung WWWOWN?= myuser verwendet werden. Dies vereinfacht dem
   Benutzer eine Anpassung dieser Werte.

   Falls die Webanwendung nicht explizit Apache beno:tigt, so sollte dieser
   auch nicht als Abha:ngigkeit des Ports aufgefu:hrt werden. Dadurch bleibt
   es dem Benutzer u:berlassen Apache oder einen anderen Webserver zu
   verwenden.

  6.12.3. PHP

   Tabelle 6.19. Variablen fu:r Ports, die PHP verwenden

                   Der Port beno:tigt PHP. Der Wert yes bewirkt eine          
   USE_PHP         Abha:ngigkeit des Ports von PHP. Es kann auch eine Liste   
                   der beno:tigten PHP-Erweiterungen angegeben werden.        
                   Beispiel: pcre xml gettext                                 
                   Legt die Version von PHP fest, die standardma:ssig         
   DEFAULT_PHP_VER installiert wird, falls noch kein PHP vorhanden ist.       
                   Standardwert ist 4. Mo:gliche Werte sind: 4,5              
   IGNORE_WITH_PHP Der Port funktioniert nicht mit der angegebenen Version    
                   von PHP. Mo:gliche Werte: 4, 5                             
   USE_PHPIZE      Der Port wird als PHP-Erweiterung gebaut.                  
                   Der Port wird wie eine PHP-Erweiterung                     
   USE_PHPEXT      behandelt - Installation und Eintragung in die             
                   PHP-Registry fu:r Erweiterungen.                           
   USE_PHP_BUILD   Setzt PHP als build-Anha:ngigkeit.                         
   WANT_PHP_CLI    Beno:tigt die Kommandozeilen-Version von PHP.              
   WANT_PHP_CGI    Beno:tigt die CGI-Version von PHP.                         
   WANT_PHP_MOD    Beno:tigt das Apache-Modul von PHP.                        
   WANT_PHP_SCR    Beno:tigt die Kommandozeilen- oder die CGI-Version von     
                   PHP.                                                       
   WANT_PHP_WEB    Beno:tigt das Apache-Modul oder die CGI-Version von PHP.   

  6.12.4. PEAR Module

   Das Portieren von PEAR-Modulen ist sehr einfach.

   Mit Hilfe der Variablen FILES, TESTS, DATA, SQLS, SCRIPTFILES, DOCS und
   EXAMPLES ko:nnen die zu installierenden Dateien angegeben werden. Alle
   aufgefu:hrten Dateien werden automatisch in die jeweiligen Verzeichnisse
   installiert und der Datei pkg-plist hinzugefu:gt.

   Die Datei ${PORTSDIR}/devel/pear/bsd.pear.mk muss am Ende des Makefiles
   eingebunden werden.

   Beispiel 6.5. Beispiel eines Makefiles fu:r eine PEAR Klasse

 PORTNAME=       Date
 PORTVERSION=    1.4.3
 CATEGORIES=     devel www pear

 MAINTAINER=     example@domain.com
 COMMENT=        PEAR Date and Time Zone Classes

 BUILD_DEPENDS=  ${PEARDIR}/PEAR.php:${PORTSDIR}/devel/pear-PEAR
 RUN_DEPENDS=    ${BUILD_DEPENDS}

 FILES=          Date.php Date/Calc.php Date/Human.php Date/Span.php     \
                 Date/TimeZone.php
 TESTS=          test_calc.php test_date_methods_span.php testunit.php   \
                 testunit_date.php testunit_date_span.php wknotest.txt   \
                 bug674.php bug727_1.php bug727_2.php bug727_3.php       \
                 bug727_4.php bug967.php weeksinmonth_4_monday.txt       \
                 weeksinmonth_4_sunday.txt weeksinmonth_rdm_monday.txt   \
                 weeksinmonth_rdm_sunday.txt
 DOCS=           TODO
 _DOCSDIR=       .

 .include <bsd.port.pre.mk>
 .include "${PORTSDIR}/devel/pear/bsd.pear.mk"
 .include <bsd.port.post.mk>

6.13. Python benutzen

   Die Ports unterstu:tzen parallele Installationen mehrerer
   Python-Versionen. Ports sollten sicherstellen, dass der richtige
   python-Interpreter verwendet wird - entsprechend der durch den Benutzer
   definierbaren Variable PYTHON_VERSION. Ha:ufig bedeutet dies, dass der
   Pfad zum python-Interpreter durch den Wert der Variablen PYTHON_CMD
   ersetzt werden muss.

   Ports, die Dateien unter PYTHON_SITELIBDIR installieren, sollten pyXY- als
   Pra:fix des Paketnamens haben, sodass in deren Paketname die zugeho:rige
   Python Version aufgefu:hrt wird.

 PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX}

   Tabelle 6.20. Nu:tzliche Variablen fu:r Ports, die Python verwenden

                           Der Port beno:tigt Python. Die minimal beno:tigte  
                           Version kann durch Werte wie 2.3+ angegeben        
   USE_PYTHON              werden. Bereiche von Versionsnummern ko:nnen durch 
                           Angabe der minimalen und maximalen Versionsnummer, 
                           getrennt durch einen Gedankenstrich, festgelegt    
                           werden, z.B.: 2.1-2.3                              
                           Verwende Python-distutils zum Konfigurieren,       
                           Kompilieren und Installieren. Dies ist             
                           erforderlich, falls der Port eine setup.py-Datei   
   USE_PYDISTUTILS         beinhaltet. Dadurch werden die do-build und        
                           do-install-Ziele und eventuell auch das            
                           do-configure-Ziel u:bergangen, falls GNU_CONFIGURE 
                           nicht definiert ist.                               
                           Wird als PKGNAMEPREFIX verwendet, um Pakete fu:r   
   PYTHON_PKGNAMEPREFIX    unterschiedliche Python-Versionen zu trennen.      
                           Beispiel: py24-                                    
                           Verzeichnis des site-Pakete Baums, der das         
                           Installationsverzeichnis von Python                
   PYTHON_SITELIBDIR       (u:blicherweise LOCALBASE) beinhaltet. Die         
                           PYTHON_SITELIBDIR-Variable kann sehr nu:tzlich bei 
                           der Installation von Python-Modulen sein.          
                           Die pra:fix-freie Variante von PYTHON_SITELIBDIR.  
                           Benutzen Sie immer %%PYTHON_SITELIBDIR%% in        
   PYTHONPREFIX_SITELIBDIR pkg-plist, wenn mo:glich. Der Standardwert von     
                           %%PYTHON_SITELIBDIR%% ist                          
                           lib/python%%PYTHON_VERSION%%/site-packages         
   PYTHON_CMD              Kommandozeilen-Interpreter fu:r Python mit         
                           Versionsnummer.                                    
   PYNUMERIC               Liste der Abha:ngigkeiten fu:r numerische          
                           Erweiterungen.                                     
                           Liste der Abha:ngigkeiten fu:r die neue numerische 
   PYNUMPY                 Erweiterung numpy. (PYNUMERIC ist vom Anbieter als 
                           veraltet deklariert)                               
                           Liste der Abha:ngigkeiten fu:r XML-Erweiterungen   
   PYXML                   (wird ab Python 2.0 nicht mehr beno:tigt, da im    
                           Basispaket enthalten).                             
                           Setzt die Abha:ngigkeit des Ports von twistedCore. 
   USE_TWISTED             Die Liste der erforderlichen Komponenten kann als  
                           Wert spezifiziert werden. Beispiel: web lore pair  
                           flow                                               
                           Setzt Zope, eine Plattform fu:r Webanwendungen,    
                           als Abha:ngigkeit des Ports. Setzt die             
   USE_ZOPE                Versionsabha:ngigkeit von Python auf 2.3. Setzt    
                           ZOPEBASEDIR auf das Verzeichnis, in welches Zope   
                           installiert wurde.                                 

   Eine vollsta:ndige Liste aller verfu:gbaren Variablen ist in
   /usr/ports/Mk/bsd.python.mk zu finden.

6.14. Benutzung von Tcl/Tk

   Die Ports-Sammlung unterstu:tzt die parallele Installation mehrerer
   Tcl/Tk-Versionen. Ports sollten mindestens die vorgegebene Tcl/Tk-Version
   oder ho:her zu unterstu:tzen versuchen anhand der Variablen USE_TCL und
   USE_TK. Es ist mo:glich, die gewu:nschte Version von tcl mit der Variable
   WITH_TCL_VER vorzuschreiben.

   Tabelle 6.21. A:usserst nu:tzliche Variablen fu:r Ports, die Tcl/Tk
   benutzen

                         Der Port beno:tigt die Tcl-Bibliothek (nicht die     
                         Shell). Eine notwendige Mindestversion kann mit      
   USE_TCL               Werten wie 84+ angegeben werden. Einzelne nicht      
                         unterstu:tzte Versionen ko:nnen mit der Variable     
                         INVALID_TCL_VER festgelegt werden.                   
   USE_TCL_BUILD         Der Port beno:tigt Tcl nur wa:hrend der Zeit, in der 
                         er gebaut wird.                                      
                         Ports, welche zwar die Tcl-Shell, aber nicht eine    
                         bestimmte Version von tclsh verlangen, sollten diese 
   USE_TCL_WRAPPER       neue Variable verwenden. Ein Wrapperskript fu:r      
                         tclsh wird auf dem System installiert. Der Benutzer  
                         kann festlegen, welche tcl-Shell gewu:nscht ist bzw. 
                         verwendet werden soll.                               
   WITH_TCL_VER          Benutzerdefinierte Variable, welche die gewu:nschte  
                         Tcl-Version bestimmt.                                
   PORTNAME_WITH_TCL_VER Gleich wie WITH_TCL_VER, nur portspezifisch.         
   USE_TCL_THREADS       Fordere threadfa:higes Tcl/Tk.                       
                         Der Port beno:tigt die Tk-Bibliothek (nicht die      
   USE_TK                Wish-Shell). Impliziert USE_TCL mit dem gleichen     
                         Wert. Fu:r weitere Informationen siehe die           
                         Beschreibung der Variable USE_TCL.                   
   USE_TK_BUILD          Analog zur Variable USE_TCL_BUILD.                   
   USE_TK_WRAPPER        Analog zur Variable USE_TCL_WRAPPER.                 
   WITH_TK_VER           Analog zur Variable WITH_TCL_VER und impliziert      
                         WITH_TCL_VER mit dem gleichen Wert.                  

   Eine vollsta:ndige Liste der zur Verfu:gung stehenden Variablen befindet
   sich in /usr/ports/Mk/bsd.tcl.mk.

6.15. Emacs benutzen

   Dieser Abschnitt muss noch geschrieben werden.

6.16. Ruby benutzen

   Tabelle 6.22. Nu:tzliche Variablen fu:r Ports, die Ruby verwenden

       Variable                            Description                        
   USE_RUBY         Der Port beno:tigt Ruby.                                  
   USE_RUBY_EXTCONF Der Port verwendet extconf.rb fu:r die Konfiguration.     
   USE_RUBY_SETUP   Der Port verwendet setup.rb fu:r die Konfiguration.       
   RUBY_SETUP       Legt den alternativen Namen von setup.rb fest. U:blich    
                    ist der Wert install.rb.                                  

   Die folgende Tabelle listet ausgewa:hlte Variablen auf, die Portautoren
   u:ber die Port-Infrastruktur zur Verfu:gung stehen. Diese Variablen
   sollten fu:r die Installation von Dateien in die entsprechenden
   Verzeichnisse verwendet werden. Sie sollten in pkg-plist so ha:ufig wie
   mo:glich verwendet und in einem Port nicht neu definiert werden.

   Tabelle 6.23. Ausgewa:hlte read-only-Variablen fu:r Ports, die Ruby
   verwenden

     Variable             Beschreibung                           Beispiel                     
                    Wird als PKGNAMEPREFIX                                                    
                    verwendet, um Pakete     
RUBY_PKGNAMEPREFIX  fu:r verschiedene        ruby18-
                    Versionen von Ruby zu    
                    unterscheiden.           
                    Vollsta:ndige Version                                                     
RUBY_VERSION        von Ruby in der Form     1.8.2
                    x.y.z.                   
                    Installationsverzeichnis                                                  
                    der von der              
RUBY_SITELIBDIR     Rechnerarchitektur       /usr/local/lib/ruby/site_ruby/1.8
                    unabha:ngigen            
                    Bibliotheken.            
                    Installationsverzeichnis                                                  
                    der von der              
RUBY_SITEARCHLIBDIR Rechnerarchitektur       /usr/local/lib/ruby/site_ruby/1.8/amd64-freebsd6
                    abha:ngigen              
                    Bibliotheken.            
                    Installationsverzeichnis                                                  
RUBY_MODDOCDIR      fu:r die Dokumentation   /usr/local/share/doc/ruby18/patsy
                    der Module.              
                    Installationsverzeichnis                                                  
RUBY_MODEXAMPLESDIR fu:r die Beispiele der   /usr/local/share/examples/ruby18/patsy
                    Module.                  

   Eine vollsta:ndige Liste der verfu:gbarenVariablen kann in
   /usr/ports/Mk/bsd.ruby.mk eingesehen werden.

6.17. SDL verwenden

   Die Variable USE_SDL wird fu:r die automatische Konfiguration der
   Abha:ngigkeiten fu:r Ports benutzt, die auf SDL basierende Bibliotheken
   wie devel/sdl12 und x11-toolkits/sdl_gui verwenden.

   Die folgenden SDL-Bibliotheken sind derzeit bekannt:

     * sdl: devel/sdl12

     * gfx: graphics/sdl_gfx

     * gui: x11-toolkits/sdl_gui

     * image: graphics/sdl_image

     * ldbad: devel/sdl_ldbad

     * mixer: audio/sdl_mixer

     * mm: devel/sdlmm

     * net: net/sdl_net

     * sound: audio/sdl_sound

     * ttf: graphics/sdl_ttf

   Falls ein Port z.B. von net/sdl_net und audio/sdl_mixer abha:ngt, so wa:re
   die Syntax:

 USE_SDL=        net mixer

   Die Abha:ngigkeit von devel/sdl12, die durch net/sdl_net und
   audio/sdl_mixer entsteht, wird automatisch zum Port hinzugefu:gt.

   Falls USE_SDL im Port verwendet wird, so wird automatisch:

     * die Abha:ngigkeit von sdl12-config zu BUILD_DEPENDS hinzugefu:gt

     * die Variable SDL_CONFIG zu CONFIGURE_ENV hinzugefu:gt

     * die Abha:ngigkeit der ausgewa:hlten Bibliotheken zu LIB_DEPENDS
       hinzugefu:gt

   Um zu u:berpru:fen, ob die SDL-Bibliotheken verfu:gbar sind, kann die
   Variable WANT_SDL verwendet werden:

 WANT_SDL=yes

 .include <bsd.port.pre.mk>

 .if ${HAVE_SDL:Mmixer}!=""
 USE_SDL+=   mixer
 .endif

 .include <bsd.port.post.mk>

6.18. wxWidgets verwenden

   Dieser Abschnitt beschreibt den Status der wxWidgets-Bibliotheken in den
   Ports und deren Einbindung in das Ports-System.

  6.18.1. Einfu:hrung

   Es gibt viele Probleme bei der gleichzeitigen Verwendung unterschiedlicher
   Versionen von wxWidgets-Bibliotheken (Dateien unterschiedlicher
   wxWidgets-Versionen haben denselben Dateinamen). In den Ports wurde das
   Problem dadurch gelo:st, dass jede Version unter einem eigenen Namen
   installiert wird, der die Versionsnummer als Suffix beinhaltet.

   Der offensichtliche Nachteil dabei ist, dass jede Anwendung so vera:ndert
   werden muss, dass sie die erwartete Version vorfindet. Die meisten solcher
   Anwendungen benutzen das wx-config-Skript, um die beno:tigten Compiler-
   und Linkerflags zu erhalten. Dieses Skript hat fu:r jede verfu:gbare
   Version einen anderen Namen. Die meisten Anwendungen beachten eine
   Umgebungsvariable oder ein Argument beim configure-Skript, um das
   gewu:nschte wx-config-Skript festzulegen. Ansonsten mu:ssen sie gepatcht
   werden.

  6.18.2. Auswahl der Version

   Um festzulegen, welche Version der wxWidgets verwendet werden soll, gibt
   es zwei Variablen (falls nur eine der beiden definiert wird, so wird die
   andere auf einen Standardwert gesetzt):

   Tabelle 6.24. Variablen, um die wxWidgets-Version festzulegen

    Variable             Beschreibung                    Standardwert         
   USE_WX     Liste der Versionen, die der Port   Alle verfu:gbaren Versionen 
              verwenden kann                      
   USE_WX_NOT Liste der Versionen, die der Port   Nichts                      
              nicht verwenden kann                

   Es folgt eine Liste an mo:glichen wxWidgets-Versionen und deren
   zugeho:riger Port:

   Tabelle 6.25. Verfu:gbare wxWidgets-Versionen

   Version         Port         
   2.4     x11-toolkits/wxgtk24 
   2.6     x11-toolkits/wxgtk26 
   2.8     x11-toolkits/wxgtk28 

  Anmerkung:

   Ab Version 2.5 werden auch Versionen in Unicode unterstu:tzt und u:ber
   einen Unterport mit dem Suffix -unicode installiert. Dies kann aber auch
   u:ber Variablen gehandhabt werden (siehe Abschnitt 6.18.4, "Unicode").

   Die Variablen in Tabelle 6.24, "Variablen, um die wxWidgets-Version
   festzulegen" ko:nnen auf einen oder mehrere (durch Leerzeichen getrennt)
   der folgenden Werte gesetzt werden:

   Tabelle 6.26. Spezifikationen der wxWidgets-Versionen

                 Beschreibung               Beispiel 
   Einzelne Version                         2.4      
   Aufsteigende Versionsnummern             2.4+     
   Absteigende Versionsnummern              2.6-     
   Versionsinterval (muss aufsteigend sein) 2.4-2.6  

   Desweiteren gibt es Variablen, u:ber die eine bevorzugte Version
   festgelegt werden kann. Die Versionen ko:nnen als Liste angegeben werden,
   wobei die Reihenfolge der Priorisierung entspricht.

   Tabelle 6.27. Variablen zur Festlegung der bevorzugten wxWidgets-Version

      Name     Bestimmt fu:r 
   WANT_WX_VER den Port      
   WITH_WX_VER den Benutzer  

  6.18.3. Komponentenauswahl

   Desweiteren gibt es Anwendungen, die nicht direkt wxWidgets-Bibliotheken
   sind, aber trotzdem mit diesen zusammenha:ngen. Diese Anwendungen ko:nnen
   u:ber die Variable WX_COMPS festgelegt werden. Die folgenden Komponenten
   sind verfu:gbar:

   Tabelle 6.28. Verfu:gbare wxWidgets-Komponenten

    Name          Beschreibung         Versionsbeschra:nkungen 
   wx      Hauptbibliothek             Nichts                  
   contrib Beigesteuerte Bibliothek    Nichts                  
   python  wxPython (Python-Bindungen) 2.4-2.6                 
   mozilla wxMozilla                   2.4                     
   svg     wxSVG                       2.6                     

   Der Typ der Abha:ngigkeit kann fu:r jede Komponente durch hinzufu:gen
   eines Suffix (durch Strichpunkt getrennt) festgelegt werden. Falls der Typ
   nicht angegeben wird, wird ein Standardwert verwendet (siehe Tabelle 6.30,
   "Standardtypen der wxWidgets-Abha:ngigkeiten"). Die folgenden Typen sind
   verfu:gbar:

   Tabelle 6.29. Verfu:gbare Typen von wxWidgets-Abha:ngigkeiten

   Name                              Beschreibung                             
   build Komponente wird zum Bau beno:tigt - a:quivalent zu BUILD_DEPENDS     
   run   Komponente wird zum Ausfu:hren beno:tigt - a:quivalent zu            
         RUN_DEPENDS                                                          
   lib   Komponente wird zum Bau und Ausfu:hren beno:tigt - a:quivalent zu    
         LIB_DEPENDS                                                          

   Die Standardwerte fu:r die einzelnen Komponenten sind in der folgenden
   Tabelle aufgefu:hrt:

   Tabelle 6.30. Standardtypen der wxWidgets-Abha:ngigkeiten

   Komponente Typ der Abha:ngigkeit 
   wx         lib                   
   contrib    lib                   
   python     run                   
   mozilla    lib                   
   svg        lib                   

   Beispiel 6.6. Auswahl von wxWidgets-Komponenten

   Der folgende Ausschnitt entspricht einem Port, der die wxWidgets-Version
   2.4 und die zugeho:rigen Bibliotheken verwendet.

 USE_WX=       2.4
 WX_COMPS=     wx contrib

  6.18.4. Unicode

   Die wxWidgets-Bibliotheken unterstu:tzen Unicode seit der Version 2.5. In
   den Ports sind beide Versionen verfu:gbar und ko:nnen u:ber die folgenden
   Variablen ausgewa:hlt werden:

   Tabelle 6.31. Variablen, um Unicode in den wxWidgets-Versionen
   auszuwa:hlen

      Variable                     Beschreibung                 Bestimmt fu:r 
   WX_UNICODE      Der Port funktioniert ausschliesslich mit    den Port      
                   der Unicode-Version                          
   WANT_UNICODE    Der Port funktioniert in beiden              den Port      
                   Versionen - bevorzugt wird jedoch Unicode    
   WITH_UNICODE    Der Port verwendet die Unicode-Version       den Benutzer  
                   Der Port verwendet, falls unterstu:tzt, die                
   WITHOUT_UNICODE normale Version (falls WX_UNICODE nicht      den Benutzer
                   definiert ist)                               

  Warnung:

   Die Variable WX_UNICODE darf nicht bei Ports benutzt werden, die sowohl
   die Version mit als auch ohne Unterstu:tzung fu:r Unicode verwenden
   ko:nnen. Falls der Port standardma:ssig Unterstu:tzung fu:r Unicode bieten
   soll, verwenden Sie WANT_UNICODE stattdessen.

  6.18.5. Feststellen der installierten Version

   Um eine bereits installierte Version zu finden, muss WANT_WX definiert
   werden. Falls diese Variable nicht auf eine bestimmte Versionsnummer
   gesetzt wird, werden die Komponenten einen Suffix mit der Versionsnummer
   tragen. Die Variable HAVE_WX wird gesetzt, falls eine installierte Version
   vorgefunden wurde.

   Beispiel 6.7. Installierte wxWidgets-Versionen und -Komponenten
   feststellen

   Der folgende Ausschnitt kann in einem Port verwendet werden, der wxWidgets
   verwendet, falls es installiert ist, oder falls eine Option dafu:r
   ausgewa:hlt wurde.

 WANT_WX=        yes

 .include <bsd.port.pre.mk>

 .if defined(WITH_WX) || ${HAVE_WX:Mwx-2.4} != ""
 USE_WX=         2.4
 CONFIGURE_ARGS+=--enable-wx
 .endif

   Der folgende Ausschnitt kann verwendet werden, um die Unterstu:tzung fu:r
   wxPython zusa:tzlich zu der von wxWidgets zu aktivieren (beide in Version
   2.6), wenn das installiert ist, oder die Option ausgewa:hlt wurde.

 USE_WX=         2.6
 WX_COMPS=       wx
 WANT_WX=        2.6

 .include <bsd.port.pre.mk>

 .if defined(WITH_WXPYTHON) || ${HAVE_WX:Mpython} != ""
 WX_COMPS+=      python
 CONFIGURE_ARGS+=--enable-wxpython
 .endif

  6.18.6. Vordefinierte Variablen

   Die folgenden Variablen sind in den Ports verfu:gbar (nachdem sie
   entsprechend Tabelle 6.24, "Variablen, um die wxWidgets-Version
   festzulegen" definiert wurden).

   Tabelle 6.32. Vordefinierte Variablen fu:r Ports, die wxWidgets verwenden

      Name                             Beschreibung                           
   WX_CONFIG  Pfad zum wxWidgets wx-config-Skript (mit unterschiedlichem      
              Namen)                                                          
   WXRC_CMD   Pfad zum wxWidgets wxrc-Programm (mit unterschiedlichem Namen)  
   WX_VERSION Version der wxWidgets, die verwendet werden soll (z.B. 2.6)     
              Falls Unterstu:tzung fu:r Unicode nicht explizit definiert,     
   WX_UNICODE jedoch verwendet wird, dann wird die Unterstu:tzung automatisch 
              aktiviert.                                                      

  6.18.7. Verarbeitung in bsd.port.pre.mk

   Falls die Variablen gleich nach dem Importieren von bsd.port.pre.mk
   benutzt werden sollen, so muss die Variable WX_PREMK definiert werden.

  Wichtig:

   Falls WX_PREMK definiert ist, so werden Version, Abha:ngigkeiten,
   Komponenten und vordefinierte Variablen nicht gea:ndert, wenn die
   Variablen des wxWidgets-Ports nach dem Einbinden von bsd.port.pre.mk
   gea:ndert werden.

   Beispiel 6.8. Verwendung von wxWidgets-Variablen in Kommandos

   Der folgende Ausschnitt zeigt die Verwendung von WX_PREMK durch Ausfu:hren
   des wx-config-Skriptes, um die vollsta:ndige Version als Zeichenkette zu
   erhalten, diese dann einer Variablen zuzuweisen und die Variable
   anschliessend einem Programm zu u:bergeben.

 USE_WX=         2.4
 WX_PREMK=       yes

 .include <bsd.port.pre.mk>

 .if exists(${WX_CONFIG})
 VER_STR!=       ${WX_CONFIG} --release

 PLIST_SUB+=     VERSION="${VER_STR}"
 .endif

  Anmerkung:

   Die wxWidgets-Variablen ko:nnen problemlos in Kommandos benutzt werden,
   falls diese in Targets ohne gesetztes WX_PREMK verwendet werden.

  6.18.8. Weitere configure-Argumente

   Einige GNU configure-Skripte ko:nnen wxWidgets nicht auffinden, falls nur
   die Umgebungsvariable WX_CONFIG gesetzt ist, sondern beno:tigen
   zusa:tzliche Argumente. Dafu:r kann die Variable WX_CONF_ARGS benutzt
   werden.

   Tabelle 6.33. Zula:ssige Werte fu:r WX_CONF_ARGS

   Mo:glicher Wert                Resultierendes Argument                 
   absolute        --with-wx-config=${WX_CONFIG}                          
   relative        --with-wx=${LOCALBASE} --with-wx-config=${WX_CONFIG:T} 

6.19. Verwendung von Lua

   Dieser Abschnitt beschreibt den Status der Lua-Bibliotheken in den Ports
   und deren Einbindung in das Ports System.

  6.19.1. Einfu:hrung

   Es gibt viele Probleme bei der gleichzeitigen Verwendung unterschiedlicher
   Versionen von Lua-Bibliotheken (Dateien unterschiedlicher Versionen haben
   denselben Dateinamen). In den Ports wurde das Problem gelo:st, indem jede
   Version unter einem eigenen Namen mit der Versionsnummer als Suffix
   installiert wird.

   Der offensichtliche Nachteil dabei ist, dass jede Anwendung so vera:ndert
   werden muss, dass sie die erwartete Version vorfindet. Dies kann jedoch
   durch zusa:tzliche Flags fu:r Compiler und Linker gelo:st werden.

  6.19.2. Auswahl der Version

   Um festzulegen, welche Version von Lua verwendet werden soll, gibt es zwei
   Variablen (falls nur eine der beiden definiert ist, so wird die andere auf
   einen Standardwert gesetzt):

   Tabelle 6.34. Variablen, um die Lua-Version festzulegen

    Variable                   Beschreibung                   Standardwert    
   USE_LUA     Liste der Versionen, welche der Port         Alle verfu:gbaren 
               verwenden kann                               Versionen         
   USE_LUA_NOT Liste der Versionen, die der Port nicht      Nichts            
               verwenden kann                               

   Es folgt eine Liste an mo:glichen Lua-Versionen und deren zugeho:riger
   Port:

   Tabelle 6.35. Verfu:gbare Lua-Versionen

   Version    Port    
   4.0     lang/lua4  
   5.0     lang/lua50 
   5.1     lang/lua   

   Die Variablen in Tabelle 6.34, "Variablen, um die Lua-Version festzulegen"
   ko:nnen auf einen oder mehrere (durch Leerzeichen getrennt) der folgenden
   Werte gesetzt werden:

   Tabelle 6.36. Spezifikationen der Lua-Versionen

                  Beschreibung                Beispiel 
   Spezielle Version                          4.0      
   Aufsteigende Versionen                     5.0+     
   Absteigende Versionen                      5.0-     
   Versionenintervall (muss aufsteigend sein) 5.0-5.1  

   Desweiteren gibt es Variablen, u:ber die eine bevorzugte Version
   festgelegt werden kann. Die Versionen ko:nnen als Liste angegeben werden,
   wobei die Reihenfolge der Priorisierung entspricht.

   Tabelle 6.37. Variablen zur Festlegung der bevorzugten Lua-Version

       Name     Bestimmt fu:r 
   WANT_LUA_VER den Port      
   WITH_LUA_VER den Benutzer  

   Beispiel 6.9. Auswahl der Lua-Version

   Der folgende Ausschnitt entspricht einem Port, der Lua in den Versionen
   5.0 oder 5.1 verwenden kann und standardma:ssig 5.0 verwendet. Diese
   Einstellung kann durch die benutzerdefinierte Variable WITH_LUA_VER
   u:berschrieben werden.

 USE_LUA=      5.0-5.1
 WANT_LUA_VER= 5.0

  6.19.3. Komponentenauswahl

   Desweiteren gibt es Anwendungen, die nicht direkt Lua-Bibliotheken sind,
   aber trotzdem mit diesen zusammenha:ngen. Diese Anwendungen ko:nnen u:ber
   die Variable LUA_COMPS festgelegt werden. Die folgenden Komponenten sind
   verfu:gbar:

   Tabelle 6.38. Verfu:gbare Lua-Komponenten

   Name                 Beschreibung                 Versionseinschra:nkungen 
   lua   Hauptbibliothek                             Keine                    
   tolua Bibliothek fu:r die Unterstu:tzung von      4.0-5.0                  
         C/C++-Code                                  
   ruby  Ruby-Bindungen                              4.0-5.0                  

  Anmerkung:

   Es gibt weitere Komponenten, die jedoch Module fu:r den Interpreter sind
   und nicht von Anwendungen benutzt werden (nur von anderen Modulen).

   Der Typ der Abha:ngigkeit kann fu:r jede Komponente durch Hinzufu:gen
   eines Suffix (durch Strichpunkt getrennt) festgelegt werden. Falls der Typ
   nicht angegeben wird, wird ein Standardwert verwendet (siehe Tabelle 6.40,
   "Standardtypen fu:r Lua-Abha:ngigkeiten"). Die folgenden Typen sind
   verfu:gbar:

   Tabelle 6.39. Verfu:gbare Typen von Lua-Abha:ngigkeiten

   Name                              Beschreibung                             
   build Komponente wird zum Bau beno:tigt - a:quivalent zu BUILD_DEPENDS     
   run   Komponente wird zum Ausfu:hren beno:tigt - a:quivalent zu            
         RUN_DEPENDS                                                          
   lib   Komponente wird zum Bau und zum Ausfu:hren beno:tigt - a:quivalent   
         zu LIB_DEPENDS                                                       

   Die Standardwerte fu:r die einzelnen Komponenten sind in der folgenden
   Tabelle aufgefu:hrt:

   Tabelle 6.40. Standardtypen fu:r Lua-Abha:ngigkeiten

   Komponente                 Typ der Abha:ngigkeit                 
   lua        lib fu:r 4.0-5.0 (shared) und build fu:r 5.1 (static) 
   tolua      build (static)                                        
   ruby       lib (shared)                                          

   Beispiel 6.10. Auswahl von Lua-Komponenten

   Der folgende Ausschnitt entspricht einem Port, welcher die Lua-Version 4.0
   und die zugeho:rigen Ruby-Bindungen verwendet.

 USE_LUA=      4.0
 LUA_COMPS=    lua ruby

  6.19.4. Feststellen der installierten Version

   Um eine bereits installierte Version zu finden, muss WANT_LUA definiert
   werden. Falls diese Variable nicht auf eine bestimmte Versionsnummer
   gesetzt wird, werden die Komponenten einen Suffix mit der Versionsnummer
   tragen. Die Variable HAVE_LUA wird gesetzt, falls eine installierte
   Version vorgefunden wurde.

   Beispiel 6.11. Installierte Lua-Versionen und- Komponenten feststellen

   Der folgende Ausschnitt kann in einem Port verwendet werden, der Lua
   benutzt, falls es installiert ist oder eine Option dafu:r ausgewa:hlt
   wurde.

 WANT_LUA=       yes

 .include <bsd.port.pre.mk>

 .if defined(WITH_LUA5) || ${HAVE_LUA:Mlua-5.[01]} != ""
 USE_LUA=        5.0-5.1
 CONFIGURE_ARGS+=--enable-lua5
 .endif

   Der folgende Ausschnitt kann verwendet werden, um die Unterstu:tzung fu:r
   tolua zusa:tzlich zu der von Lua zu aktivieren (beide in Version 4.0),
   wenn dies installiert ist oder die Option ausgewa:hlt wurde.

 USE_LUA=        4.0
 LUA_COMPS=      lua
 WANT_LUA=       4.0

 .include <bsd.port.pre.mk>

 .if defined(WITH_TOLUA) || ${HAVE_LUA:Mtolua} != ""
 LUA_COMPS+=     tolua
 CONFIGURE_ARGS+=--enable-tolua
 .endif

  6.19.5. Vordefinierte Variablen

   Die folgenden Variablen sind in den Ports verfu:gbar (nachdem sie
   entsprechend Tabelle 6.34, "Variablen, um die Lua-Version festzulegen"
   definiert wurden).

   Tabelle 6.41. Vordefinierte Variablen fu:r Ports, die Lua verwenden

         Name                              Beschreibung                       
   LUA_VER           Die Lua-Version, die verwendet wird (z.B. 5.1)           
   LUA_VER_SH        Die Hauptversion fu:r shared-Lua-Bibliotheken (z.B. 1)   
   LUA_VER_STR       Die Lua-Version ohne die Punkte (z.B. 51)                
   LUA_PREFIX        Der Pra:fix, unter dem Lua (und Komponenten) installiert 
                     ist                                                      
   LUA_SUBDIR        Das Verzeichnis unter ${PREFIX}/bin, ${PREFIX}/share und 
                     ${PREFIX}/lib, in welchem Lua installiert ist            
   LUA_INCDIR        Das Verzeichnis, in dem Lua- und tolua-Header-Dateien    
                     installiert sind                                         
   LUA_LIBDIR        Das Verzeichnis, in dem Lua- und tolua-Bibliotheken      
                     installiert sind                                         
   LUA_MODLIBDIR     Das Verzeichnis, in dem Lua Modul-Bibliotheken (.so)     
                     installiert sind                                         
   LUA_MODSHAREDIR   Das Verzeichnis, in dem Lua-Module (.lua) installiert    
                     sind                                                     
   LUA_PKGNAMEPREFIX Der Paketnamen-Pra:fix, der von Lua-Modulen verwendet    
                     wird                                                     
   LUA_CMD           Das Verzeichnis, in dem der Lua-Interpreter liegt        
   LUAC_CMD          Das Verzeichnis, in dem der Lua-Compiler liegt           
   TOLUA_CMD         Das Verzeichnis, in dem das tolua-Programm liegt         

   Beispiel 6.12. Einem Port mitteilen, in welchem Verzeichnis Lua liegt

   Der folgende Ausschnitt zeigt, wie einem Port, welcher ein
   configure-Skript verwendet, mitgeteilt werden kann, wo die
   Lua-Header-Dateien und Bibliotheken liegen.

 USE_LUA=        4.0
 GNU_CONFIGURE=  yes
 CONFIGURE_ENV=  CPPFLAGS="-I${LUA_INCDIR}" LDFLAGS="-L${LUA_LIBDIR}"

  6.19.6. Verarbeitung in bsd.port.pre.mk

   Falls die Variablen gleich nach dem Einbinden von bsd.port.pre.mk benutzt
   werden sollen, so muss die Variable LUA_PREMK definiert werden.

  Wichtig:

   Falls LUA_PREMK definiert ist, so werden Version, Abha:ngigkeiten,
   Komponenten und vordefinierte Variablen nicht gea:ndert, wenn die
   Variablen des Lua-Ports nach dem Einbinden von bsd.port.pre.mk gea:ndert
   werden.

   Beispiel 6.13. Verwendung von Lua-Variablen in Kommandos

   Der folgende Ausschnitt zeigt die Verwendung von LUA_PREMK durch
   Ausfu:hren des Lua-Interpreters, um die vollsta:ndige Version als
   Zeichenkette zu erhalten, diese dann einer Variablen zuzuweisen und die
   Variable schliesslich einem Programm zu u:bergeben.

 USE_LUA=        5.0
 LUA_PREMK=      yes

 .include <bsd.port.pre.mk>

 .if exists(${LUA_CMD})
 VER_STR!=       ${LUA_CMD} -v

 CFLAGS+=        -DLUA_VERSION_STRING="${VER_STR}"
 .endif

  Anmerkung:

   Die Lua-Variablen ko:nnen problemlos in Befehlen benutzt werden, falls
   diese in Targets ohne gesetztes LUA_PREMK verwendet werden.

6.20. Xfce verwenden

   Die USE_XFCE-Variable wird fu:r die automatische Konfiguration der
   Abha:ngigkeiten eingesetzt, welche die Xfce-Basisbibliotheken oder
   Anwendungen wie x11-toolkits/libxfce4gui und x11-wm/xfce4-panel verwenden.

   Die folgenden Xfce-Bibliotheken und -Anwendungen werden derzeit
   unterstu:tzt:

     * libexo: x11/libexo

     * libgui: x11-toolkits/libxfce4gui

     * libutil: x11/libxfce4util

     * libmcs: x11/libxfce4mcs

     * mcsmanager: sysutils/xfce4-mcs-manager

     * panel: x11-wm/xfce4-panel

     * thunar: x11-fm/thunar

     * wm: x11-wm/xfce4-wm

     * xfdev: dev/xfce4-dev-tools

   Die folgenden zusa:tzlichen Parameter werden unterstu:tzt:

     * configenv: Benutzen Sie dies, wenn Ihr Port eine speziell angepasste
       CONFIGURE_ENV-Variable beno:tigt, um seine erforderlichen Bibliotheken
       zu finden.

 -I${LOCALBASE}/include
             -L${LOCALBASE}/lib

       wird CPPFLAGS hinzugefu:gt und ergibt CONFIGURE_ENV.

   Wenn also ein Port von sysutils/xfce4-mcs-manager abha:ngt und die
   speziellen CPPFLAGS in seiner configure-Umgebung verlangt, dann wu:rde die
   Syntax wie folgt aussehen:

 USE_XFCE=        mcsmanager configenv

6.21. Mozilla verwenden

   Tabelle 6.42. Variablen fu:r Ports, die Mozilla verwenden

                         Vom Port unterstu:tzte Gecko-Backends. Mo:gliche     
   USE_GECKO             Werte sind: libxul (libxul.so), seamonkey            
                         (libgtkembedmoz.so, (veraltet, sollte daher nicht    
                         mehr verwendet werden).                              
                         Der Port beno:tigt Firefox, um korrekt zu            
   USE_FIREFOX           funktionieren. Mo:gliche Werte sind: yes (verwendet  
                         die Standardversion), 40, 36, 35. Die                
                         Standardversion ist derzeit 40.                      
                         Um den Port zu bauen, muss Firefox installiert sein. 
   USE_FIREFOX_BUILD     Wird diese Variable gesetzt, wird automatisch auch   
                         USE_FIREFOX gesetzt.                                 
                         Der Port beno:tigt Seamonkey, um korrekt zu          
                         funktionieren. Mo:gliche Werte sind: yes (verwendet  
   USE_SEAMONKEY         die Standardversion), 20, 11 (veraltet, sollte daher 
                         nicht mehr verwendet werden). Die Standardversion    
                         ist 20.                                              
                         Um den Port zu bauen, muss Seamonkey installiert     
   USE_SEAMONKEY_BUILD   sein. Wird diese Variable gesetzt, wird automatisch  
                         auch USE_SEAMONKEY gesetzt.                          
                         Dieser Port beno:tigt Thunderbird, um korrekt zu     
                         funktionieren. Mo:gliche Werte sind: yes (verwendet  
   USE_THUNDERBIRD       die Standardversion), 31, 30 (veraltet, sollte daher 
                         nicht mehr verwendet werden). Die Standardversion    
                         ist 31.                                              
                         Um den Port zu bauen, muss Thunderbird installiert   
   USE_THUNDERBIRD_BUILD sein. Wird diese Variable gesetzt, wird automatisch  
                         auch USE_THUNDERBIRD gesetzt.                        

   Eine komplette Liste aller verfu:gbaren Variablen finden Sie in der Datei
   /usr/ports/Mk/bsd.gecko.mk.

6.22. Benutzung von Datenbanken

   Tabelle 6.43. Variablen fu:r Ports, die Datenbanken benutzen

   Variable                             Bedeutung                             
             Falls die Variable auf yes gesetzt ist, fu:ge eine Abha:ngigkeit 
             von databases/db41 hinzu. Die Variable kann auch folgende Werte  
   USE_BDB   annehmen: 40, 41, 42, 43, 44, 46, 47, 48 oder 51. Sie ko:nnen    
             eine Folge akzeptierter Werte angeben - USE_BDB=42+ stellt die   
             ho:chste installierte Version fest und greift auf 42 zuru:ck,    
             falls sonst nichts installiert ist.                              
             Falls die Variable auf yes gesetzt ist, fu:ge                    
   USE_MYSQL databases/mysql55-server als Abha:ngigkeit hinzu. Die damit      
             verknu:pfte Variable WANT_MYSQL_VER kann Werte wie 323, 40, 41,  
             50, 51, 52, 55, oder 60 annehmen.                                
             Falls die Variable auf yes gesetzt ist, fu:ge eine Abha:ngigkeit 
   USE_PGSQL von databases/postgresql84 hinzu. Die damit verknu:pfte Variable 
             WANT_PGSQL_VER kann Werte wie 73, 74, 80, 81, 82, 83, oder 90    
             annehmen.                                                        

   Weitere Informationen zu diesem Thema finden sich in der Datei
   bsd.database.mk.

6.23. Starten und Anhalten von Diensten (rc Skripten)

   rc.d-Skripten werden zum Starten von Diensten wa:hrend des Systemstarts
   verwendet und um den Administratoren einen Standardweg zum Anhalten und
   Starten von Diensten zu bieten. Ports halten sich an dieses systemweite
   rc.d-Framework. Details zu deren Benutzung ko:nnen im rc.d Kapitel des
   Handbuchs nachgelesen werden. Ausfu:hrliche Beschreibungen der
   verfu:gbaren Befehle stehen in rc(8) und rc.subr(8). Desweiteren gibt es
   einen Artikel zu praktischen Aspekten bezu:glich rc.d-Skripten.

   Ein oder mehrere rc.d-Skripten ko:nnen installiert werden mittels:

 USE_RC_SUBR=    doormand

   Skripten mu:ssen im Unterverzeichnis files abgelegt und jeder Skript-Datei
   muss ein .in-Suffix hinzugefu:gt werden. Standardma:ssige
   SUB_LIST-Ersetzungen werden fu:r diese Dateien unterstu:tzt. Die
   Verwendung von %%PREFIX%% und %%LOCALBASE%% wird dringend empfohlen.
   Na:heres zu SUB_LIST kann im zugeho:rigen Kapitel nachgelesen werden.

   Fu:r FreeBSD-Versionen, die a:lter als 6.1-RELEASE sind, ist die
   Integration mittels rcorder(8) mo:glich, indem USE_RCORDER anstatt
   USE_RC_SUBR verwendet wird. Die Verwendung dieser Methode ist jedoch nur
   notwendig, wenn der Port in die Verzeichnisstruktur des Basissystems
   installiert werden kann oder der Dienst vor den FILESYSTEMS-Skripten in
   rc.d des Basissystems gestartet sein muss.

   Seit FreeBSD 6.1-RELEASE sind lokale rc.d-Skripten (inklusive der durch
   Ports installierten) im allgemeinen rcorder(8) des Basissystems.

   Beispiel eines einfachen rc.d-Skripts:

 #!/bin/sh

 # $FreeBSD$
 #
 # PROVIDE: doormand
 # REQUIRE: LOGIN
 # KEYWORD: shutdown
 #
 # Add the following lines to /etc/rc.conf.local or /etc/rc.conf
 # to enable this service:
 #
 # doormand_enable (bool):    Set to NO by default.
 #                Set it to YES to enable doormand.
 # doormand_config (path):    Set to %%PREFIX%%/etc/doormand/doormand.cf
 #                by default.
 #

 . /etc/rc.subr

 name="doormand"
 rcvar=${name}_enable

 command=%%PREFIX%%/sbin/${name}
 pidfile=/var/run/${name}.pid

 load_rc_config $name

 : ${doormand_enable="NO"}
 : ${doormand_config="%%PREFIX%%/etc/doormand/doormand.cf"}

 command_args="-p $pidfile -f $doormand_config"

 run_rc_command "$1"

   Solange kein guter Grund dafu:r besteht, einen Dienst fru:her starten zu
   lassen, sollten alle Ports-Skripten

 REQUIRE: LOGIN

   verwenden. Falls der Port von einem bestimmten Benutzer (ausser root)
   ausgefu:hrt wird, ist dies zwingend.

 KEYWORD: shutdown

   ist im Skript oben deswegen vorhanden, weil der frei erfundene
   Beispiel-Port einen Dienst startet und dieser beim Herunterfahren des
   Systems sauber beendet werden sollte. Startete das Skript keinen
   persistenten Dienst, wa:re dies nicht notwendig.

   Fu:r die Wertzuweisung von Variablen sollte "=" anstatt ":=" verwendet
   werden, da bei Ersterem nur auf einen Standardwert gesetzt wird, wenn die
   Variable vorher noch nicht gesetzt war, und bei Letzterem dieser gesetzt
   wird, auch wenn der Wert vorher Null gewesen ist. Ein Benutzer kann
   durchaus einen Ausdruck wie

 doormand_flags=""

   in seiner rc.conf.local-Datei stehen haben, und eine Variablenzuweisung
   mittels ":=" wu:rde in diesem Fall die Benutzerdefinition u:berschreiben.

  Anmerkung:

   Es sollten keine weiteren Skripten mit der .sh-Endung hinzugefu:gt werden.
   Irgendwann wird es ein Massenumbenennen aller Skripten im Repository
   geben, die immer noch diese Endung haben.

  6.23.1. Anhalten und Deinstallieren von Diensten

   Es ist mo:glich, dass ein Dienst wa:hrend der Deinstallation automatisch
   angehalten wird. Es wird empfohlen dieses Verhalten nur zu implementieren,
   wenn es unbedingt erforderlich ist zuerst den Dienst anzuhalten und dann
   die Dateien zu entfernen. Normalerweise sollte es dem Administrator
   u:berlassen werden, ob ein Dienst durch Deinstallieren angehalten werden
   soll. Dies betrifft auch den Vorgang des Aktualisierens.

   Der Datei pkg-plist sollte eine Zeile wie folgt zugefu:gt werden:

 @stopdaemon doormand

   Das Argument muss dabei mit dem Inhalt der USE_RC_SUBR-Variablen
   u:bereinstimmen.

6.24. Hinzufu:gen von Benutzern und Gruppen

   Manche Ports setzen voraus, dass ein bestimmter Benutzer auf dem System
   angelegt ist. Wa:hlen Sie in einem solchen Fall eine freie Kennnummer
   zwischen 50 und 999 aus und tragen Sie diese in ports/UIDs (fu:r Benutzer)
   oder ports/GIDs (fu:r Gruppen) ein. Stellen Sie dabei sicher, dass Sie
   keine Kennnummer auswa:hlen, die bereits vom System oder von anderen Ports
   verwendet wird.

   Erstellen Sie bitte eine entsprechende Patch-Datei fu:r diese beiden
   Dateien, wenn fu:r Ihren Port ein neuer Benutzer oder eine neue Gruppe
   angelegt werden muss.

   Sie ko:nnen dann die Variablen USERS und GROUPS im Makefile benutzen, um
   bei der Port-Installation das automatische Anlegen des Benutzers zu
   veranlassen.

 USERS=  pulse
 GROUPS= pulse pulse-access pulse-rt

   Die Liste mit den momentan belegten UIDs (GIDs) befindet sich in
   ports/UIDs (ports/GIDs).

6.25. Von Kernelquellen abha:ngige Ports

   Einige Ports (beispielsweise vom Kernel ladbare Module) beno:tigen die
   Kernelsourcen, damit sie gebaut werden ko:nnen. Die folgenden Zeilen
   beschreiben den korrekten Weg, wie Sie feststellen ko:nnen, ob der
   Benutzer die Kernelsourcen installiert hat:

 .if !exists(${SRC_BASE}/sys/Makefile)

 IGNORE=         requires kernel sources to be installed
 .endif

                 Kapitel 7. Fortgeschrittene pkg-plist-Methoden

   Inhaltsverzeichnis

   7.1. A:nderungen an pkg-plist mit Hilfe von make-Variablen

   7.2. Leere Verzeichnisse

   7.3. Konfigurationsdateien

   7.4. Dynamische oder statische Paketliste

   7.5. Automatisiertes Erstellen von Paketlisten

7.1. A:nderungen an pkg-plist mit Hilfe von make-Variablen

   Einige Ports, insbesondere die p5--Ports, mu:ssen, abha:ngig von ihren
   Konfigurationsoptionen (oder im Falle der p5-Ports von der perl-Version),
   die pkg-plist vera:ndern. Um dies zu vereinfachen, werden fu:r jeden
   Eintrag in pkg-plist die Variablen %%OSREL%%, %%PERL_VER%% und
   %%PERL_VERSION%% durch die jeweiligen Werte ersetzt. Der Wert von
   %%OSREL%% ist die Revisionsnummer des Betriebssystems (z.B. 4.9).
   %%PERL_VERSION%% und %%PERL_VER%% geben die vollsta:ndige Versionsnummer
   von perl (z.B. 5.8.9) an. Weitere, die Dokumentationsdateien des Ports
   betreffende %%VARS%%, werden im entsprechenden Abschnitt erla:utert.

   Falls Sie weitere Ersetzungen von Variablen durchfu:hren mu:ssen, ko:nnen
   Sie in der Variable PLIST_SUB eine Liste von VAR=VALUE-Paaren angeben,
   wobei in der pkg-plist %%VAR%% durch VALUE ersetzt wird.

   Wenn Sie z.B. einen Port haben, der viele Dateien in ein
   versionsspezifisches Unterverzeichnis installiert, dann ko:nnen Sie etwas
   wie

 OCTAVE_VERSION= 2.0.13
 PLIST_SUB=      OCTAVE_VERSION=${OCTAVE_VERSION}

   in das Makefile schreiben und %%OCTAVE_VERSION%% verwenden, unabha:ngig
   davon, wo die Variable in pkg-plist verwendet wird. In diesem Fall mu:ssen
   Sie bei einem Upgrade des Ports nicht dutzende (oder manchmal sogar
   hunderte) Zeilen in pkg-plist anpassen.

   Falls Ihr Port in Abha:ngigkeit von den ausgewa:hlten Optionen Dateien
   installiert, ist es u:blich, den entsprechenden Zeilen in der pkg-plist
   eine Zeichenfolge %%TAG%% voranzustellen, wobei der Platzhalter TAG der
   Variablen PLIST_SUB im Makefile bei gleichzeitiger Zuweisung des
   speziellen Werts @comment hinzugefu:gt wird, der die Paket-Werkzeuge die
   Zeile ignorieren la:sst:

 .if defined(WITH_X11)
 PLIST_SUB+= X11=""
 .else
 PLIST_SUB+= X11="@comment "
 .endif

   und in der pkg-plist:

 %%X11%%bin/foo-gui

   Diese Ersetzung (ebenso wie das Hinzufu:gen weiterer Manualpages) wird
   zwischen den pre-install- und do-install-Targets ausgefu:hrt, indem aus
   PLIST gelesen und in TMPPLIST geschrieben wird (Standard:
   WRKDIR/.PLIST.mktmp). Falls Ihr Port also PLIST wa:hrend dem Erstellen
   generiert, so sollte dies vor oder in pre-install geschehen. Muss Ihr Port
   die resultierende Datei vera:ndern, so sollte dies in post-install mit der
   Ausgabedatei TMPPLIST erfolgen.

   Eine weitere Mo:glichkeit, die Paketliste eines Ports zu vera:ndern,
   besteht darin die Variablen PLIST_FILES und PLIST_DIRS zu setzen. Der Wert
   jeder der beiden Variablen stellt eine Liste von Pfadnamen dar, die
   zusammen mit dem Inhalt von PLIST in TMPPLIST geschrieben wird. Dabei
   unterliegen die Namen in PLIST_FILES und PLIST_DIRS der weiter oben
   beschriebenen Substitution von %%VAR%%. Die Namen aus PLIST_FILES werden
   ansonsten unvera:ndert in die endgu:ltige Paketliste u:bernommen, wa:hrend
   den Namen aus PLIST_DIRS noch der Wert von @dirrm vorangestellt wird.
   Damit die Verwendung von PLIST_FILES und PLIST_DIRS u:berhaupt mo:glich
   ist, mu:ssen diese gesetzt werden, bevor TMPPLIST geschrieben wird - z.B.
   in pre-install oder vorher.

7.2. Leere Verzeichnisse

  7.2.1. Aufra:umen leerer Verzeichnisse

   Bitte sorgen Sie dafu:r, dass ihre Ports bei der Deinstallation leere
   Verzeichnisse lo:schen. Dazu wird fu:r jedes Verzeichnis, das der Port
   erzeugt hat, eine @dirrm-Zeile angegeben. Um ein Verzeichnis zu lo:schen
   mu:ssen Sie zuerst dessen Unterverzeichnisse entfernen.

  :
 lib/X11/oneko/pixmaps/cat.xpm
 lib/X11/oneko/sounds/cat.au
  :
 @dirrm lib/X11/oneko/pixmaps
 @dirrm lib/X11/oneko/sounds
 @dirrm lib/X11/oneko

   Es kann allerdings auch vorkommen, dass @dirrm Fehler ausgibt, da andere
   Ports ein Verzeichnis ebenfalls nutzen. Deshalb ko:nnen Sie @dirrmtry
   verwenden, um nur Verzeichnisse zu lo:schen, die wirklich leer sind, und
   damit Warnhinweise vermeiden.

 @dirrmtry share/doc/gimp

   Dadurch wird es weder eine Fehlermeldung geben noch wird pkg_delete(1)
   abnormal beendet werden - auch dann nicht, wenn ${PREFIX}/share/doc/gimp
   nicht leer ist, da andere Ports hier ebenfalls Dateien installiert haben.

  7.2.2. Erstellen leerer Verzeichnisse

   Um leere Verzeichnisse wa:hrend der Installation eines Ports zu erstellen,
   bedarf es etwas Aufmerksamkeit. Diese Verzeichnisse werden nicht erstellt,
   wenn das Paket installiert wird, da Pakete nur die Dateien speichern und
   pkg_add(1) nur die Verzeichnisse erstellt, die dafu:r beno:tigt werden. Um
   sicher zu gehen, dass das leere Verzeichnis erstellt wird, wenn ein Paket
   installiert wird, muss die folgende Zeile in pkg-plist u:ber der
   entsprechenden @dirrm Zeile eingetragen werden:

 @exec mkdir -p %D/share/foo/templates

7.3. Konfigurationsdateien

   Sollte Ihr Port Konfigurationsdateien in PREFIX/etc beno:tigen, so sollten
   Sie diese nicht einfach installieren und in pkg-plist auflisten. Dies
   wu:rde pkg_delete(1) veranlassen, diese Dateien zu lo:schen, selbst wenn
   wenn sie vom Benutzer editiert wurden.

   Stattdessen sollten Beispieldateien mit einem entsprechenden Suffix
   (beispielsweise filename.sample) versehen werden. Ist die
   Konfigurationsdatei nicht vorhanden, so sollte die Beispieldatei an deren
   Platz kopiert werden. Bei der Deinstallation sollte die
   Konfigurationsdatei gelo:scht werden, aber nur, wenn sie nicht vom
   Benutzer vera:ndert wurde. Das alles muss sowohl im Makefile des Ports als
   auch in der pkg-plist (fu:r die Installation aus einem Paket)
   sichergestellt werden.

   Beispiel aus einem Makefile:

 post-install:
     @if [ ! -f ${PREFIX}/etc/orbit.conf ]; then \
         ${CP} -p ${PREFIX}/etc/orbit.conf.sample ${PREFIX}/etc/orbit.conf ; \
     fi

   Beispiel aus einer pkg-plist:

 @unexec if cmp -s %D/etc/orbit.conf.sample %D/etc/orbit.conf; then rm -f %D/etc/orbit.conf; fi
 etc/orbit.conf.sample
 @exec if [ ! -f %D/etc/orbit.conf ] ; then cp -p %D/%F %B/orbit.conf; fi

   Wahlweise ko:nnen Sie auch eine Nachricht ausgegeben lassen, in der Sie
   den Nutzer auffordern, die Datei an die richtige Stelle zu kopieren und zu
   bearbeiten, bevor das Programm ausgefu:hrt werden kann.

7.4. Dynamische oder statische Paketliste

   Eine statische Paketliste ist eine Paketliste, die in der Ports-Sammlung,
   entweder in Form der pkg-plist (mit oder ohne der Ersetzung von Variablen)
   oder durch PLIST_FILES und PLIST_DIRS im Makefile eingebettet, verfu:gbar
   ist. Selbst wenn der Inhalt durch ein Werkzeug oder ein Target im Makefile
   automatisch erzeugt wird, bevor die Datei von einem Committer in die
   Ports-Sammlung aufgenommen wird, so ist dies immer noch eine statische
   Liste, da es mo:glich ist den Dateiinhalt zu betrachten ohne ein Distfile
   Herunterladen oder Kompilieren zu mu:ssen.

   Eine dynamische Paketliste ist eine Paketliste, die beim Kompilieren des
   Ports erstellt wird, abha:ngig davon, welche Dateien und Verzeichnisse
   installiert werden. Es ist nicht mo:glich diese Liste zu betrachten, bevor
   der Quelltext heruntergeladen und kompiliert oder nachdem ein make clean
   ausgefu:hrt wurde.

   Der Einsatz dynamischer Paketlisten ist zwar nicht untersagt, aber Sie
   sollten, wann immer das mo:glich ist, statische Paketlisten verwenden, da
   die Nutzer dann grep(1) auf alle verfu:gbaren Ports anwenden ko:nnen, um
   z.B. herauszufinden, von welchem eine bestimmte Datei installiert wurde.
   Dynamische Paketlisten sollten fu:r komplexe Ports verwendet werden, bei
   denen sich die Liste abha:ngig von den gewa:hlten Funktionen sehr stark
   a:ndern kann (wodurch die Pflege von statischen Listen unmo:glich wird),
   oder Ports, welche die Paketliste abha:ngig von den Versionen verwendeter
   Abha:ngigkeiten vera:ndern (z.B. Ports, die Ihre Dokumentation mit Javadoc
   erzeugen).

   Maintainer, die dynamische Paketlisten bevorzugen, werden dazu
   aufgefordert, neue Targets zu Ihren Ports hinzuzufu:gen, welche die
   pkg-plist-Datei erzeugen, sodass Benutzer den Inhalt u:berpru:fen ko:nnen.

7.5. Automatisiertes Erstellen von Paketlisten

   Als Erstes sollten Sie sich vergewissern, dass der Port bis auf pkg-plist
   vollsta:ndig ist.

   Als Na:chstes erstellen Sie einen tempora:ren Verzeichnisbaum, in welchem
   Ihr Port installiert werden kann, und installieren Sie alle
   Abha:ngigkeiten.

 # mkdir /var/tmp/`make -V PORTNAME`
 # mtree -U -f `make -V MTREE_FILE` -d -e -p /var/tmp/`make -V PORTNAME`
 # make depends PREFIX=/var/tmp/`make -V PORTNAME`

   Speichern Sie die Verzeichnisstruktur in einer neuen Datei.

 # (cd /var/tmp/`make -V PORTNAME` && find -d * -type d) | sort > OLD-DIRS

   Erstellen Sie eine leere pkg-plist-Datei:

 # :>pkg-plist

   Wenn Ihr Port auf PREFIX achtet (was er machen sollte), so kann der Port
   nun installiert und die Paketliste erstellt werden.

 # make install PREFIX=/var/tmp/`make -V PORTNAME`
 # (cd /var/tmp/`make -V PORTNAME` && find -d * \! -type d) | sort > pkg-plist

   Sie mu:ssen auch alle neu erstellten Verzeichnisse in die Paketliste
   aufnehmen.

 # (cd /var/tmp/`make -V PORTNAME` && find -d * -type d) | sort | comm -13 OLD-DIRS - | sort -r | sed -e 's#^#@dirrm #' >> pkg-plist

   Zu guter Letzt muss die Paketliste noch manuell aufgera:umt werden - es
   funktioniert eben nicht alles automatisch. Manualpages sollten im Makefile
   des Ports unter MANn aufgefu:hrt sein und nicht in der Paketliste.
   Konfigurationsdateien des Benutzers sollten entfernt oder als
   filename.sample installiert werden. Die info/dir-Datei sollte nicht
   aufgefu:hrt sein und die zugeho:rigen install-info-Zeilen sollten
   hinzugefu:gt werden, wie im info files-Abschnitt beschrieben. Alle
   Bibliotheken, die der Port installiert, sollten aufgelistet werden, wie es
   im Shared Libraries-Abschnitt festgelegt ist.

   Alternativ dazu ko:nnen Sie das plist-Skript in /usr/ports/Tools/scripts/
   verwenden, um die Paketliste automatisch zu erstellen. Das plist-Skript
   ist ein Ruby-Skript, das die meisten der in den vorangehenden Absa:tzen
   kurz dargestellten manuellen Schritte automatisiert.

   Der erste Schritt ist derselbe wie oben: Nehmen Sie die ersten drei
   Zeilen, also mkdir, mtree und make depends. Installieren und bauen Sie
   dann den Port:

 # make install PREFIX=/var/tmp/`make -V PORTNAME`

   Und lassen Sie plist die pkg-plist-Datei erstellen:

 # /usr/ports/Tools/scripts/plist -Md -m `make -V MTREE_FILE` /var/tmp/`make -V PORTNAME` > pkg-plist

   Die Paketliste muss immer noch von Hand aufgera:umt werden, wie es oben
   erkla:rt wurde.

   Ein weiteres Werkzeug zur Erzeugung einer ersten pkg-plist-Datei ist
   ports-mgmt/genplist. Wie bei jedem automatisierten Hilfswerkzeug, sollte
   die erzeugte pkg-plist-Datei u:berpru:ft und bei Bedarf von Hand
   nachbearbeitet werden.

                          Kapitel 8. Die pkg-* Dateien

   Inhaltsverzeichnis

   8.1. pkg-message

   8.2. pkg-install

   8.3. pkg-deinstall

   8.4. pkg-req

   8.5. A:ndern der Namen der pkg-* Dateien

   8.6. Nutzung von SUB_FILES und SUB_LIST

   Es gibt noch einige Tricks mit pkg-*, die wir noch nicht erwa:hnt haben,
   die aber oft sehr praktisch sind.

8.1. pkg-message

   Wenn Sie dem Anwender bei der Installation weitere Informationen anzeigen
   wollen, so ko:nnen Sie diese Nachricht in pkg-message speichern. Diese
   Vorgehensweise ist oft nu:tzlich, um zusa:tzliche Schritte anzuzeigen, die
   nach pkg_add(1) durchgefu:hrt werden mu:ssen. Dadurch ko:nnen Sie auch
   Lizenzinformationen darstellen.

   Wollen Sie nur ein paar Zeilen u:ber die Einstellungen zum Erstellen des
   Ports oder Warnungen ausgeben, benutzen Sie ECHO_MSG. pkg-message ist nur
   fu:r Schritte nach der Installation vorgesehen. Sie sollten den
   Unterschied zwischen ECHO_MSG und ECHO_CMD beachten: Ersteres wird
   benutzt, um Informationen auf dem Bildschirm auszugeben, wa:hrend
   Letzteres fu:r Kommando-Pipelining bestimmt ist.

   Ein gutes Beispiel fu:r die Benutzung der beiden Befehle ist in
   shells/bash2/Makefile zu finden:

 update-etc-shells:
     @${ECHO_MSG} "updating /etc/shells"
     @${CP} /etc/shells /etc/shells.bak
     @( ${GREP} -v ${PREFIX}/bin/bash /etc/shells.bak; \
         ${ECHO_CMD} ${PREFIX}/bin/bash) >/etc/shells
     @${RM} /etc/shells.bak

  Anmerkung:

   Die pkg-message wird nicht zur pkg-plist hinzugefu:gt. Sie wird auch nicht
   automatisch angezeigt, falls ein Anwender den Port installiert. Sie
   mu:ssen also die Ausgabe selbst im post-install-Ziel des Make-Vorgangs
   veranlassen.

8.2. pkg-install

   Sollte es no:tig sein, dass Ihr Port bei der Installation des Bina:rpakets
   mit pkg_add(1) Befehle ausfu:hrt, ko:nnen Sie das Skript pkg-install
   benutzen. Dieses Skript wird automatisch dem Paket hinzugefu:gt und
   zweimal von pkg_add(1) ausgefu:hrt: Zuerst als ${SH} pkg-install
   ${PKGNAME} PRE-INSTALL und beim zweiten Mal als ${SH} pkg-install
   ${PKGNAME} POST-INSTALL. $2 kann also getestet werden, um festzustellen,
   in welchem Modus das Skript ausgefu:hrt wird. Die Umgebungsvariable
   PKG_PREFIX wird auf das Verzeichnis gesetzt, in welches das Paket
   installiert wird. Siehe pkg_add(1) fu:r weiterfu:hrende Informationen.

  Anmerkung:

   Das Skript wird nicht automatisch ausgefu:hrt, wenn Sie den Port mit make
   install installieren. Wenn Sie es ausfu:hren lassen wollen, dann mu:ssen
   Sie es im Makefile aufrufen: PKG_PREFIX=${PREFIX} ${SH} ${PKGINSTALL}
   ${PKGNAME} PRE-INSTALL.

8.3. pkg-deinstall

   Dieses Skript wird ausgefu:hrt, wenn ein Paket deinstalliert wird.

   Es wird zweimal von pkg_delete(1) aufgerufen. Das erste Mal als ${SH}
   pkg-deinstall ${PKGNAME} DEINSTALL und dann als ${SH} pkg-deinstall
   ${PKGNAME} POST-DEINSTALL.

8.4. pkg-req

   Muss Ihr Port entscheiden, ob er installiert werden soll oder nicht,
   ko:nnen Sie ein pkg-req-"Bedingungsskript" verwenden. Dieses wird
   automatisch bei der Installation/ Deinstallation aufgerufen, um zu
   entscheiden, ob die Installation/ Deinstallation fortgesetzt werden soll.

   Das Skript wird wa:hrend der Installation von pkg_add(1) als pkg-req
   ${PKGNAME} INSTALL aufgerufen. Bei der Deinstallation wird es von
   pkg_delete(1) als pkg-req ${PKGNAME} DEINSTALL ausgefu:hrt.

8.5. A:ndern der Namen der pkg-* Dateien

   Alle Namen der pkg-* Dateien werden durch Variablen festgelegt. Sie
   ko:nnen sie bei Bedarf also im Makefile des Ports a:ndern. Das ist
   besonders nu:tzlich, wenn Sie die gleichen pkg-* Dateien in mehreren Ports
   nutzen oder in eine der oben genannten Dateien schreiben wollen. Schreiben
   Sie niemals ausserhalb des Unterverzeichnisses WRKDIR pkg-*, eine
   Erkla:rung hierzu finden Sie in Schreiben ausserhalb von WRKDIR.

   Hier ist eine Liste von Variablennamen und ihren Standardwerten (PKGDIR
   ist standardma:ssig ${MASTERDIR}).

              Variable                            Standardwert                
   DESCR                           ${PKGDIR}/pkg-descr                        
   PLIST                           ${PKGDIR}/pkg-plist                        
   PKGINSTALL                      ${PKGDIR}/pkg-install                      
   PKGDEINSTALL                    ${PKGDIR}/pkg-deinstall                    
   PKGREQ                          ${PKGDIR}/pkg-req                          
   PKGMESSAGE                      ${PKGDIR}/pkg-message                      

   Bitte benutzen Sie diese Variablen anstatt PKG_ARGS zu a:ndern. Wenn Sie
   PKG_ARGS modifizieren, werden diese Dateien bei der Installation des Ports
   nicht korrekt in /var/db/pkg installiert.

8.6. Nutzung von SUB_FILES und SUB_LIST

   Die Variablen SUB_FILES und SUB_LIST sind nu:tzlich, um dynamische Werte
   in Port-Dateien zu verwenden, wie beispielsweise der Installations-PREFIX
   in pkg-message.

   Die Variable SUB_FILES entha:lt eine Liste von Dateien, die automatisch
   vera:ndert werden. Jede Datei in SUB_FILES muss ein entsprechendes Pendant
   datei.in im Verzeichnis FILESDIR haben. Die modifizierte Version wird in
   WRKDIR angelegt. Dateien, die als Werte von USE_RC_SUBR (oder veraltet in
   USE_RCORDER) gespeichert werden, werden automatisch zu SUB_FILES
   hinzugefu:gt. Fu:r die Dateien pkg-message, pkg-install, pkg-deinstall und
   pkg-req werden die jeweiligen Makefile-Variablen selbstta:tig auf die
   gea:nderte Version der Datei gesetzt.

   Die Variable SUB_LIST ist eine Liste von VAR=WERT-Paaren. Jedes Paar
   %%VAR%% in den Dateien von SUB_FILES wird mit WERT ersetzt. Einige
   gebra:uchliche Paare werden automatisch definiert: PREFIX, LOCALBASE,
   DATADIR, DOCSDIR, EXAMPLESDIR. Jede Zeile, die mit @comment beginnt, wird
   nach der Variablen-Ersetzung aus der neu erstellten Datei gelo:scht.

   Im folgenden Beispiel wird %%ARCH%% mit der Systemarchitektur in
   pkg-message ersetzt:

 SUB_FILES=     pkg-message
 SUB_LIST=      ARCH=${ARCH}

   Beachten Sie bitte, dass in diesem Beispiel die Datei pkg-message.in im
   Verzeichnis FILESDIR vorhanden sein muss.

   Hier ein Beispiel fu:r eine gute pkg-message.in:

 Now it is time to configure this package.
 Copy %%PREFIX%%/share/examples/putsy/%%ARCH%%.conf into your home directory
 as .putsy.conf and edit it.

                          Kapitel 9. Ihren Port testen

   Inhaltsverzeichnis

   9.1. make describe ausfu:hren

   9.2. Portlint

   9.3. Port Tools

   9.4. PREFIX und DESTDIR

   9.5. Die Tinderbox

9.1. make describe ausfu:hren

   Einige der FreeBSD-Werkzeuge zur Pflege von Ports, wie zum Beispiel
   portupgrade(1), verwenden eine Datenbank names /usr/ports/INDEX, welche
   Eigenschaften, wie z.B. Port-Abha:ngigkeiten, verfolgt. INDEX wird vom
   Makefile der ho:chsten Ebene, ports/Makefile, mittels make index erstellt,
   welches in das Unterverzeichnis jedes Ports wechselt und dort make
   describe ausfu:hrt. Wenn also make describe bei einem Port fehlschla:gt,
   kann INDEX nicht generiert werden und schnell werden viele Leute daru:ber
   unzufrieden sein.

  Anmerkung:

   Es ist wichtig diese Datei erzeugen zu ko:nnen, unabha:ngig davon, welche
   Optionen in make.conf vorhanden sind. Bitte vermeiden Sie es daher
   beispielsweise .error-Anweisungen zu benutzen, wenn zum Beispiel eine
   Abha:ngigkeit nicht erfu:llt wird (Lesen Sie dazu bitte Abschnitt 12.16,
   "Vermeiden Sie den Gebrauch des .error-Konstruktes").

   Wenn make describe eine Zeichenkette anstatt einer Fehlermeldung erzeugt,
   sind Sie wahrscheinlich auf der sicheren Seite. Vergleichen Sie die
   erzeugte Zeichenkette mit bsd.port.mk, um mehr u:ber deren Bedeutung zu
   erfahren.

   Beachten Sie bitte ausserdem, dass die Benutzung einer aktuellen Version
   von portlint (wie im na:chsten Abschnitt beschrieben) automatisch make
   describe startet.

9.2. Portlint

   Bitte u:berpru:fen Sie Ihre Arbeit stets mit portlint, bevor Sie diese
   einreichen oder committen. portlint warnt Sie bei ha:ufigen Fehlern,
   sowohl funktionaler als auch stilistischer Natur. Fu:r einen neuen (oder
   repokopierten) Port ist portlint -A die gru:ndlichste Variante; fu:r einen
   bereits existierenden Port ist portlint -C ausreichend.

   Da portlint heuristische Methoden zur Fehlersuche benutzt, kann es
   vorkommen, dass Warnungen fu:r Fehler erzeugt werden, die keine sind.
   Gelegentlich kann etwas, das als Problem angezeigt wird, aufgrund von
   Einschra:nkungen im Port-System nicht anders gelo:st werden. Wenn es
   Zweifel gibt, fragen Sie am besten auf FreeBSD ports nach.

9.3. Port Tools

   Das Programm ports-mgmt/porttools ist Teil der Ports-Sammlung.

   port ist das Front-End-Skript, das Ihnen dabei behilflich sein kann Ihre
   Arbeit als Tester zu vereinfachen. Um einen neuen Port zu testen oder
   einen bereits bestehenden Port zu aktualisieren, ko:nnen Sie port test
   verwenden, damit die Tests, inklusive der portlint-U:berpru:fung,
   durchgefu:hrt werden. Dieser Befehl spu:rt ausserdem alle nicht in
   pkg-plist enthaltenen Dateien auf und gibt eine Liste dieser aus. Hier ein
   Beispiel:

 # port test /usr/ports/net/csup

9.4. PREFIX und DESTDIR

   PREFIX bestimmt, an welche Stelle der Port installiert werden soll. In der
   Regel ist dies/usr/local oder /opt, was jedoch anpassbar ist. Ihr Port
   muss sich an diese Variable halten.

   DESTDIR, wenn es vom Benutzer gesetzt wird, bestimmt die alternative
   Umgebung (in der Regel eine Jail oder ein installiertes System, welches an
   anderer Stelle als / eingeha:ngt ist). Ein Port wird unter DESTDIR/PREFIX
   installiert und registriert sich in der Paket-Datenbank unter
   DESTDIR/var/db/pkg. Da DESTDIR mittels eines chroot(8)-Aufrufs vom
   Ports-System automatisch gesetzt wird, brauchen Sie keine A:nderungen oder
   besondere Pflege fu:r DESTDIR-konforme Ports.

   Der Wert von PREFIX wird auf LOCALBASE gesetzt (Standard ist /usr/local).
   Falls USE_LINUX_PREFIX gesetzt ist, wird PREFIX LINUXBASE annehmen
   (Standard ist /compat/linux).

   Die Vermeidung der hart kodierten Angaben von /usr/local oder /usr/X11R6
   im Quelltext wird den Port viel flexibler machen und erleichtert es die
   Anforderungen anderer Einsatzorte zu erfu:llen. Fu:r X-Ports, die imake
   benutzen, geschieht dies automatisch; andernfalls kann dies erreicht
   werden, indem alle Angaben von /usr/local (oder /usr/X11R6 fu:r X-Ports,
   die nicht imake benutzen) in den verschiedenen Makefiles im Port ersetzt
   werden, um ${PREFIX} zu lesen, da diese Variable automatisch an jede Stufe
   des Build- und Install-Prozesses u:bergeben wird.

   Vergewissern Sie sich bitte, dass Ihre Anwendung nichts unter /usr/local
   an Stelle von PREFIX installiert. Um dies festzustellen, ko:nnen Sie
   folgendes machen:

 # make clean; make package PREFIX=/var/tmp/`make -V PORTNAME`

   Wenn etwas ausserhalb von PREFIX installiert wird, so gibt der Prozess der
   Paketerstellung eine Meldung aus, dass es die Dateien nicht finden kann.

   Dies pru:ft nicht das Vorhandensein eines internen Verweises oder die
   richtige Verwendung von LOCALBASE fu:r Verweise auf Dateien anderer Ports.
   Das Testen der Installation in /var/tmp/`make -V PORTNAME` wu:rde dies
   erledigen.

   Die Variable PREFIX kann in Ihrem Makefile oder der Umgebung des Benutzers
   neu gesetzt werden. Allerdings wird fu:r einzelne Ports dringend davon
   abgeraten diese Variable in den Makefiles direkt zu setzen.

   Verweisen Sie bitte ausserdem auf Programme/Dateien von anderen Ports
   durch die oben erwa:hnten Variablen und nicht mit den eindeutigen
   Pfadnamen. Wenn Ihr Port zum Beispiel vom Makro PAGER erwartet, dass es
   den vollsta:ndigen Pfadnamen von less entha:lt, benutzen Sie folgendes
   Compiler-Flag:

 -DPAGER=\"${LOCALBASE}/bin/less\"

   anstatt -DPAGER=\"/usr/local/bin/less\". Somit ist die Wahrscheinlichkeit
   ho:her, dass es auch funktioniert, wenn der Administrator den ganzen
   /usr/local-Baum an eine andere Stelle verschoben hat.

9.5. Die Tinderbox

   Wenn Sie ein begeisterter Ports-Entwickler sind mo:chten Sie vielleicht
   einen Blick auf die Tinderbox werfen. Es ist ein leistungsstarkes System
   zur Erstellung und zum Testen von Ports, welches auf Skripten basiert, die
   auf Pointyhat verwendet werden. Sie ko:nnen Tinderbox installieren, indem
   Sie den Port ports-mgmt/tinderbox benutzen. Bitte lesen Sie die
   mitgelieferte Dokumentation gru:ndlich, da die Konfiguration nicht einfach
   ist.

   Um Na:heres daru:ber zu erfahren, besuchen Sie bitte die Tinderbox
   Homepage.

               Kapitel 10. Einen existierenden Port aktualisieren

   Inhaltsverzeichnis

   10.1. Patches mit CVS erstellen

   10.2. Die Dateien UPDATING und MOVED

   Wenn Sie feststellen, dass ein Port verglichen mit der neuesten Version
   des Originalautors nicht mehr auf dem aktuellen Stand ist, sollten Sie als
   Erstes sicherstellen, dass Sie die aktuellste Version des Ports haben.
   Diese finden Sie im Verzeichnis ports/ports-current der FreeBSD
   FTP-Spiegelseiten. Wenn Sie allerdings mit mehr als ein paar Ports
   arbeiten, werden Sie es wahrscheinlich einfacher finden CVSup zu benutzen,
   um Ihre gesamte Ports-Sammlung aktuell zu halten, wie es im Handbuch
   beschrieben wird. Das hat zusa:tzlich den Vorteil, dass Sie so auch alle
   Abha:ngigkeiten des Ports aktuell halten.

   Der na:chste Schritt besteht darin festzustellen, ob bereits eine
   Aktualisierung des Ports darauf wartet committet zu werden. Um das
   sicherzustellen haben Sie folgende Mo:glichkeiten. Es gibt eine
   durchsuchbare Schnittstelle zur FreeBSD Problembericht Datenbank (PR -
   Problem Report) (auch bekannt als GNATS). Wa:hlen Sie dazu Ports im
   Drop-Down-Menu: und geben Sie den Namen des Ports ein.

   Allerdings wird manchmal vergessen den Namen des Ports eindeutig im Feld
   fu:r die Zusammenfassung anzugeben. In diesem Fall ko:nnen Sie das FreeBSD
   Ports Monitoring System (auch bekannt als portsmon) nutzen. Dieses
   versucht PRs von Ports nach Portname zu sortieren. Um PRs nach einem
   bestimmten Port zu durchsuchen ko:nnen Sie die U:bersicht eines Ports
   verwenden.

   Wenn es keine wartenden PRs gibt, ist der na:chste Schritt eine E-Mail an
   den Maintainer des Ports zu schicken, wie von make maintainer gezeigt
   wird. Diese Person arbeitet vielleicht schon an einer Aktualisierung, oder
   hat einen guten Grund den Port im Moment nicht zu aktualisieren (z.B.
   wegen Stabilita:tsproblemen der neuen Version). Sie wollen sicher nicht
   die Arbeit des Maintainers doppelt machen. Beachten Sie bitte, dass fu:r
   Ports ohne Maintainer ports@FreeBSD.org eingetragen ist. Das ist nur die
   allgemeine FreeBSD ports-Mailingliste, deshalb wird es in diesem Fall
   wahrscheinlich nicht helfen eine E-Mail dorthin zu schicken.

   Wenn Sie der Maintainer bittet die Aktualisierung zu erledigen, oder falls
   es keinen Maintainer gibt, haben Sie Gelegenheit, FreeBSD zu helfen, indem
   Sie die Aktualisierung selbst bereitstellen. Dazu verwenden Sie diff(1),
   das bereits im Basissystem enthalten ist.

   Um einen brauchbaren diff fu:r einen einzelne Datei zu erstellen, kopieren
   Sie die zu patchende Datei nach dateiname.orig und speichern Ihre
   A:nderungen in die Datei dateiname. Danach erzeugen Sie den Patch:

 % /usr/bin/diff dateiname.orig dateiname > dateiname.diff

   Soll mehr als eine Datei gepatcht werden, ko:nnen Sie entweder cvs diff
   verwenden (siehe dazu Abschnitt 10.1, "Patches mit CVS erstellen") oder
   Sie kopieren den kompletten Port in ein neues Verzeichnis und speichern
   die Ausgabe des rekursiven diff(1) auf das neue und alte Portverzeichniss
   (wenn Ihr vera:ndertes Portverzeichnis z.B. superedit und das Original
   superedit.bak heisst, dann speichern Sie bitte die Ergebnisse von diff
   -ruN superedit.bak superedit). Sowohl vereinheitlichendes als auch
   kontextabha:ngiges diff (Auflistung der Unterschiede zweier Dateien) sind
   akzeptabel, aber im Allgemeinen bevorzugen Port-Committer
   vereinheitlichende diffs. Bitte beachten Sie die Verwendung der -N-Option.
   Dies ist der gebra:uchliche Weg diff dazu zu bewegen korrekt damit
   umzugehen, neue Dateien anzulegen und alte zu lo:schen. Bevor Sie das diff
   einsenden u:berpru:fen Sie bitte die Ausgabe, um sicherzugehen, dass die
   A:nderungen sinnvoll sind. Stellen Sie insbesondere sicher, dass Sie das
   Arbeitsverzeichnis mit make clean aufgera:t haben).

   Um ga:ngige Operationen mit Korrekturdateien zu vereinfachen, ko:nnen Sie
   /usr/ports/Tools/scripts/patchtool.py benutzen. Aber lesen Sie bitte
   vorher /usr/ports/Tools/scripts/README.patchtool.

   Falls der Port keinen Maintainer hat und Sie ihn selbst aktiv benutzen,
   ziehen Sie bitte in Erwa:gung sich als Maintainer zu melden. FreeBSD hat
   mehr als 4000 Ports ohne Maintainer und in diesem Bereich werden immer
   zusa:tzliche Freiwillige beno:tigt (Fu:r eine ausfu:hrliche Beschreibung
   der Verantwortlichkeiten eines Maintainers lesen Sie bitte im Developer's
   Handbook nach).

   Der beste Weg uns das diff zu schicken ist mittels send-pr(1) (Kategorie
   Ports). Wenn Sie der Maintainer des Ports sind, fu:gen Sie bitte
   [maintainer update] an den Anfang Ihrer Zusammenfassung und setzen Sie die
   "Klasse" des PR auf maintainer-update. Ansonsten sollte die "Klasse" des
   PR change-request sein. Bitte erwa:hnen Sie alle hinzugefu:gten oder
   gelo:schten Dateien in der Nachricht, da diese beim Commit ausdru:cklich
   an cvs(1) u:bergeben werden mu:ssen. Wenn das diff gro:sser ist als 20
   Kilobyte komprimieren und uuencoden Sie es bitte. Ansonsten ko:nnen Sie es
   in den PR einfu:gen wie es ist.

   Bevor Sie den PR mit send-pr(1) abschicken, sollten Sie den Abschnitt Den
   Problembericht schreiben im Artikel u:ber Problemberichte lesen. Dieser
   entha:lt sehr viel mehr Informationen daru:ber, wie man nu:tzliche
   Problemberichte verfasst.

  Wichtig:

   Wenn Sie Ihre Aktualisierung aufgrund von Sicherheitsbedenken oder eines
   schwerwiegenden Fehlers bereitstellen wollen, informieren Sie bitte das
   Ports Management Team <portmgr@FreeBSD.org>, um einen sofortigen Rebuild
   und eine Neuverteilung des Pakets Ihres Ports durchzufu:hren. Sonst werden
   ahnungslose Nutzer von pkg_add(1) u:ber mehrere Wochen die alte Version
   durch pkg_add -r installieren.

  Anmerkung:

   Noch einmal: Bitte verwenden Sie diff(1) und nicht shar(1), um
   Aktualisierungen existierender Ports zu senden. Sie erleichtern es damit
   den Ports-Committern, Ihre A:nderungen nachzuvollziehen.

   Nun, da Sie all das geschafft haben, ko:nnen Sie in Kapitel 14, Auf dem
   Laufenden bleiben nachlesen, wie Sie den Port aktuell halten.

10.1. Patches mit CVS erstellen

   Wenn mo:glich, sollten Sie stets eine cvs(1)-Differenz einreichen. Diese
   sind leichter zu bearbeiten als Differenzen zwischen "neuen und alten"
   Verzeichnissen. Ausserdem ko:nenn Sie so einfacher feststellen, welche
   A:nderungen Sie vorgenommen haben oder Ihren Patch modifizieren, falls
   dies durch A:nderungen in einem anderen Bereich der Ports-Sammlung
   notwendig wird oder Sie vom Committer um eine Korrektur Ihres Patches
   gebeten werden.

 % cd ~/my_wrkdir 1
 % cvs -d R_CVSROOT co pdnsd 2 3
 % cd ~/my_wrkdir/pdnsd

   1 Das Verzeichnis, in dem Sie den Port bauen wollen. Dieses                
     Arbeitsverzeichnis kann sich auch ausserhalb von /usr/ports/ befinden.   
   2 R_CVSROOT steht fu:r einen o:ffentlichen CVS-Server. Eine Liste aller    
     verfu:gbaren Server finden Sie im FreeBSD Handbuch.                      
   3 Ersetzen Sie "pdnsd" durch den Modulnamen des Ports. Dieser entspricht   
     in der Regel dem Namen des Ports. Allerdings gibt es einige Ausnahmen    
     von dieser Regel, insbesondere bei sprachspezifischen Ports              
     (beispielsweise lautet der Modulname fu:r den Port german/selfhtml       
     de-selfhtml). Um den Namen des Moduls herauszufinden, ko:nnen Sie        
     entweder die cvsweb-Schnittstelle verwenden oder den kompletten Pfad des 
     Ports angeben (in unserem Beispiel wa:re der komplette Pfad also         
     ports/dns/pdnsd).                                                        

   Danach modifizieren Sie den Port in gewohnter Weise. Falls Sie Dateien
   hinzufu:gen oder entfernen, sollten Sie dies mit cvs protokollieren:

 % cvs add new_file
 % cvs remove deleted_file

   U:berpru:fen Sie die Funktion Ihres Ports anhand der Checklisten in
   Abschnitt 3.4, "Den Port testen" und Abschnitt 3.5, "Ihren Port mit
   portlint u:berpru:fen".

 % cvs status
 % cvs update 1

   1 Dadurch wird versucht, die Differenz zwischen Ihrer gea:nderten Version  
     und dem aktuellen Stand im CVS zu kombinieren. Achten Sie dabei          
     unbedingt auf die Ausgabe dieses Befehls. Vor jeder Datei wird ein       
     Buchstabe angezeigt, der Ihnen mitteilt, was mit dieser Datei passiert   
     ist. Eine vollsta:ndige Liste dieser Pra:fixe finden Sie in              
     Tabelle 10.1, "Von cvs update verwendete Pra:fixe".                      

   Tabelle 10.1. Von cvs update verwendete Pra:fixe

   U Die Datei wurde aktualisiert. Es traten dabei keine Probleme auf.        
   P Die Datei wurde ohne Probleme aktualisiert (dieses Pra:fix wird nur      
     verwendet, wenn Sie mit einem entfernten Repository arbeiten).           
   M Die Datei wurde modifiziert. Es traten keine Konflikte auf.              
   C Die Datei wurde modifiziert, allerdings kam es dabei zu Konflikten       
     zwischen Ihrer gea:nderten Version und der aktuellen Version im CVS.     

   Wird das Pra:fix C nach einem cvs update angezeigt, bedeutet dies, dass im
   CVS etwas gea:ndert wurde und cvs(1) daher nicht in der Lage war, Ihre
   A:nderungen und die A:nderungen im CVS zu kombinieren. Es ist immer
   sinnvoll, sich die A:nderungen anzusehen, da cvs keine Informationen
   daru:ber hat, wie ein Port aufgebaut sein soll. Es kann (und wird
   wahrscheinlich) daher vorkommen, dass sich manchmal A:nderungen ergeben,
   die keinen Sinn machen.

   Im letzten Schritt erzeugen Sie einen "unified diff(1)" gegen die derzeit
   im CVS vorhandenen Dateien:

 % cvs diff -uN > ../`basename ${PWD}`.diff

  Anmerkung:

   Verwenden Sie unbedingt die Option -N, um sicherzustellen, dass von
   hinzugefu:gte oder gelo:schte Dateien im Patch erfasst sind. Der Patch
   entha:t auch von Ihnen gelo:schte Dateien (allerdings ohne Inhalt). Dies
   ist wichtig, da nur so der Committer wissen kann, welche Dateien er
   entfernen muss.

   Zuletzt reichen Sie Ihren Patch ein, indem Sie der Anleitung in
   Kapitel 10, Einen existierenden Port aktualisieren folgen.

10.2. Die Dateien UPDATING und MOVED

   Wenn die Aktualisierung des Ports spezielle Schritte wie die Anpassung von
   Konfigurationsdateien oder die Ausfu:hrung eines speziellen Programms
   erfordert, sollten Sie diesen Umstand in der Datei /usr/ports/UPDATING
   dokumentieren. Eintra:ge in dieser Datei haben das folgende Format:

 YYYYMMDD:
   AFFECTS: users of portcategory/portname
   AUTHOR: Your name <Your email address>

   Special instructions

   Wenn Sie exakte Portmaster oder Portupgrade-Meldungen einfu:gen wollen,
   stellen Sie bitte sicher, dass alle Sonderzeichen korrekt dargestellt
   werden.

   Wurde der Port gelo:scht oder umbenannt, sollten Sie dies in der Datei
   /usr/ports/MOVED vermerken. Eintra:ge in dieser Datei haben das folgende
   Format:

 old name|new name (blank for deleted)|date of move|reason

                        Kapitel 11. Sicherheit der Ports

   Inhaltsverzeichnis

   11.1. Warum Sicherheit so wichtig ist

   11.2. Sicherheitslu:cken schliessen

   11.3. Die Community informiert halten

11.1. Warum Sicherheit so wichtig ist

   Es finden sich immer wieder Fehler in Software. Die gefa:hrlichsten davon
   sind wohl jene, die Sicherheitslu:cken o:ffnen. Technisch gesehen mu:ssen
   diese Lu:cken geschlossen werden, indem die Fehler, die Sie verursacht
   haben, beseitigt werden. Aber die Vorgehensweisen, wie mit blossen Fehlern
   und Sicherheitslu:cken umgegangen wird, sind sehr unterschiedlich.

   Ein typischer kleiner Fehler betrifft nur Nutzer, die eine bestimmte
   Kombination von Optionen aktiviert haben, die den Fehler auslo:st. Der
   Entwickler wird letztendlich einen Patch herausgeben, gefolgt von einer
   neuen Version des Programms, die den Fehler nicht mehr entha:lt - jedoch
   wird die Mehrheit der Nutzer nicht sofort aktualisieren, da sie von diesem
   Fehler nicht betroffen sind. Ein kritischer Fehler, der zu Datenverlust
   fu:hren kann, stellt ein schwerwiegendes Problem dar. Dennoch sind sich
   umsichtige Nutzer bewusst, dass Datenverlust verschiedene Ursachen - neben
   Softwarefehlern - haben kann, und machen deshalb Sicherungskopien
   wichtiger Daten. Zumal ein kritischer Fehler sehr schnell entdeckt wird.

   Bei einer Sicherheitslu:cke ist dies ganz anders. Erstens wird sie
   vielleicht jahrelang nicht entdeckt, da dies oftmals keine Fehlfunktion im
   Programm verursacht. Zweitens kann eine bo:swillige Person unerlaubten
   Zugriff auf ein unsicheres System erlangen, um empfindliche Daten zu
   vera:ndern oder zu zersto:ren; im schlimmsten Fall findet der Nutzer nicht
   einmal die Ursache des Schadens. Drittens hilft der Zugriff auf ein
   unsicheres System dem Angreifer oft in ein anderes System einzudringen,
   welches ansonsten nicht gefa:hrdet wa:re. Deshalb reicht es nicht aus eine
   Sicherheitslu:cke nur zu schliessen: Die Zielgruppe sollte mo:glichst
   genau und umfassend daru:ber informiert werden, damit sie die Gefahr
   einscha:tzen und passende Massnahmen ergreifen ko:nnen.

11.2. Sicherheitslu:cken schliessen

   Bei Ports und Paketen kann eine Sicherheitslu:cke im urspru:nglichen
   Programm oder in den Port-Dateien verursacht werden. Im ersten Fall wird
   der urspru:ngliche Entwickler den Fehler wahrscheinlich umgehend
   korrigieren oder eine neue Version herausgeben und Sie mu:ssen den Port
   nur aktualisieren und die Korrekturen des Autors beachten. Falls sich die
   Korrektur aus irgendeinem Grund verzo:gert, sollten Sie den Port als
   FORBIDDEN markieren oder selbst den Fehler fu:r den Port korrigieren.
   Falls die Sicherheitslu:cke im Port verursacht wird, sollten Sie ihn
   sobald wie mo:glich berichtigen. In jedem Fall sollte die
   Standardvorgehensweise zum Einreichen von A:nderungen beachtet werden - es
   sei denn, Sie haben das Recht diese direkt in den Ports-Baum zu committen.

  Wichtig:

   Ports-Committer zu sein ist nicht genug, um A:nderungen an einem
   beliebigen Port zu committen. Bitte denken Sie daran, dass Ports
   u:blicherweise Maintainer haben, die Sie respektieren sollten.

   Bitte stellen Sie sicher, dass die Revision des Ports erho:ht wird, sobald
   die Sicherheitslu:cke geschlossen wurde. Dadurch sehen die Nutzer, die
   installierte Pakete regelma:ssig aktualisieren, dass es an der Zeit ist
   eine Aktualisierung durchzufu:hren. Ausserdem wird ein neues Paket gebaut,
   u:ber FTP- und WWW-Spiegel verteilt und die unsichere Version damit
   verdra:ngt. PORTREVISION sollte erho:ht werden - es sei denn, PORTREVISION
   hat sich im Laufe der Korrektur des Fehlers gea:ndert. Das heisst, Sie
   sollten PORTREVISION erho:hen, wenn Sie eine Korrektur hinzugefu:gt haben.
   Sie sollten diese aber nicht erho:hen, wenn Sie den Port auf die neueste
   Version des Programms gebracht haben und PORTREVISION somit schon
   vera:ndert wurde. Bitte beachten Sie den betreffenden Abschnitt fu:r
   weitere Informationen.

11.3. Die Community informiert halten

  11.3.1. Die VuXML-Datenbank

   Ein sehr wichtiger und dringender Schritt, den man unternehmen muss,
   sobald eine Sicherheitslu:cke entdeckt wurde, ist die Gemeinschaft der
   Anwender des Ports u:ber die Gefahr zu informieren. Diese Benachrichtigung
   hat zwei Gru:nde. Erstens wird es sinnvoll sein, wenn die Gefahr wirklich
   so gross ist, sofort Abhilfe zu schaffen, indem man z.B. den betreffenden
   Netzwerkdienst beendet oder den Port komplett deinstalliert, bis die
   Lu:cke geschlossen wurde. Und Zweitens pflegen viele Nutzer installierte
   Pakete nur gelegentlich zu aktualisieren. Sie werden aus der Mitteilung
   erfahren, dass Sie das Paket, sobald eine Korrektur verfu:gbar ist, sofort
   aktualisieren mu:ssen.

   Angesichts der riesigen Zahl an Ports kann nicht fu:r jeden Vorfall ein
   Sicherheitshinweis erstellt werden, ohne durch die Flut an Nachrichten die
   Aufmerksamkeit der Empfa:nger zu verlieren, im Laufe der Zeit kommt es so
   zu ernsten Problemen. Deshalb werden Sicherheitslu:cken von Ports in der
   FreeBSD VuXML-Datenbank aufgezeichnet. Das Team der
   Sicherheitsverantwortlichen beobachtet diese wegen Angelegenheiten, die
   Ihr Eingreifen erfordern.

   Wenn Sie Committerrechte haben, ko:nnen Sie die VuXML-Datenbank selbst
   aktualisieren. Auf diese Weise helfen Sie den Sicherheitsverantwortlichen
   und liefern die kritischen Informationen fru:hzeitig an die Community.
   Aber auch wenn Sie kein Committer sind und glauben, Sie haben eine
   aussergewo:hnlich schwerwiegende Lu:cke gefunden - egal welche - zo:gern
   Sie bitte nicht die Sicherheitsverantwortlichen zu kontaktieren, wie es in
   den FreeBSD Sicherheitsinformationen beschrieben wird.

   Wie vielleicht aus dem Titel hervorgeht, handelt es sich bei der
   VuXMl-Datenbank um ein XML-Dokument. Die Quelldatei vuln.xml ko:nnen Sie
   im Port security/vuxml finden. Deshalb wird der komplette Pfadname
   PORTSDIR/security/vuxml/vuln.xml lauten. Jedes Mal, wenn Sie eine
   Sicherheitslu:cke in einem Port entdecken, fu:gen Sie bitte einen Eintrag
   dafu:r in diese Datei ein. Solange Sie nicht mit VuXML vertraut sind, ist
   es das Beste, was Sie machen ko:nnen, einen vorhandenen Eintrag, der zu
   Ihrem Fall passt, zu kopieren und als Vorlage zu verwenden.

  11.3.2. Eine kurze Einfu:hrung in VuXML

   Das komplette XML ist komplex und wu:rde den Rahmen dieses Buches
   sprengen. Allerdings beno:tigen Sie fu:r einen grundlegenden Einblick in
   die Struktur eines VuXML-Eintrags nur eine Vorstellung der Tags. XML-Tags
   bestehen aus Namen, die in spitzen Klammern eingeschlossen sind. Zu jedem
   o:ffnenden <Tag> muss ein passendes </Tag> existieren. Tags ko:nnen
   geschachtelt werden. Wenn sie geschachtelt werden mu:ssen die inneren Tags
   vor den A:usseren geschlossen werden. Es gibt eine Hierarchie von
   Tags - das heisst komplexere Regeln zur Schachtelung. Klingt so a:hnlich
   wie HTML, oder? Der gro:sste Unterschied ist: XML ist erweiterbar
   (eXtensible) - das heisst es basiert darauf massgeschneiderte Tags zu
   definieren. Aufgrund seiner wesentlichen Struktur bringt XML ansonsten
   formlose Daten in eine bestimmte Form. VuXML ist speziell darauf
   zugeschnitten Beschreibungen von Sicherheitslu:cken zu verwalten.

   Lassen Sie uns nun einen realistischen VuXML-Eintrag betrachten:

 <vuln vid="f4bc80f4-da62-11d8-90ea-0004ac98a7b9"> 1
   <topic>Several vulnerabilities found in Foo</topic> 2
   <affects>
     <package>
       <name>foo</name> 3
       <name>foo-devel</name>
       <name>ja-foo</name>
       <range><ge>1.6</ge><lt>1.9</lt></range> 4
       <range><ge>2.*</ge><lt>2.4_1</lt></range>
       <range><eq>3.0b1</eq></range>
     </package>
     <package>
       <name>openfoo</name> 5
       <range><lt>1.10_7</lt></range> 6
       <range><ge>1.2,1</ge><lt>1.3_1,1</lt></range>
     </package>
   </affects>
   <description>
     <body xmlns="http://www.w3.org/1999/xhtml">
       <p>J. Random Hacker reports:</p> 7
       <blockquote
         cite="http://j.r.hacker.com/advisories/1">
         <p>Several issues in the Foo software may be exploited
           via carefully crafted QUUX requests.  These requests will
           permit the injection of Bar code, mumble theft, and the
           readability of the Foo administrator account.</p>
       </blockquote>
     </body>
   </description>
   <references> 8
     <freebsdsa>SA-10:75.foo</freebsdsa> 9
     <freebsdpr>ports/987654</freebsdpr> 10
     <cvename>CAN-2010-0201</cvename> 11
     <cvename>CAN-2010-0466</cvename>
     <bid>96298</bid> 12
     <certsa>CA-2010-99</certsa> 13
     <certvu>740169</certvu> 14
     <uscertsa>SA10-99A</uscertsa> 15
     <uscertta>SA10-99A</uscertta> 16
     <mlist msgid="201075606@hacker.com">http://marc.theaimsgroup.com/?l=bugtraq&amp;m=203886607825605</mlist> 17
     <url>http://j.r.hacker.com/advisories/1</url> 18
   </references>
   <dates>
     <discovery>2010-05-25</discovery> 19
     <entry>2010-07-13</entry> 20
     <modified>2010-09-17</modified> 21
   </dates>
 </vuln>

   Die Namen der Tags sollten selbsterkla:rend sein  - also werfen wir einen
   genaueren Blick auf die Felder, die Sie selbst ausfu:llen mu:ssen:

   1  Dies ist die ho:chste Tag-Ebene eines VuXML-Eintrags. Es ist ein        
      vorgeschriebenes Attribut vid, welches eine allgemein einzigartige      
      Kennung (universally unique identifier, UUID) in Anfu:hrungszeichen     
      fu:r diesen Eintrag festlegt. Sie sollten eine UUID fu:r jeden neuen    
      VuXML-Eintrag erzeugen (und vergessen Sie nicht die UUID der Vorlage zu 
      ersetzen, es sei denn, Sie schreiben den Eintrag von Grund auf selbst). 
      Sie ko:nnen uuidgen(1) verwenden, um eine VuXML UUID zu erzeugen.       
   2  Dies ist eine einzeilige Beschreibung des gefundenen Fehlers.           
   3  Hier werden die Namen betroffener Pakete aufgefu:hrt. Es ko:nnen        
      mehrere Namen angegeben werden, da mehrere Pakete von einem einzigen    
      Master-Port oder Software-Produkt abha:ngen ko:nnen. Das schliesst      
      Stable- und Developement-Zweige, lokalisierte Versionen und Slave-Ports 
      ein, die verschiedene Auswahlmo:glichkeiten wichtiger                   
      Kompilierungszeit-Optionen bieten.                                      
                                                                              
        Wichtig:                                                              
                                                                              
      Es liegt in Ihrer Verantwortung all diese betroffenen Pakete zu finden, 
      wenn Sie den VuXML-Eintrag schreiben.Behalten Sie im Hinterkopf, dass   
      make search name=foo Ihr Freund ist. Die wichtigsten Punkte, auf die    
      Sie achten sollten, sind die folgenden:                                 
                                                                              
        * die foo-devel Variante eines foo Ports;                             
                                                                              
        * andere Varianten mit einem Suffix wie -a4 (fu:r Druck-betreffende   
          Pakete), -without-gui (fu:r Pakete mit deaktivierter                
          X-Unterstu:tzung) oder a:hnliche                                    
                                                                              
        * jp-, ru-, zh- und andere, eventuell lokalisierte, Varianten in den  
          entsprechenden La:nderkategorien der Ports-Sammlung                 
   4  Betroffene Versionen der Pakete werden hier als ein Bereich oder        
      mehrere durch eine Kombination aus <lt>, <le> , <eq>, <ge>, und         
      <gt>-Elementen ausgegeben. Die angegebenen Bereiche sollten sich nicht  
      u:berschneiden.                                                         
                                                                              
      In einer Bereichsangabe steht * (Asterisk) fu:r die kleinste            
      Versionsnummer. Insbesondere ist 2.* kleiner als 2.a. Deshalb kann ein  
      Stern benutzt werden, um auf alle mo:glichen Alpha -, Beta- und RC      
      -Versionen zuzutreffen. Zum Beispiel passt <ge>2.*</ge><lt>3.* </lt>    
      auf alle Versionen der Form 2.x, wa:hrend <ge> 2.0</ge><lt>3.0</lt> das 
      nicht erfu:llt, da es nicht auf 2.r3 passt, auf 3.b aber schon.         
                                                                              
      Das obige Beispiel legt fest, dass Versionen von 1.6 bis 1.9 betroffen  
      sind - ausserdem Versionen 2.x vor 2.4_1 und Version 3.0b1.             
   5  Mehrere zusammenha:ngende Gruppen von Paketen (im wesentlichen Ports)   
      ko:nnen im Abschnitt <affected> aufgefu:hrt werden. Das kann man        
      benutzen, wenn sich Programme (sagen wir FooBar, FreeBar und OpenBar)   
      denselben Quelltext als Grundlage haben und sich noch dessen Fehler und 
      Sicherheitslu:cken teilen. Beachten Sie den Unterschied zum Anfu:hren   
      mehrerer Namen innerhalb eines <package> Abschnittes.                   
   6  Die Versionsbereiche sollten, wenn mo:glich, sowohl PORTEPOCH als auch  
      PORTREVISION erlauben. Bitte denken Sie daran, dass gema:ss der         
      Vergleichsregeln eine Version mit einer PORTEPOCH, die nicht Null ist,  
      gro:sser ist als jede Version ohne PORTEPOCH. Das heisst, 3.0,1 ist     
      gro:sser als 3.1 oder sogar 8.9.                                        
   7  Das ist die Zusammenfassung des Problems. In diesem Feld wird XHTML     
      verwendet. Zumindest umschliessende <p> und </p> sollten auftauchen.    
      Komplexere Tags sind zwar mo:glich, aber sollten nur um der Genauigkeit 
      und Klarheit willen verwendet werden: Bitte verwenden Sie hier kein     
      Eye-Candy.                                                              
   8  Dieser Abschnitt entha:lt Verweise auf relevante Dokumente. Es wird     
      empfohlen so viele Referenzen wie no:tig aufzufu:hren.                  
   9  Das ist ein FreeBSD Sicherheitshinweis.                                 
   10 Das ist ein FreeBSD Problembericht.                                     
   11 Das ist eine Mitre CVE Kennung.                                         
   12 Das ist eine SecurityFocus Fehler-Kennung.                              
   13 Das ist ein Sicherheitshinweis von US-CERT.                             
   14 Das ist eine Mitteilung u:ber eine Schwachstelle von US-CERT.           
   15 Das ist ein Cyber-Sicherheitsalarm von US-CERT.                         
   16 Das ist ein technischer Cyber-Sicherheitsalarm von US-CERT.             
   17 Das ist eine URL zu einem archivierten Posting auf einer Mailingliste.  
      Das Attribut msgid ist optional und gibt die Nachrichtenkennung des     
      Postings an.                                                            
   18 Das ist eine gewo:hnliche URL. Sie sollte nur verwendet werden, wenn    
      keine der anderen Referenzkategorien verfu:gbar ist.                    
   19 Das ist das Datum, an dem die Sicherheitslu:cke bekannt wurde           
      (JJJJ-MM-TT).                                                           
   20 Das ist das Datum, an dem der Eintrag hinzugefu:gt wurde (JJJJ-MM-TT).  
   21 Das ist das Datum, an dem zuletzt irgendeine Information des Eintrags   
      vera:ndert wurde (JJJJ-MM-TT). Neue Eintra:ge du:rfen dieses Feld nicht 
      enthalten. Es sollte beim Editieren eines existierenden Eintrags        
      eingefu:gt werden.                                                      

  11.3.3. Ihre A:nderungen an der VuXML-Datenbank testen

   Nehmen wir an, Sie haben gerade einen Eintrag fu:r eine Sicherheitslu:cke
   in dem Paket clamav geschrieben oder ausgefu:llt, die in der Version
   0.65_7 korrigiert wurde.

   Als Voraussetzung mu:ssen Sie die aktuellen Versionen der Ports
   ports-mgmt/portaudit, ports-mgmt/portaudit-db sowie security/vuxml
   installieren.

  Anmerkung:

   Um packaudit auszufu:hren, mu:ssen Sie die Berechtigung haben DATABASEDIR
   zu schreiben - u:blicherweise ist das /var/db/portaudit.

   Durch Setzen der Umgebungsvariable DATABASEDIR ko:nnen Sie hier auch ein
   anderes Verzeichnis angeben.

   Arbeiten Sie nicht aus dem Verzeichnis ${PORTSDIR}/security/vuxml heraus,
   mu:ssen Sie zusa:tzlich die Umgebungsvariable VUXMLDIR setzen, um
   anzugeben, in welchem Verzeichnis sich die Datei vuln.xml befindet.

   Zuerst u:berpru:fen Sie bitte, ob bereits ein Eintrag fu:r diese
   Schwachstelle existiert. Wenn es einen solchen Eintrag gibt, sollte er auf
   die vorige Version 0.65_6 zutreffen:

 % packaudit
 % portaudit clamav-0.65_6

   Wenn keine vorhandenen Eintra:ge gefunden werden haben Sie gru:nes Licht,
   einen neuen Eintrag fu:r diese Sicherheitslu:cke anzulegen. Sie ko:nnen
   nun eine neue UUID erzeugen (wir nehmen an, diese lautet
   74a9541d-5d6c-11d8-80e3-0020ed76ef5a) und einen neuen Eintrag in der
   VuXML-Datenbank anlegen. Bitte u:berpru:fen Sie danach die Syntax mit
   folgendem Befehl:

 % cd ${PORTSDIR}/security/vuxml && make validate

  Anmerkung:

   Sie werden zumindest eines der folgenden Pakete beno:tigen:
   textproc/libxml2, textproc/jade.

   Jetzt bauen Sie bitte die portaudit-Datenbank aus der VuXML-Datei neu:

 % packaudit

   Um sicherzustellen, dass der Abschnitt <affected> Ihres Eintrags die
   richtigen Pakete betrifft, verwenden Sie bitte den folgenden Befehl:

 % portaudit -f /usr/ports/INDEX -r 74a9541d-5d6c-11d8-80e3-0020ed76ef5a

  Anmerkung:

   Bitte lesen Sie in portaudit(1) nach, um ein besseres Versta:ndnis der
   Befehlssyntax zu entwickeln.

   Bitte stellen Sie sicher, dass Ihr Eintrag keine falschen Treffer in der
   Ausgabe erzeugt.

   Jetzt u:berpru:fen Sie bitte, dass Ihr Eintrag die richtigen Versionen des
   Pakets angibt:

 % portaudit clamav-0.65_6 clamav-0.65_7
 Affected package: clamav-0.65_6 (matched by clamav<0.65_7)
 Type of problem: clamav remote denial-of-service.
 Reference: <http://www.freebsd.org/ports/portaudit/74a9541d-5d6c-11d8-80e3-0020ed76ef5a.html>

 1 problem(s) found.

   Offensichtlich sollte die erste Version ausgegeben werden - die zweite
   jedoch nicht.

   Abschliessend u:berpru:fen Sie bitte, ob die Webseite, die aus der
   VuXML-Datenbank erzeugt wird, wie erwartet aussieht:

 % mkdir -p ~/public_html/portaudit
 % packaudit
 % lynx ~/public_html/portaudit/74a9541d-5d6c-11d8-80e3-0020ed76ef5a.html

             Kapitel 12. Was man machen respektive vermeiden sollte

   Inhaltsverzeichnis

   12.1. Einfu:hrung

   12.2. WRKDIR

   12.3. WRKDIRPREFIX

   12.4. Unterschiedliche Betriebssysteme und Betriebssystemversionen

   12.5. __FreeBSD_version Werte

   12.6. Etwas hinter die bsd.port.mk-Anweisung schreiben

   12.7. Benutzen Sie die exec-Anweisung in Wrapper-Skripten

   12.8. Aufgaben vernu:nftig lo:sen

   12.9. Beru:cksichtigen Sie sowohl CC als auch CXX

   12.10. Beru:cksichtigen Sie CFLAGS

   12.11. Threading-Bibliotheken

   12.12. Ru:ckmeldungen

   12.13. README.html

   12.14. Einen Port durch BROKEN, FORBIDDEN oder IGNORE als nicht
   installierbar markieren

   12.15. Kennzeichnen eines Ports zur Entfernung durch DEPRECATED oder
   EXPIRATION_DATE

   12.16. Vermeiden Sie den Gebrauch des .error-Konstruktes

   12.17. Verwendung von sysctl

   12.18. Erneutes Ausliefern von Distfiles

   12.19. Verschiedenes

12.1. Einfu:hrung

   Hier ist eine Liste von gebra:uchlichen Dos and Don'ts (Dinge, die man
   machen oder vermeiden sollte), welchen Sie wa:hrend des
   Portierungsprozesses begegnen werden. Sie sollten Ihren Port anhand dieser
   Liste u:berpru:fen. Sie ko:nnen auch Ports in der PR Datenbank, welche
   andere Menschen eingereicht haben, kontrollieren. Senden Sie bitte
   Kommentare zu Ports, die Sie verifizieren wie unter Bug Reports and
   General Commentary beschrieben. Der Abgleich von Ports aus der
   PR-Datenbank hilft uns diese schneller zu committen, und zeigt auch, dass
   Sie wissen, worum es geht.

12.2. WRKDIR

   Schreiben Sie in keine Dateien ausserhalb von WRKDIR. WRKDIR ist der
   einzige Ort, welcher wa:hrend des Erstellen des Ports garantiert
   beschreibbar ist (siehe Ports Installieren von CDROM fu:r ein Beispiel, um
   Ports in einem schreibgeschu:tzen Zweig zu erstellen). Wenn Sie eine der
   pkg-* Dateien modifizieren mu:ssen, sollten Sie eine Variable erneut
   definieren, anstatt die Datei zu u:berschreiben.

12.3. WRKDIRPREFIX

   Vergewissern Sie sich, dass Ihr Port WRKDIRPREFIX beachtet. Die meisten
   Ports sollten sich daru:ber keine Sorgen machen. Beachten Sie bitte, falls
   auf WRKDIR eines anderen Ports verwiesen wird, dass die korrekte Position
   WRKDIRPREFIXPORTSDIR/subdir/name/work, und nicht etwa
   PORTSDIR/subdir/name/work, .CURDIR/../../subdir/name/work oder a:hnliches
   ist.

   Falls Sie WRKDIR selbst definieren, sollten Sie sicherstellen, dass Sie
   ${WRKDIRPREFIX}${.CURDIR} am Anfang anfu:gen.

12.4. Unterschiedliche Betriebssysteme und Betriebssystemversionen

   Sie ko:nnen auf Quelltext treffen, welcher Modifizierungen oder bedingtes
   Kompilieren, abha:ngig davon, unter welcher Unix-Version er la:uft,
   beno:tigt. Falls Sie A:nderungen an solch einem Quelltext vornehmen
   mu:ssen, stellen Sie bitte sicher, dass Sie Ihre A:nderungen so allgemein
   wie mo:glich halten, damit wir den Quelltext auf a:ltere FreeBSD-Systeme
   portieren und zur Quer-Portierung auf andere BSD-Systeme, wie etwa 4.4BSD
   von CSRG, BSD/386, 386BSD, NetBSD und OpenBSD verwenden ko:nnen.

   Der bevorzugte Weg, um 4.3BSD/Reno (1990) und neuere Versionen des
   BSD-Quelltextes zu unterscheiden, ist das BSD-Makro zu nutzen, welches in
   sys/param.h definiert ist. Hoffentlich ist diese Datei schon
   enthalten - falls nicht, so fu:gen Sie folgenden Quelltext:

 #if (defined(__unix__) || defined(unix)) && !defined(USG)
 #include <sys/param.h>
 #endif

   an der richtigen Stelle in der .c Datei hinzu. Wir glauben, dass jedes
   System, welches diese beiden Symbole definiert, die Datei sys/param.h
   besitzt. Wenn Sie auf Systeme stossen, wo dies nicht so ist, wu:rden wir
   gerne davon erfahren. Bitte senden Sie eine E-Mail an FreeBSD ports.

   Eine andere Mo:glichkeit zur Unterscheidung ist der GNU Autoconf-Stil:

 #ifdef HAVE_SYS_PARAM_H
 #include <sys/param.h>
 #endif

   Vergessen Sie nicht -DHAVE_SYS_PARAM_H zu den CFLAGS im Makefile
   hinzuzufu:gen, falls Sie diese Methode benutzen sollten.

   Sobald Sie sys/param.h hinzugefu:gt haben, ko:nnen Sie mit Hilfe von

 #if (defined(BSD) && (BSD >= 199103))

   unterscheiden, ob der Quelltext auf einer 4.3 Net2 Code-Basis oder neuer
   (z.B. FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1 und
   niedriger) kompiliert werden wird.

   Benutzen Sie:

 #if (defined(BSD) && (BSD >= 199306))

   um zu differenzieren, ob der Quelltext auf der Basis von 4.4 Code oder
   neuer (z.B. FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0 oder ho:her)
   kompiliert werden wird.

   Der Wert des BSD-Makros ist 199506 fu:r die 4.4BSD-Lite2 Codebasis.
   Beachten Sie bitte, dass dies hier nur der Information wegen angegeben
   ist. Das Makro sollte nicht dazu benutzt werden, um zwischen Versionen von
   FreeBSD, welche auf 4.4-Lite basieren, und Versionen, welche A:nderungen
   von 4.4-Lite2 u:bernommen haben, zu unterscheiden. Das __FreeBSD__ Makro
   sollte stattdessen verwandt werden.

   Sparsam sollte eingesetzt werden:

     * __FreeBSD__ ist in allen Versionen von FreeBSD definiert. Benutzen Sie
       dieses Makro, falls die A:nderung(en), die Sie machen, nur FreeBSD
       betrifft. Portierungsfallen, wie der Gebrauch von sys_errlist[]
       gegenu:ber strerror() sind Berkeley-Eigenheiten, keine FreeBSD
       A:nderungen.

     * In FreeBSD 2.x, ist __FreeBSD__ auf 2 definiert. In a:lteren
       Versionen, ist es 1. Alle spa:teren Versionen erho:hen es, damit es
       mit der Haupt-Versionsnummer u:bereinstimmt.

     * Falls Sie zwischen einem FreeBSD 1.x und einem FreeBSD 2.x (oder
       ho:her) System unterscheiden mu:ssen, ist es normalerweise richtig,
       die BSD-Makros (wie oben beschrieben) zu benutzen. Gibt es
       tatsa:chlich eine FreeBSD-spezifische A:nderung (wie z.B. spezielle
       Optionen von Shared-Libraries fu:r ld), ist es nicht zu beanstanden
       __FreeBSD__ und #if __FreeBSD__ > 1 zu nutzen, um FreeBSD 2.x und
       spa:tere Systeme zu erkennen. Falls Sie eine ho:here Genauigkeit
       beno:tigen, um FreeBSD Systeme seit 2.0-RELEASE zu erkennen, ko:nnen
       Sie folgendes nutzen:

 #if __FreeBSD__ >= 2
 #include <osreldate.h>
 #    if __FreeBSD_version >= 199504
          /* 2.0.5+ release specific code here */
 #    endif
 #endif

   In den Tausenden von Ports, die bis jetzt erstellt wurden, gab es nur ein
   oder zwei Fa:lle, in denen __FreeBSD__ ha:tte benutzt werden sollen. Nur
   weil ein fru:herer Port es an der falschen Stelle benutzt hatte, bedeutet
   das nicht, dass Sie dies auch machen sollten.

12.5. __FreeBSD_version Werte

   Hier ist eine praktische Liste von __FreeBSD_version-Werten wie in
   sys/param.h definiert:

   Tabelle 12.1. __FreeBSD_version-Werte

      Wert          Datum                          Release                    
   119411                        2.0-RELEASE                                  
   199501,    19. Ma:rz 1995     2.1-CURRENT                                  
   199503     
   199504     9. April 1995      2.0.5-RELEASE                                
   199508     26. August 1995    2.2-CURRENT vor 2.1                          
   199511     10. November 1995  2.1.0-RELEASE                                
   199512     10. November 1995  2.2-CURRENT vor 2.1.5                        
   199607     10. Juli 1996      2.1.5-RELEASE                                
   199608     12. Juli 1996      2.2-CURRENT vor 2.1.6                        
   199612     15. November 1996  2.1.6-RELEASE                                
   199612                        2.1.7-RELEASE                                
   220000     19. Februar 1997   2.2-RELEASE                                  
   (nicht                        2.2.1-RELEASE                                
   gea:ndert) 
   (nicht                        2.2-STABLE nach 2.2.1-RELEASE                
   gea:ndert) 
   221001     15. April 1997     2.2-STABLE nach texinfo-3.9                  
   221002     30. April 1997     2.2-STABLE nach top                          
   222000     16. Mai 1997       2.2.2-RELEASE                                
   222001     19. Mai 1997       2.2-STABLE nach 2.2.2-RELEASE                
   225000     2. Oktober 1997    2.2.5-RELEASE                                
   225001     20. November 1997  2.2-STABLE nach 2.2.5-RELEASE                
   225002     27. Dezember 1997  2.2-STABLE nach der Aufnahme von ldconfig -R 
   226000     24. Ma:rz 1998     2.2.6-RELEASE                                
   227000     21. Juli 1998      2.2.7-RELEASE                                
   227001     21. Juli 1998      2.2-STABLE nach 2.2.7-RELEASE                
   227002     19. September 1998 2.2-STABLE nach semctl(2) A:nderung          
   228000     29. November 1998  2.2.8-RELEASE                                
   228001     29. November 1998  2.2-STABLE nach 2.2.8-RELEASE                
   300000     19. Februar 1996   3.0-CURRENT vor mount(2) A:nderung           
   300001     24. September 1997 3.0-CURRENT nach mount(2) A:nderung          
   300002     2. Juni 1998       3.0-CURRENT nach semctl(2) A:nderung         
   300003     7. Juni 1998       3.0-CURRENT nach ioctl arg A:nderungen       
   300004     3. September 1998  3.0-CURRENT nach ELF-Konvertierung           
   300005     16. Oktober 1998   3.0-RELEASE                                  
   300006     16. Oktober 1998   3.0-CURRENT nach 3.0-RELEASE                 
   300007     22. Januar 1999    3.0-STABLE nach 3/4 Zweig                    
   310000     9. Februar 1999    3.1-RELEASE                                  
   310001     27. Ma:rz 1999     3.1-STABLE nach 3.1-RELEASE                  
   310002     14. April 1999     3.1-STABLE nach A:nderung der C++            
                                 Konstruktor/Destruktor-Reihenfolge           
   320000                        3.2-RELEASE                                  
   320001     8. Mai 1999        3.2-STABLE                                   
   320002     29. August 1999    3.2-STABLE nach bina:r-inkompatibler IPFW    
                                 und Socket-A:nderungen                       
   330000     2. September 1999  3.3-RELEASE                                  
   330001     16. September 1999 3.3-STABLE                                   
   330002     24. November 1999  3.3-STABLE nach Hinzufu:gen von mkstemp(3)   
                                 zur libc                                     
   340000     5. Dezember 1999   3.4-RELEASE                                  
   340001     17. Dezember 1999  3.4-STABLE                                   
   350000     20. Juni 2000      3.5-RELEASE                                  
   350001     12. Juli 2000      3.5-STABLE                                   
   400000     22. Januar 1999    4.0-CURRENT nach 3.4 Zweig                   
   400001     20. Februar 1999   4.0-CURRENT nach der A:nderung im Verhalten  
                                 des dynamischen Linkers.                     
   400002     13. Ma:rz 1999     4.0-CURRENT nach A:nderung der C++           
                                 Konstruktor/Destruktor Reihenfolge.          
   400003     27. Ma:rz 1999     4.0-CURRENT nach funktionierendem dladdr(3). 
                                 4.0-CURRENT nach der __deregister_frame_info 
   400004     5. April 1999      Fehlerbehebung fu:r den dynamischen Linker   
                                 (auch 4.0-CURRENT nach EGCS 1.1.2            
                                 Integration).                                
   400005     27. April 1999     4.0-CURRENT nach suser(9) API A:nderung      
                                 (auch 4.0-CURRENT nach newbus).              
   400006     31. Mai 1999       4.0-CURRENT nach A:nderung der               
                                 cdevsw-Registrierung.                        
   400007     17. Juni 1999      4.0-CURRENT nach Hinzufu:gen von so_cred     
                                 fu:r Zugangsberechtigungen auf Socket-Ebene. 
   400008     20. Juni 1999      4.0-CURRENT nach Hinzufu:gen eines poll      
                                 Syscall-Wrappers zur libc_r.                 
   400009     20. Juli 1999      4.0-CURRENT nach der A:nderung des Kernel    
                                 dev_t-Typs zum struct specinfo-Zeiger.       
   400010     25. September 1999 4.0-CURRENT nach dem Beseitigen eines        
                                 Fehlers in jail(2).                          
   400011     29. September 1999 4.0-CURRENT nach der sigset_t Datentyp       
                                 A:nderung.                                   
   400012     15. November 1999  4.0-CURRENT nach dem Wechsel zum GCC         
                                 2.95.2-Compiler.                             
   400013     4. Dezember 1999   4.0-CURRENT nach Hinzufu:gen der             
                                 erweiterbaren Linux Mode ioctl-Routinen.     
   400014     18. Januar 2000    4.0-CURRENT nach dem OpenSSL-Import.         
                                 4.0-CURRENT nach der C++ ABI A:nderung in    
   400015     27. Januar 2000    GCC 2.95.2 von -fvtable-thunks zu            
                                 -fno-vtable-thunks als Standard.             
   400016     27. Februar 2000   4.0-CURRENT nach OpenSSH-Import.             
   400017     13. Ma:rz 2000     4.0-RELEASE                                  
   400018     17. Ma:rz 2000     4.0-STABLE nach 4.0-RELEASE                  
   400019     5. Mai 2000        4.0-STABLE nach der Einfu:hrung von          
                                 verzo:gerten Pru:fsummen.                    
   400020     4. Juni 2000       4.0-STABLE nach dem Einpflegen des           
                                 libxpg4-Quelltextes in die libc.             
                                 4.0-STABLE nach der Aktualisierung von       
   400021     8. Juli 2000       Binutils auf 2.10.0, A:nderungen der         
                                 bina:ren ELF-Markierungen, Aufnahme von tcsh 
                                 ins Basissystem.                             
   410000     14. Juli 2000      4.1-RELEASE                                  
   410001     29. Juli 2000      4.1-STABLE nach 4.1-RELEASE                  
   410002     16. September 2000 4.1-STABLE nachdem setproctitle(3) von der   
                                 libutil in die libc verschoben wurde.        
   411000     25. September 2000 4.1.1-RELEASE                                
   411001                        4.1.1-STABLE nach 4.1.1-RELEASE              
   420000     31. Oktober 2000   4.2-RELEASE                                  
                                 4.2-STABLE nach Kombinaion von libgcc.a und  
   420001     10. Januar 2001    libgcc_r.a und zugeho:rigen A:nderungen der  
                                 GCC-Bindungen.                               
   430000     6. Ma:rz 2001      4.3-RELEASE                                  
   430001     18. Mai 2001       4.3-STABLE nach der Einfu:hrung von wint_t.  
   430002     22. Juli 2001      4.3-STABLE nach dem Einpflegen der PCI       
                                 Stromstatus-API.                             
   440000     1. August 2001     4.4-RELEASE                                  
   440001     23. Oktober 2001   4.4-STABLE nach der Einfu:hrung von          
                                 d_thread_t.                                  
                                 4.4-STABLE nach den A:nderungen der          
   440002     4. November 2001   mount-Struktur (betrifft                     
                                 Dateisystem-Kernelmodule).                   
   440003     18. Dezember 2001  4.4-STABLE nachdem die Userland-Komponenten  
                                 von smbfs importiert worden sind.            
   450000     20. Dezember 2001  4.5-RELEASE                                  
   450001     24. Februar 2002   4.5-STABLE nach der Umbenennung von          
                                 Elementen der USB-Struktur.                  
                                 4.5-STABLE nachdem die sendmail_enable       
   450004     16. April 2002     rc.conf(5) Variable gea:ndert worden ist, um 
                                 den Wert NONE zu akzeptieren.                
   450005     27. April 2002     4.5-STABLE nachdem XFree86 4 als Standard    
                                 zum Bauen der Pakete benutzt wird.           
                                 4.5-STABLE nach dem Reparieren des           
   450006     1. Mai 2002        Empfangsfilters, welcher anfa:llig fu:r      
                                 einfache DoS-Attacken war.                   
   460000     21. Juni 2002      4.6-RELEASE                                  
                                 4.6-STABLE sendfile(2) repariert, um mit der 
                                 Dokumentation u:bereinzustimmen, und nicht   
   460001     21. Juni 2002      mehr die Anzahl der gesendeten Header mit    
                                 der Anzahl der Daten, welche aus der Datei   
                                 geschickt werden, gegenzurechnen.            
   460002     19. Juli 2002      4.6.2-RELEASE                                
   460100     26. Juni 2002      4.6-STABLE                                   
   460101     26. Juni 2002      4.6-STABLE nach dem Einfliessen von `sed -i' 
                                 aus CURRENT.                                 
                                 4.6-STABLE nach dem Einfliessen von vielen   
   460102     1. September 2002  neuen pkg_install-Funktionen aus HEAD (HEAD  
                                 = die aktuellste und letzte Version des      
                                 Quellverzeichnisbaumes).                     
   470000     8. Oktober 2002    4.7-RELEASE                                  
   470100     9. Oktober 2002    4.7-STABLE                                   
                                 Beginn von generierten __std{in,out,err}p    
   470101     10. November 2002  Referenzen statt __sF. Dies a:ndert          
                                 std{in,out,err} von einem Ausdruck wa:hrend  
                                 des Kompilierens zu einem Laufzeitausdruck.  
                                 4.7-STABLE nach dem Einfliessen von          
   470102     23. Januar 2003    mbuf-A:nderungen, um m_aux mbufs mit denen   
                                 von m_tag zu ersetzen                        
   470103     14. Februar 2003   4.7-STABLE erha:lt OpenSSL 0.9.7             
   480000     30. Ma:rz 2003     4.8-RELEASE                                  
   480100     5. April 2003      4.8-STABLE                                   
   480101     22. Mai 2003       4.8-STABLE nachdem realpath(3) Thread-sicher 
                                 gemacht wurde.                               
   480102     10. August 2003    4.8-STABLE A:nderung der 3ware-API in twe.   
   490000     27. Oktober 2003   4.9-RELEASE                                  
   490100     27. Oktober 2003   4.9-STABLE                                   
   490101     8. Januar 2004     4.9-STABLE nachdem e_sid zu der Struktur     
                                 kinfo_eproc hinzugefu:gt wurde.              
   490102     4. Februar 2004    4.9-STABLE nach dem Einfliessen der          
                                 libmap-Funktionalita:t fu:r rtld.            
   491000     25. Mai 2004       4.10-RELEASE                                 
   491100     1. Juni 2004       4.10-STABLE                                  
                                 4.10-STABLE nach dem Einfliessen von         
   491101     11. August 2004    Revision 20040629 der Paket-Werkzeuge aus    
                                 CURRENT.                                     
                                 4.10-STABLE nach der Fehlerbehebung in der   
   491102     16. November 2004  VM, um das Freigeben von fiktiven            
                                 Speicherseiten korrekt zu handhaben.         
   492000     17. Dezember 2004  4.11-RELEASE                                 
   492100     17. Dezember 2004  4.11-STABLE                                  
                                 4.11-STABLE nach dem Hinzufu:gen von         
   492101     18. April 2006     libdata/ldconfig Verzeichnissen zu den       
                                 mtree-Dateien.                               
   500000     13. Ma:rz 2000     5.0-CURRENT                                  
                                 5.0-CURRENT nach Hinzufu:gen von             
   500001     18. April 2000     zusa:tzlichen Feldern in den ELF-Headern und 
                                 A:ndern der Methode zur ELF-Markierung von   
                                 Bina:rdateien.                               
   500002     2. Mai 2000        5.0-CURRENT nach kld-Metadaten A:nderungen.  
   500003     18. Mai 2000       5.0-CURRENT nach buf/bio A:nderungen.        
   500004     26. Mai 2000       5.0-CURRENT nach binutils Aktualisierung.    
                                 5.0-CURRENT nach dem Einfliessen des libxpg4 
   500005     3. Juni 2000       Quelltextes in die libc und der Einfu:hrung  
                                 der TASKQ-Schnittstelle.                     
   500006     10. Juni 2000      5.0-CURRENT nach dem Hinzufu:gen der         
                                 AGP-Schnittstellen.                          
   500007     29. Juni 2000      5.0-CURRENT nach der Aktualisierung von Perl 
                                 auf Version 5.6.0.                           
   500008     7. Juli 2000       5.0-CURRENT nach der Aktualisierung des      
                                 KAME-Quelltextes zu den 2000/07-Quellen.     
   500009     14. Juli 2000      5.0-CURRENT nach ether_ifattach() und        
                                 ether_ifdetach() A:nderungen.                
                                 5.0-CURRENT nachdem die mtree-Standards      
   500010     16. Juli 2000      zuru:ck zur urspru:nglichen Variante         
                                 gea:ndert wurden; -L hinzugefu:gt, um        
                                 Symlinks zu folgen.                          
   500011     18. Juli 2000      5.0-CURRENT nachdem die kqueue-API gea:ndert 
                                 worden ist.                                  
   500012     2. September 2000  5.0-CURRENT nachdem setproctitle(3) von      
                                 libutil nach libc verschoben worden ist.     
   500013     10. September 2000 5.0-CURRENT nach dem ersten SMPng-Commit.    
   500014     4. Januar 2001     5.0-CURRENT nachdem <sys/select.h> nach      
                                 <sys/selinfo.h> verschoben worden ist.       
                                 5.0-CURRENT nach dem Kombinieren von         
   500015     10. Januar 2001    libgcc.a und libgcc_r.a und damit verbundene 
                                 A:nderungen an GCC-Bindungen.                
                                 5.0-CURRENT nach der A:nderung das           
   500016     24. Januar 2001    Zusammenbinden von libc und libc_r zu        
                                 erlauben, womit die -pthread Option veraltet 
                                 ist.                                         
                                 5.0-CURRENT nach dem Umschalten von struct   
   500017     18. Februar 2001   ucred zu struct xucred, um die vom Kernel    
                                 exportierte API fu:r mount u.a.zu            
                                 stabilisieren.                               
                                 5.0-CURRENT nach dem Hinzufu:gen der CPUTYPE 
   500018     24. Februar 2001   make Variable zum Kontrollieren von          
                                 CPU-spezifischen Optimierungen.              
   500019     9. Juni 2001       5.0-CURRENT nach dem Verschieben von         
                                 machine/ioctl_fd.h nach sys/fdcio.h          
   500020     15. Juni 2001      5.0-CURRENT nach der Umbenennung der         
                                 locale-Namen.                                
                                 5.0-CURRENT nach dem Bzip2-Import.           
   500021     22. Juni 2001      Kennzeichnet auch, dass S/Key entfernt       
                                 wurde.                                       
   500022     12. Juli 2001      5.0-CURRENT nach SSE Unterstu:tzung.         
   500023     14. September 2001 5.0-CURRENT nach KSE-Meilenstein 2.          
   500024     1. Oktober 2001    5.0-CURRENT nach d_thread_t, und nachdem     
                                 UUCP in die Ports verschoben worden ist.     
                                 5.0-CURRENT nach A:nderungen in der ABI bei  
   500025     4. Oktober 2001    der Weitergabe von Deskriptoren und          
                                 Berechtigungen auf 64 Bit Plattformen.       
                                 5.0-CURRENT nachdem XFree86 4 als Standard   
   500026     9. Oktober 2001    zum Erstellen der Pakete benutzt wird und    
                                 die neue libc strnstr()-Funktion             
                                 hinzugefu:gt wurde.                          
   500027     10. Oktober 2001   5.0-CURRENT nachdem die neue libc            
                                 strcasestr()-Funktion hinzugefu:gt wurde.    
   500028     14. Dezember 2001  5.0-CURRENT nachdem die Userland-Komponenten 
                                 von smbfs importiert wurden.                 
   (nicht                        5.0-CURRENT nachdem die neuen C99-Ganzzahlen 
   gea:ndert)                    mit spezifischer Breite hinzugefu:gt wurden. 
   500029     29. Januar 2002    5.0-CURRENT nachdem eine A:nderung im        
                                 Ru:ckgabewert von sendfile(2) gemacht wurde. 
                                 5.0-CURRENT nach der Einfu:hrung des Types   
   500030     15. Februar 2002   fflags_t, welches die passende Gro:sse fu:r  
                                 Dateiflags hat.                              
   500031     24. Februar 2002   5.0-CURRENT nach der Umbenennung der USB     
                                 elements-Struktur.                           
   500032     16. Ma:rz 2002     5.0-CURRENT nach der Einfu:hrung von Perl    
                                 5.6.1.                                       
                                 5.0-CURRENT nachdem die sendmail_enable      
   500033     3. April 2002      rc.conf(5) Variable gea:ndert worden ist, um 
                                 den Wert NONE zu akzeptieren.                
   500034     30. April 2002     5.0-CURRENT nachdem mtx_init() einen dritten 
                                 Parameter entgegen nimmt.                    
   500035     13. Mai 2002       5.0-CURRENT mit GCC 3.1.                     
   500036     17. Mai 2002       5.0-CURRENT ohne Perl in /usr/src            
   500037     29. Mai 2002       5.0-CURRENT nach dem Hinzufu:gen von         
                                 dlfunc(3)                                    
                                 5.0-CURRENT nachdem die Typen von einigen    
   500038     24. Juli 2002      Elementen der sockbuf-Struktur gea:ndert     
                                 wurden und nachdem die Struktur neu geordnet 
                                 wurde.                                       
                                 5.0-CURRENT nach dem GCC 3.2.1 Import. Und   
                                 auch nachdem die Header nicht mehr           
                                 _BSD_FOO_T_ sondern _FOO_T_DECLARED          
   500039     1. September 2002  benutzen. Dieser Wert kann auch als          
                                 konservative Scha:tzung fu:r den Beginn der  
                                 Unterstu:tzung des bzip2(1) Pakets verwendet 
                                 werden.                                      
                                 5.0-CURRENT nachdem verschiedene A:nderungen 
   500040     20. September 2002 an Plattenfunktionen gemacht wurden, um die  
                                 Anha:ngigkeit von Interna der                
                                 disklabel-Struktur zu entfernen.             
   500041     1. Oktober 2002    5.0-CURRENT nach dem Hinzufu:gen von         
                                 getopt_long(3) zur libc.                     
                                 5.0-CURRENT nach der Aktualisierung von      
   500042     15. Oktober 2002   Binutils auf 2.13, bei denen die             
                                 FreeBSD-Emulation, vec und das Ausgabeformat 
                                 gea:ndert wurden.                            
                                 5.0-CURRENT nach dem Hinzufu:gen schwacher   
   500043     1. November 2002   pthread_XXX Stubs zur libc, womit            
                                 libXThrStub.so veraltet ist. 5.0-RELEASE.    
   500100     17. Januar 2003    5.0-CURRENT nach dem Erstellen des           
                                 RELENG_5_0-Zweiges                           
   500101     19. Februar 2003   <sys/dkstat.h> ist leer und sollte nicht     
                                 inkludiert werden.                           
   500102     25. Februar 2003   5.0-CURRENT nach der A:nderung in der        
                                 d_mmap_t-Schnittstelle.                      
                                 5.0-CURRENT nachdem taskqueue_swi gea:dert   
   500103     26. Februar 2003   wurde, um ohne Giant zu arbeiten, und        
                                 taskqueue_swi_giant hinzugefu:gt wurde, um   
                                 Giant zu verwenden.                          
                                 cdevsw_add() und cdevsw_remove() gibt es     
   500104     27. Februar 2003   nicht la:nger. Auftauchen der                
                                 MAJOR_AUTO-Allokationsmo:glichkeit.          
   500105     4. Ma:rz 2003      5.0-CURRENT nach der neuen                   
                                 cdevsw-Initialisierungsmethode.              
   500106     8. Ma:rz 2003      devstat_add_entry() wurde durch              
                                 devstat_new_entry() ersetzt.                 
   500107     15. Ma:rz 2003     Devstat Schnittstellena:nderung; siehe       
                                 sys/sys/param.h 1.149.                       
   500108     15. Ma:rz 2003     Token-Ring Schnittstellena:nderungen.        
   500109     25. Ma:rz 2003     Hinzufu:gen von vm_paddr_t.                  
   500110     28. Ma:rz 2003     5.0-CURRENT nachdem realpath(3)              
                                 Thread-sicher gemacht wurde.                 
   500111     9. April 2003      5.0-CURRENT nachdem usbhid(3) mit NetBSD     
                                 synchronisiert wurde.                        
                                 5.0-CURRENT nach der neuen NSS               
   500112     17. April 2003     Implementierung und Hinzufu:gen der POSIX.1  
                                 getpw*_r, getgr*_r Funktionen.               
   500113     2. Mai 2003        5.0-CURRENT nach Entfernen des alten         
                                 rc-Systems.                                  
   501000     4. Juni 2003       5.1-RELEASE.                                 
   501100     2. Juni 2003       5.1-CURRENT nach dem Erstellen des           
                                 RELENG_5_1 Zweiges.                          
                                 5.1-CURRENT nachdem die Semantik von         
   501101     29. Juni 2003      sigtimedwait(2) and sigwaitinfo(2)           
                                 korrigiert wurden.                           
                                 5.1-CURRENT nach dem Hinzufu:gen der         
   501102     3. Juli 2003       lockfunc und lockfuncarg-Felder zu           
                                 bus_dma_tag_create(9).                       
   501103     31. Juli 2003      5.1-CURRENT nach der Integration des GCC     
                                 3.3.1-pre 20030711 Snapshots.                
   501104     5. August 2003     5.1-CURRENT 3ware-API A:nderungen in twe.    
                                 5.1-CURRENT Unterstu:tzung von dynamisch     
   501105     17. August 2003    gebundenen /bin und /sbin und Verschieben    
                                 von Bibliotheken nach /lib.                  
   501106     8. September 2003  5.1-CURRENT nachdem im Kernel Unterstu:tzung 
                                 fu:r Coda 6.x hinzugefu:gt wurden.           
                                 5.1-CURRENT nachdem die 16550                
                                 UART-Konstanten von <dev/sio/sioreg.h> nach  
   501107     17. September 2003 <dev/ic/ns16550.h> verschoben wurden. Und    
                                 nachdem die libmap Funktionalita:t           
                                 vorbehaltlos vom rtld unterstu:tzt wurde.    
   501108     23. September 2003 5.1-CURRENT nach Aktualisierung der          
                                 PFIL_HOOKS API.                              
   501109     27. September 2003 5.1-CURRENT nachdem kiconv(3) hinzugefu:gt   
                                 wurde.                                       
                                 5.1-CURRENT nachdem der standardma:ssige     
   501110     28. September 2003 Ablauf von open und close in cdevsw          
                                 gea:ndert wurde.                             
   501111     16. Oktober 2003   5.1-CURRENT nachdem das Layout von cdevsw    
                                 gea:ndert wurde.                             
   501112     16. Oktober 2003   5.1-CURRENT nach dem Hinzufu:gen von         
                                 Mehrfachvererbung in kobj.                   
   501113     31. Oktober 2003   5.1-CURRENT nach der if_xname A:nderung in   
                                 der Struktur ifnet                           
   501114     16. November 2003  5.1-CURRENT nachdem /bin und /sbin gea:ndert 
                                 wurden, um sie dynamisch zu binden.          
   502000     7. Dezember 2003   5.2-RELEASE                                  
   502010     23. Februar 2004   5.2.1-RELEASE                                
   502100     7. Dezember 2003   5.2-CURRENT nach dem Erstellen des           
                                 RELENG_5_2-Zweiges.                          
                                 5.2-CURRENT nachdem die                      
   502101     19. Dezember 2003  __cxa_atexit/__cxa_finalize Funktionen zur   
                                 libc hinzugefu:gt wurden.                    
                                 5.2-CURRENT nachdem die Standard-Thread      
   502102     30. Januar 2004    Bibliothek von libc_r zu libpthread          
                                 gea:ndert wurde.                             
   502103     21. Februar 2004   5.2-CURRENT nach dem Gera:tetreiber API      
                                 Megapatch.                                   
   502104     25. Februar 2004   5.2-CURRENT nachdem getopt_long_only()       
                                 hinzugefu:gt wurde.                          
                                 5.2-CURRENT nachdem NULL fu:r C in ((void    
   502105     5. Ma:rz 2004      *)0) gea:ndert wurde, was mehr Warnungen     
                                 erzeugt.                                     
   502106     8. Ma:rz 2004      5.2-CURRENT nachdem pf beim Bauen und        
                                 Installieren mit eingebunden wird.           
                                 5.2-CURRENT nachdem time_t auf der           
   502107     10. Ma:rz 2004     sparc64-Plattform in einen 64-bit Wert       
                                 gea:ndert wurde.                             
                                 5.2-CURRENT nachdem sich die Unterstu:tzung  
   502108     12. Ma:rz 2004     fu:r den Intel C/C++-Compiler in einigen     
                                 Headern und execve(2) gea:ndert hat, um sich 
                                 strikter an POSIX zu halten.                 
   502109     22. Ma:rz 2004     5.2-CURRENT nach der Einfu:hrung der         
                                 bus_alloc_resource_any API                   
   502110     27. Ma:rz 2004     5.2-CURRENT nach dem Hinzufu:gen von UTF-8   
                                 locales                                      
   502111     11. April 2004     5.2-CURRENT nach dem Entfernen der           
                                 getvfsent(3) API                             
   502112     13. April 2004     5.2-CURRENT nach dem Hinzufu:gen der         
                                 .warning Directive fu:r make.                
                                 5.2-CURRENT nachdem ttyioctl() zwingend      
   502113     4. Juni 2004       erforderlich fu:r serielle Treiber gemacht   
                                 wurde.                                       
   502114     13. Juni 2004      5.2-CURRENT nach dem Import des              
                                 ALTQ-Frameworks.                             
                                 5.2-CURRENT nachdem sema_timedwait(9)        
   502115     14. Juni 2004      gea:ndert wurde, 0 bei Erfolg und einen von  
                                 0 verschiedenen Fehlercode im Falle eines    
                                 Fehlers zuru:ckzuliefern.                    
                                 5.2-CURRENT nach dem A:ndern der Kernel      
   502116     16. Juni 2004      Struktur dev_t, in ein Zeiger auf die        
                                 Struktur cdev *                              
   502117     17. Juni 2004      5.2-CURRENT nach dem A:ndern der             
                                 Kernelstruktur udev_t in dev_t.              
                                 5.2-CURRENT nachdem Unterstu:tzung fu:r      
   502118     17. Juni 2004      CLOCK_VIRTUAL und CLOCK_PROF zu              
                                 clock_gettime(2) und clock_getres(2)         
                                 hinzugefu:gt wurde.                          
                                 5.2-CURRENT nachdem die U:berpru:fung des    
   502119     22. Juni 2004      Klonens von Netzwerk-Schnittstellen          
                                 gea:ndert wurde.                             
   502120     2. Juli 2004       5.2-CURRENT nach dem Einfliessen von         
                                 Revision 20040629 der Paket-Werkzeuge.       
   502121     9. Juli 2004       5.2-CURRENT nachdem Bluetooth-Quelltext als  
                                 nicht i386-spezifisch markiert wurde.        
                                 5.2-CURRENT nach der Einfu:hrung des KDB     
   502122     11. Juli 2004      Debugger Frameworks, der Umwandlung des DDB  
                                 in ein Backend und der Einfu:hrung des       
                                 GDB-Backends.                                
                                 5.2-CURRENT nachdem VFS_ROOT gea:ndert       
                                 wurde, eine Struktur thread als Argument zu  
                                 aktzeptieren, wie vflush. Die Struktur       
   502123     12. Juli 2004      kinfo_proc entha:lt nun einen Zeiger auf     
                                 Benutzer Daten. Der Umstieg auf xorg als     
                                 standardma:ssige X Implementierung wurde     
                                 auch zu dieser Zeit durchgefu:hrt.           
                                 5.2-CURRENT nachdem die Art und Weise, wie   
   502124     24. Juli 2004      rc.d-Skripte von Ports und Altlasten         
                                 gestartet werden, getrennt wurde.            
   502125     28. Juli 2004      5.2-CURRENT nachdem die vorherige A:nderung  
                                 ru:ckga:ngig gemacht wurde.                  
                                 5.2-CURRENT nach dem Entfernen von           
   502126     31. Juli 2004      kmem_alloc_pageable() und dem Import von GCC 
                                 3.4.2.                                       
                                 5.2-CURRENT nachdem die UMA Kernel API       
   502127     2. August 2004     gea:ndert wurde, um Konstruktoren und        
                                 Initialisierungsmethoden zu erlauben         
                                 fehlzuschlagen.                              
                                 5.2-CURRENT nach der A:nderung in der        
   502128     8. August 2004     vfs_mount Signatur sowie allgemeines         
                                 Ersetzen von PRISON_ROOT durch               
                                 SUSER_ALLOWJAIL in der suser(9) API.         
   503000     23. August 2004    5.3-BETA/RC vor der A:nderung der pfil-API.  
   503001     22. September 2004 5.3-RELEASE                                  
   503100     16. Oktober 2004   5.3-STABLE nach dem Erstellen des            
                                 RELENG_5_3-Zweiges.                          
                                 5.3-STABLE nach dem Hinzufu:gen von          
   503101     3. Dezember 2004   Fu:lloptionen im Stile der libc zu           
                                 strftime(3).                                 
   503102     13. Februar 2005   5.3-STABLE nachdem OpenBSD's nc(1) von       
                                 CURRENT importiert wurde.                    
                                 5.4-PRERELEASE nach dem Einfliessen der      
                                 Reparaturen aus CURRENT, in                  
   503103     27. Februar 2005   <src/include/stdbool.h> und                  
                                 <src/sys/i386/include/_types.h>, um die      
                                 GCC-Kompatibilita:t des Intel                
                                 C/C++-Compilers zu benutzen.                 
                                 5.4-PRERELEASE nach dem Einfliessen der      
   503104     28. Februar 2005   A:nderung aus CURRENT in ifi_epoch statt der 
                                 lokalen Zeit die Betriebszeit des Systems zu 
                                 benutzen.                                    
                                 5.4-PRERELEASE nach dem Einfliessen der      
   503105     2. Ma:rz 2005      Reparaturen von EOVERFLOW in vswprintf(3)    
                                 aus CURRENT.                                 
   504000     3. April 2005      5.4-RELEASE.                                 
   504100     3. April 2005      5.4-STABLE nach dem Erstellen des            
                                 RELENG_5_4-Zweiges.                          
   504101     11. Mai 2005       5.4-STABLE nach dem Vergro:ssern der         
                                 standardma:ssigen Stackgro:sse fu:r Threads. 
   504102     24. Juni 2005      5.4-STABLE nach dem Hinzufu:gen von sha256.  
   504103     3. Oktober 2005    5.4-STABLE nach dem Einfliessen von          
                                 if_bridge aus CURRENT.                       
   504104     13. November 2005  5.4-STABLE nach dem Einfliessen von bsdiff   
                                 und portsnap aus CURRENT.                    
                                 5.4-STABLE nach dem Einfliessen der          
   504105     17. Januar 2006    A:nderung von ldconfig_local_dirs aus        
                                 CURRENT.                                     
   505000     12. Mai 2006       5.5-RELEASE.                                 
   505100     12. Mai 2006       5.5-STABLE nach dem Erstellen des            
                                 RELENG_5_5-Zweiges.                          
   600000     18. August 2004    6.0-CURRENT                                  
   600001     27. August 2004    6.0-CURRENT nach der festen Aktivierung von  
                                 PFIL_HOOKS im Kernel.                        
                                 6.0-CURRENT nach der anfa:nglichen           
                                 Einfu:hrung von ifi_epoch zur Struktur       
   600002     30. August 2004    if_data. Wurde nach ein paar Tagen wieder    
                                 ru:ckga:ngig gemacht. Benutzen Sie diesen    
                                 Wert bitte nicht.                            
   600003     8. September 2004  6.0-CURRENT nach dem erneuten Hinzufu:gen    
                                 des Elements ifi_epoch zur Struktur if_data. 
   600004     29. September 2004 6.0-CURRENT nach dem Hinzufu:gen der         
                                 Struktur inpcb als Argument in der pfil API. 
   600005     5. Oktober 2004    6.0-CURRENT nach dem Hinzufu:gen des "-d     
                                 DESTDIR" Schalters zu newsyslog.             
                                 6.0-CURRENT nach dem Hinzufu:gen von         
   600006     4. November 2004   Fu:lloptionen im Style der libc zu           
                                 strftime(3).                                 
   600007     12. Dezember 2004  6.0-CURRENT nach dem Hinzufu:gen von 802.11  
                                 Framework Neuerungen.                        
                                 6.0-CURRENT A:nderung an den VOP_*VOBJECT()  
   600008     25. Januar 2005    Funktionen und Einfu:hrung des MNTK_MPSAFE   
                                 Schalters fu:r Dateisysteme, welche ohne     
                                 Giant arbeiten.                              
   600009     4. Februar 2005    6.0-CURRENT nach dem Hinzufu:gen von cpufreq 
                                 Framework und Treibern.                      
   600010     6. Februar 2005    6.0-CURRENT nachdem OpenBSD's nc(1)          
                                 importiert wurde.                            
                                 6.0-CURRENT nachdem der Anschein von         
   600011     12. Februar 2005   matherr() Unterstu:tzung in SVID2 entfernt   
                                 wurde.                                       
   600012     15. Februar 2005   6.0-CURRENT nach dem Vergro:ssern der        
                                 standardma:ssigen Stackgro:sse fu:r Threads. 
                                 6.0-CURRENT nach dem Einfliessen der         
                                 Reparaturen in <src/include/stdbool.h> und   
   600013     19. Februar 2005   <src/sys/i386/include/_types.h>, um die      
                                 GCC-Kompatibilita:t des Intel                
                                 C/C++-Compilers zu benutzen.                 
   600014     21. Februar 2005   6.0-CURRENT nachdem die U:berpru:fungen auf  
                                 EOVERFLOW in vswprintf(3) korrigiert wurden. 
                                 6.0-CURRENT nach dem Einfliessen der         
   600015     25. Februar 2005   A:nderung, in ifi_epoch, statt der lokalen   
                                 Zeit, die Betriebzeit des Systems zu         
                                 benutzen.                                    
   600016     26. Februar 2005   6.0-CURRENT nachdem das Format von LC_CTYPE  
                                 auf der Festplatte vera:ndert wurde.         
                                 6.0-CURRENT nachdem das Format der           
   600017     27. Februar 2005   NLS-Kataloge auf der Festplatte vera:ndert   
                                 wurde.                                       
                                 6.0-CURRENT nachdem das Format von           
   600018     27. Februar 2005   LC_COLLATE auf der Festplatte vera:ndert     
                                 wurde.                                       
   600019     28. Februar 2005   Installation der acpica Include-Dateien in   
                                 /usr/include.                                
   600020     9. Ma:rz 2005      Hinzufu:gen des MSG_NOSIGNAL Schalters zur   
                                 send(2) API.                                 
   600021     17. Ma:rz 2005     Hinzufu:gen von Feldern zu cdevsw            
   600022     21. Ma:rz 2005     gtar wurde aus dem Basissystem entfernt.     
   600023     13. April 2005     Die Optionen LOCAL_CREDS, LOCAL_CONNWAIT     
                                 fu:r Sockets wurde zu unix(4) hinzugefu:gt.  
   600024     19. April 2005     hwpmc(4) und zugeho:rige Werkzeuge wurden zu 
                                 6.0-CURRENT hinzugefu:gt.                    
   600025     26. April 2005     Die Struktur icmphdr wurden zu 6.0-CURRENT   
                                 hinzugefu:gt.                                
   600026     3. Mai 2005        pf Aktualisierung auf 3.7.                   
   600027     6. Mai 2005        Kernel libalias und ng_nat wurden            
                                 eingefu:hrt.                                 
   600028     13. Mai 2005       POSIX ttyname_r(3) wurde u:ber unistd.h und  
                                 libc zur Verfu:gung gestellt.                
   600029     29. Mai 2005       6.0-CURRENT nachdem libpcap zu Version       
                                 v0.9.1 alpha 096 aktualisiert wurde.         
   600030     5. Juni 2005       6.0-CURRENT nach dem Import von NetBSDs      
                                 if_bridge(4).                                
   600031     10. Juni 2005      6.0-CURRENT nachdem die Struktur ifnet aus   
                                 dem Treiber softcs herausgelo:st wurde.      
   600032     11. Juli 2005      6.0-CURRENT nach dem Import von libpcap      
                                 v0.9.1.                                      
                                 6.0-STABLE nachdem die Versionen aller       
   600033     25. Juli 2005      gemeinsam genutzten Bibliotheken, welche     
                                 seit RELENG_5 nicht gea:ndert wurden,        
                                 erho:ht wurden.                              
                                 6.0-STABLE nachdem das Argument credential   
   600034     13. August 2005    zu der dev_clone-Ereignisbehandlung          
                                 hinzugefu:gt wurde. 6.0-RELEASE.             
   600100     1. November 2005   6.0-STABLE nach dem Erstellen des            
                                 6.0-RELEASE-Zweiges.                         
                                 6.0-STABLE nach dem Aufnehmen von Skripten   
   600101     21. Dezember 2005  aus den local_startup-Verzeichnissen in      
                                 rcorder(8) des Basissystems.                 
   600102     30. Dezember 2005  6.0-STABLE nach dem Aktualisieren der        
                                 ELF-Typen und Konstanten.                    
   600103     15. Januar 2006    6.0-STABLE nach dem Einfliessen der          
                                 pidfile(3)-API aus CURRENT.                  
                                 6.0-STABLE nach dem Einfliessen der          
   600104     17. Januar 2006    A:nderung von ldconfig_local_dirs aus        
                                 CURRENT.                                     
   600105     26. Februar 2006   6.0-STABLE nach der                          
                                 NLS-Katalogunterstu:tzung von csh(1).        
   601000     6. Mai 2006        6.1-RELEASE                                  
   601100     6. Mai 2006        6.1-STABLE nach 6.1-RELEASE.                 
   601101     22. Juni 2006      6.1-STABLE nach dem Import von csup.         
   601102     11. Juli 2006      6.1-STABLE nach der iwi(4)-Aktualisierung.   
                                 6.1-STABLE nach der Aktualisierung der       
   601103     17. Juli 2006      Namensauflo:sung zu BIND9 und Aufnahme der   
                                 ablaufinvarianten Versionen der              
                                 netdb-Funktionen.                            
                                 6.1-STABLE nachdem Unterstu:tzung fu:r DSO   
   601104     8. August 2006     (dynamic shared objects - gemeinsam          
                                 genutzte, dynamische Objekte) in OpenSSL     
                                 aktiviert wurde.                             
                                 6.1-STABLE nachdem 802.11 Reparaturen die    
   601105     2. September 2006  API der IEEE80211_IOC_STA_INFO ioctl         
                                 gea:ndert haben.                             
   602000     15. November 2006  6.2-RELEASE                                  
   602100     15. September 2006 6.2-STABLE nach 6.2-RELEASE.                 
   602101     12. Dezember 2006  6.2-STABLE nach dem Hinzufu:gen der Wi-Spy   
                                 Eigenart.                                    
   602102     28. Dezember 2006  6.2-STABLE nachdem pci_find_extcap()         
                                 hinzugefu:gt wurde.                          
                                 6.2-STABLE nach dem Einpflegen der dlsym     
                                 A:nderung aus CURRENT, ein angefordertes     
   602103     16. Januar 2007    Symbol sowohl in der spezifizierten dso, als 
                                 auch in den impliziten Abha:ngigkeiten       
                                 nachzuschlagen.                              
                                 6.2-STABLE nach dem Einpflegen von           
                                 ng_deflate(4) und ng_pred1(4) netgraph       
   602104     28. Januar 2007    Knoten und neuen Kompressions- und           
                                 -Verschlu:sselungmodi fu:r den ng_ppp(4)     
                                 Knoten aus CURRENT.                          
                                 6.2-STABLE nach dem Einpflegen der BSD       
   602105     20. Februar 2007   lizensierten Version von gzip(1), welche von 
                                 NetBSD portiert wurde aus CURRENT.           
   602106     31. Ma:rz 2007     6.2-STABLE nach dem Einpflegen der PCI MSI   
                                 und MSI-X Unterstu:tzung aus CURRENT.        
                                 6.2-STABLE nach dem Einpflegen von ncurses   
   602107     6. April 2007      5.6 und Unterstu:tzung fu:r                  
                                 Multibyte-Zeichen aus CURRENT.               
                                 6.2-STABLE nach dem Einpflegen des 'SG'      
   602108     11. April 2007     Peripheriegera:tes aus CURRENT in CAM,       
                                 welches einen Teil der SCSI SG passthrough   
                                 Gera:te API von Linux entha:lt.              
   602109     17. April 2007     6.2-STABLE nach dem Einpflegen von readline  
                                 5.2 Patchset 002 aus CURRENT.                
                                 6.2-STABLE nach dem Einpflegen von           
                                 pmap_invalidate_cache(), pmap_change_attr(), 
   602110     2. Mai 2007        pmap_mapbios(), pmap_mapdev_attr(), und      
                                 pmap_unmapbios() fu:r amd64 und i386 aus     
                                 CURRENT.                                     
                                 6.2-STABLE nach dem Einpflegen von           
   602111     11. Juni 2007      BOP_BDFLUSH aus CURRENT und dem daraus       
                                 resultierendem Bruch mit dem                 
                                 Dateisystemmodul KBI.                        
   602112     21. September 2007 6.2-STABLE nach dem Einpflegen von           
                                 libutil(3) aus CURRENT.                      
                                 6.2-STABLE, nach der Trennung in "wide und   
                                 single byte ctype". Neu kompilierte          
   602113     25. Oktober 2007   Bina:rdateien, die ctype.h referenzieren,    
                                 erfordern mo:glicherweise ein neues Symbol,  
                                 __mb_sb_limit, das auf a:lteren Systemen     
                                 nicht verfu:gbar ist.                        
                                 6.2-STABLE, nachdem die ctype                
   602114     30. Oktober 2007   ABI-Aufwa:rtskompatibilita:t                 
                                 wiederhergestellt wurde.                     
                                 FreeBSD 6.2-STABLE nach der                  
   602115     21. November 2007  Entfernung/Eliminierung der wide und single  
                                 Byte ctype-Trennung                          
   603000     25. November 2007  6.3-RELEASE                                  
   603100     25. November 2007  6.3-STABLE nach 6.3-RELEASE.                 
                                 6.3-STABLE, nachdem der Support fu:r den     
   603101     7. Dezember 2007   Multibyte-Datentyp im Bit-Makro gefixt       
                                 wurde.                                       
   603102     24. April 2008     6.3-STABLE nach Hinzufu:gen von l_sysid zu   
                                 struct flock.                                
   603103     27. Mai 2008       6.3-STABLE nach Einfliessen der              
                                 memrchr-Funktion.                            
                                 6.3-STABLE nach U:bernahme der               
   603104     15. Juni 2008      Unterstu:tzung von :u als Variablenwandler   
                                 in make(1).                                  
   604000     4. Oktober 2008    6.4-RELEASE                                  
   604100     4. Oktober 2008    6.4-STABLE nach 6.4-RELEASE.                 
   700000     11. Juli 2005      7.0-CURRENT.                                 
                                 7.0-CURRENT nachdem die Versionen aller      
   700001     23. Juli 2005      gemeinsam genutzten Bibliotheken, welche     
                                 seit RELENG_5 nicht gea:ndert wurden,        
                                 erho:ht wurden.                              
                                 7.0-CURRENT nachdem ein                      
   700002     13. August 2005    Berechtigungs-Argument zur                   
                                 dev_clone-Ereignisroutine hinzugefu:gt       
                                 wurde.                                       
   700003     25. August 2005    7.0-CURRENT nachdem memmem(3) zur libc       
                                 hinzugefu:gt wurde.                          
                                 7.0-CURRENT nachdem die Argumente der        
                                 Kernelfunktion solisten(9) modifiziert       
   700004     30. Oktober 2005   wurden, um einen Backlog-Parameter (Anzahl   
                                 der maximalen wartenden Verbindungen) zu     
                                 akzeptieren.                                 
                                 7.0-CURRENT nachdem IFP2ENADDR() gea:ndert   
   700005     11. November 2005  wurde, einen Zeiger auf IF_LLADDR()          
                                 zuru:ckzugeben.                              
                                 7.0-CURRENT nach dem Hinzufu:gen des         
   700006     11. November 2005  if_addr-Elements zur Struktur ifnet und dem  
                                 Entfernen von IFP2ENADDR().                  
                                 7.0-CURRENT nach dem Aufnehmen von Skripten  
   700007     2. Dezember 2005   aus den local_startup Verzeichnissen in      
                                 rcorder(8) des Basissystems.                 
   700008     5. Dezember 2005   7.0-CURRENT nach dem Entfernen der MNT_NODEV 
                                 mount-Option.                                
   700009     19. Dezember 2005  7.0-CURRENT nach ELF-64 Typen A:nderungen    
                                 und Symbol Versionierung.                    
                                 7.0-CURRENT nach Hinzufu:gen der hostb und   
                                 vgapci Treiber, Hinzufu:gen von              
   700010     20. Dezember 2005  pci_find_extcap() und A:nderung der AGP      
                                 Treiber die Apertur nicht la:nger            
                                 abzubilden.                                  
                                 7.0-CURRENT nachdem auf allen Plattformen    
   700011     31. Dezember 2005  ausser Alpha tv_sec in time_t umgewandelt    
                                 wurde.                                       
   700012     8. Januar 2006     7.0-CURRENT nach A:nderung von               
                                 ldconfig_local_dirs.                         
                                 7.0-CURRENT nach A:nderung in /etc/rc.d/abi  
   700013     12. Januar 2006    um /compat/linux/etc/ld.so.cache als Symlink 
                                 in ein schreibgeschu:tztes Dateisystem zu    
                                 unterstu:tzen.                               
   700014     26. Januar 2006    7.0-CURRENT nach pts Import.                 
   700015     26. Ma:rz 2006     7.0-CURRENT nach Einfu:hrung von Version 2   
                                 der hwpmc(4)'s ABI.                          
   700016     22. April 2006     7.0-CURRENT nach dem Hinzufu:gen von         
                                 fcloseall(3) zur libc.                       
   700017     13. Mai 2006       7.0-CURRENT nach dem Entfernen von ip6fw.    
   700018     15. Juli 2006      7.0-CURRENT nach dem Import von snd_emu10kx. 
   700019     29. Juli 2006      7.0-CURRENT nach dem Import von OpenSSL      
                                 0.9.8b.                                      
   700020     3. September 2006  7.0-CURRENT nach dem Hinzufu:gen der         
                                 bus_dma_get_tag-Funktion                     
   700021     4. September 2006  7.0-CURRENT nach dem Import von libpcap      
                                 0.9.4 und tcpdump 3.9.4.                     
                                 7.0-CURRENT nach der dlsym A:nderung, ein    
   700022     9. September 2006  angefordertes Symbol sowohl in der           
                                 spezifizierten dso, als auch in den          
                                 impliziten Abha:ngigkeiten nachzuschlagen.   
   700023     23. September 2006 7.0-CURRENT nach dem Hinzufu:gen neuer       
                                 Sound-IOCTLs fu:r die OSSv4-Mixer-API.       
   700024     28. September 2006 7.0-CURRENT nach dem Import von OpenSSL      
                                 0.9.8d.                                      
   700025     11. November 2006  7.0-CURRENT nach dem Hinzufu:gen der libelf. 
   700026     26. November 2006  7.0-CURRENT nach gro:sseren A:nderungen an   
                                 den Sound sysctls.                           
   700027     30. November 2006  7.0-CURRENT nach dem Hinzufu:gen der         
                                 Wi-Spy-Eigenart.                             
   700028     15. Dezember 2006  7.0-CURRENT nach dem Hinzufu:gen von         
                                 sctp-Aufrufen zur libc.                      
                                 7.0-CURRENT nach dem Ersetzen von GNU        
   700029     26. Januar 2007    gzip(1) durch eine von NetBSD portierte      
                                 Version, die unter BSD-Lizenz steht.         
                                 7.0-CURRENT nach dem Entfernen der IPIP      
   700030     7. Februar 2007    Tunnelkapselung (VIFF_TUNNEL) aus dem IPv4   
                                 Multicast-Forwarding-Quelltext.              
   700031     23. Februar 2007   7.0-CURRENT nach den Modifizierungen an      
                                 bus_setup_intr() (newbus).                   
   700032     2. Ma:rz 2007      7.0-CURRENT nach der Aufnahme der Firmware   
                                 fu:r ipw(4) und iwi(4).                      
   700033     9. Ma:rz 2007      7.0-CURRENT nach Unterstu:tzung fu:r         
                                 Multibyte-Zeichen.                           
                                 7.0-CURRENT nach A:nderungen, wie            
   700034     19. Ma:rz 2007     insmntque(), getnewvnode() und               
                                 vfs_hash_insert() arbeiten.                  
                                 7.0-CURRENT nach Hinzufu:gen eines           
   700035     26. Ma:rz 2007     Benachrichtigungsmechanismus fu:r CPU        
                                 Frequenza:nderungen.                         
   700036     6. April 2007      7.0-CURRENT nach dem Import des ZFS          
                                 Dateisystemes.                               
                                 7.0-CURRENT nach dem Einpflegen des 'SG'     
   700037     8. April 2007      Peripheriegera:tes in CAM, welches einen     
                                 Teil der SCSI SG passthrough Gera:te API von 
                                 Linux entha:lt.                              
                                 7.0-CURRENT nachdem getenv(3), putenv(3),    
   700038     30. April 2007     setenv(3) und unsetenv(3) gea:ndert wurden,  
                                 um POSIX konform zu sein.                    
   700039     1. Mai 2007        7.0-CURRENT nachdem die A:nderungen von      
                                 700038 ru:ckga:ngig gemacht wurden.          
   700040     10. Mai 2007       7.0-CURRENT nach dem Hinzufu:gen von         
                                 flopen(3) zur libutil.                       
                                 7.0-CURRENT nachdem Symbol Versionierung     
   700041     13. Mai 2007       aktiviert und die standardma:ssige           
                                 Thread-Bibliothek zu libthr gea:ndert wurde. 
   700042     19. Mai 2007       7.0-CURRENT nach dem Import von GCC 4.2.0.   
                                 7.0-CURRENT nachdem die Versionen aller      
   700043     21. Mai 2007       Shared-Libraries, welche seit RELENG_6 nicht 
                                 gea:ndert wurden, erho:ht worden sind.       
                                 7.0-CURRENT nachdem das Argument fu:r        
   700044     7. Juni 2007       vn_open()/VOP_OPEN() vom                     
                                 Dateideskriptorindex zur Struktur file *     
                                 gea:dert wurde.                              
                                 7.0-CURRENT nachdem pam_nologin(8) gea:dert  
   700045     10. Juni 2007      wurde, eine Kontoverwaltungs-Funktion statt  
                                 einer Authentifizierungsfunktion fu:r das    
                                 PAM-Framework zur Verfu:gung zu stellen.     
   700046     11. Juni 2007      7.0-CURRENT nach aktualisierter 802.11       
                                 wireless Unterstu:tzung.                     
                                 7.0-CURRENT, nachdem                         
   700047     11. Juni 2007      TCP-LRO-Schnittstellen-Ressourcen            
                                 hinzugefu:gt wurden.                         
                                 7.0-CURRENT, nachdem die RFC 3678            
                                 API-Unterstu:tzung zum IPv4-Stack            
                                 hinzugefu:gt wurde. Veraltetes               
   700048     12. Juni 2007      RFC 1724-Verhalten des IP_MULTICAST_IF ioctl 
                                 wurde entfernt; 0.0.0.0/8 darf nicht la:nger 
                                 als Schnittstellen-Index benutzt werden.     
                                 Stattdessen sollte die Struktur ipmreqn      
                                 verwendet werden.                            
   700049     3. Juli 2007       7.0-CURRENT, nachdem pf von OpenBSD 4.1      
                                 importiert wurde                             
   (nicht                        7.0-CURRENT, nachdem die IPv6-Unterstu:tzung 
   gea:ndert)                    um FAST_IPSEC erweitert, KAME IPSEC entfernt 
                                 und FAST_IPSEC in IPSEC umbenannt wurde.     
                                 7.0-CURRENT, nachdem Aufrufe von             
   700050     4. Juli 2007       setenv/putenv/usw. von der traditionellen    
                                 BSD-Art und Weise nach POSIX konvertiert     
                                 wurden.                                      
   700051     4. Juli 2007       7.0-CURRENT, nachdem neue Systemaufrufe      
                                 (mmap/lseek/usw.) implementiert wurden.      
   700052     6. Juli 2007       7.0-CURRENT, nachdem die I4B-Header nach     
                                 include/i4b verschoben wurden.               
   700053     30. September 2007 7.0-CURRENT, nachdem die Unterstu:tzung fu:r 
                                 PCI Doma:nen hinzugefu:gt wurde.             
   700054     25. Oktober 2007   7.0-CURRENT, nach der Trennung in "wide und  
                                 single byte ctype".                          
                                 7.0-RELEASE sowie 7.0-CURRENT, nachdem die   
                                 ABI-Abwa:rtskompatibilita:t fu:r die FreeBSD 
                                 4/5/6-Versionen der PCIOCGETCONF-,           
   700055     28. Oktober 2007   PCIOCREAD- sowie PCIOCWRITE IOCTLs           
                                 hinzugefu:gt wurde. Damit verbunden war,     
                                 dass die ABI der PCIOCGETCONF IOCTL erneut   
                                 deaktiviert werden musste.                   
   700100     22. Dezember 2007  7.0-STABLE nach 7.0-RELEASE.                 
   700101     8. Februar 2008    7.0-STABLE nach Einfu:hrung von              
                                 m_collapse().                                
   700102     30. Ma:rz 2008     7.0-STABLE nach Einfliessen von              
                                 kdb_enter_why().                             
   700103     10. April 2008     7.0-STABLE nach Hinzufu:gen von l_sysid zu   
                                 struct flock.                                
   700104     11. April 2008     7.0-STABLE nach U:bernahme von procstat(1).  
   700105     11. April 2008     7.0-STABLE nach Einfu:hrung von              
                                 umtx-Features.                               
   700106     15. April 2008     7.0-STABLE nach Hinzufu:gen der              
                                 Unterstu:tzung von write(2) zu psm(4).       
   700107     20. April 2008     7.0-STABLE nach Hinzufu:gen des Befehls      
                                 F_DUP2FD zu fcntl(2).                        
                                 7.0-STABLE nach einigen A:nderungen an       
   700108     5. Mai 2008        lockmgr(9), welche die Einbindung von        
                                 sys/lock.h zur Verwendung von lockmgr(9)     
                                 voraussetzen.                                
   700109     27. Mai 2008       7.0-STABLE nach Einfliessen der              
                                 memrchr-Funktion.                            
   700110     5. August 2008     7.0-STABLE nach Einfu:hrung eines Clients    
                                 fu:r den Kernel NFS lockd.                   
                                 7.0-STABLE nach Hinzufu:gen einer            
   700111     20. August 2008    Unterstu:tzung von physisch fortlaufender    
                                 Jumbo Frames.                                
   700112     27. August 2008    7.0-STABLE nach Einfliessen einer            
                                 Kernelunterstu:tzung fu:r DTrace.            
   701000     25. November 2008  7.1-RELEASE                                  
   701100     25. November 2008  7.1-STABLE nach 7.1-RELEASE.                 
   701101     10. Januar 2009    7.1-STABLE nach U:bernahme von strndup.      
   701102     17. Januar 2009    7.1-STABLE nach Hinzufu:gen einer            
                                 Unterstu:tzung von cpuctl(4).                
                                 7.1-STABLE nach Einfliessen der              
   701103     7. Februar 2009    Unterstu:tzung von Jails mit keinen oder     
                                 mehreren IPv4-/IPv6-Adressen.                
                                 7.1-STABLE, nachdem der Besitzer des Suspend 
   701104     14. Februar 2009   in struct mount gespeichert wird und die     
                                 Funktion vfs_susp_clean in struct vfsops     
                                 aufgenommen ist.                             
                                 7.1-STABLE nach der inkompatiblen A:nderung  
                                 am sysctl kern.ipc.shmsegs, um die           
   701105     12. Ma:rz 2009     Anforderung gro:sserer Segmente von          
                                 gemeinsam genutzten SysV-Speicher auf        
                                 64bit-Architekturen zu erlauben.             
                                 7.1-STABLE nach der U:bernahme einer         
   701106     14. Ma:rz 2009     Fehlerbehebung fu:r Warteoperationen, die    
                                 POSIX-Semaphore verwenden.                   
   702000     15. April 2009     7.2-RELEASE                                  
   702100     15. April 2009     7.2-STABLE nach 7.2-RELEASE.                 
                                 7.2-STABLE, nachdem ichsmb(4) dahingehend    
                                 gea:ndert wurde, dass es links-ausgerichtete 
   702101     15. Mai 2009       Adressierung von Slaves verwendet, um        
                                 anderen SMBus-Kontrollertreibern zu          
                                 entsprechen.                                 
   702102     28. Mai 2009       7.2-STABLE nach dem Einfliessen der Funktion 
                                 fdopendir.                                   
   702103     06. Juni 2009      7.2-STABLE nach dem Einfliessen von          
                                 PmcTools.                                    
   702104     14. Juli 2009      7.2-STABLE nach dem Einfliessen des          
                                 Systemaufrufs closefrom.                     
   702105     31. Juli 2009      7.2-STABLE nach dem Einfliessen der          
                                 A:nderung an der SYSVIPC-ABI.                
                                 7.2-STABLE nach dem Einfliessen der          
                                 PAT-Verbesserungen fu:r x86-Prozessoren      
   702106     14. September 2009 sowie dem Hinzufu:gen von d_mmap_single()    
                                 und des VM-Objekttyps fu:r                   
                                 scatter/gather-Listen.                       
   703000     9. Februar 2010    7.3-RELEASE                                  
   703100     9. Februar 2010    7.3-STABLE nach 7.3-RELEASE.                 
   704000     22. Dezember 2010  7.4-RELEASE                                  
   704100     22. Dezember 2010  7.4-STABLE, nachdem 7.4-RELEASE erzeugt      
                                 wurde.                                       
   800000     11. Oktober 2007   8.0-CURRENT. Nach der Trennung in "wide und  
                                 single byte ctype".                          
   800001     16. Oktober 2007   8.0-CURRENT, nachdem libpcap 0.9.8 und       
                                 tcpdump 3.9.8 importiert wurden.             
                                 8.0-CURRENT, nachdem kthread_create() und    
   800002     21. Oktober 2007   Konsorten in kproc_create() usw. umbenannt   
                                 wurden.                                      
                                 8.0-CURRENT, nachdem die                     
                                 ABI-Abwa:rtskompatibilita:t fu:r die FreeBSD 
                                 4/5/6-Versionen der PCIOCGETCONF-,           
   800003     24. Oktober 2007   PCIOCREAD- sowie PCIOCWRITE IOCTLs           
                                 hinzugefu:gt wurde. Damit verbunden war,     
                                 dass die ABI der PCIOCGETCONF IOCTL erneut   
                                 deaktiviert werden musste.                   
                                 8.0-CURRENT, nachdem der agp(4) Treiber      
   800004     12. November 2007  verschoben wurde von src/sys/pci nach        
                                 src/sys/dev/agp.                             
   800005     4. Dezember 2007   8.0-CURRENT nach A:nderungen am              
                                 Jumbo Frame Allocator.                       
                                 8.0-CURRENT, nach dem Hinzufu:gen der        
   800006     7. Dezember 2007   callgraph capture Funktionalita:t zu         
                                 hwpmc(4).                                    
   800007     25. Dezember 2007  8.0-CURRENT nach dem Hinzufu:gen von "why"   
                                 als Argument in kdb_enter().                 
   800008     28. Dezember 2007  8.0-CURRENT nach Entfernen der Option        
                                 LK_EXCLUPGRADE.                              
   800009     9. Januar 2008     8.0-CURRENT nach Einfu:hrung von             
                                 lockmgr_disown(9)                            
   800010     10. Januar 2008    8.0-CURRENT nach A:nderungen am              
                                 vn_lock(9)-Prototyp.                         
                                 8.0-CURRENT nach A:nderungen an den          
   800011     13. Januar 2008    Prototypen von VOP_LOCK(9) und               
                                 VOP_UNLOCK(9).                               
                                 8.0-CURRENT nach Einfu:hrung von             
   800012     19. Januar 2008    lockmgr_recursed(9), BUF_RECURSED(9) und     
                                 BUF_ISLOCKED(9) sowie Entfernung von         
                                 BUF_REFCNT().                                
   800013     23. Januar 2008    8.0-CURRENT nach Einfu:hrung der             
                                 "ASCII"-Kodierung.                           
                                 8.0-CURRENT nach A:nderungen am              
   800014     24. Januar 2008    lockmgr(9)-Prototyp und Entfernung von       
                                 lockcount() sowie LOCKMGR_ASSERT().          
   800015     26. Januar 2008    8.0-CURRENT nach Erweiterung der Datentypen  
                                 der fts(3)-Strukturen.                       
   800016     1. Februar 2008    8.0-CURRENT nach Hinzufu:gen eines neuen     
                                 Parameters zu MEXTADD(9).                    
                                 8.0-CURRENT nach Einfu:hrung der Optionen    
   800017     6. Februar 2008    LK_NODUP und LK_NOWITNESS in die             
                                 lockmgr(9)-Umgebung.                         
   800018     8. Februar 2008    8.0-CURRENT nach Hinzufu:gen von m_collapse. 
                                 8.0-CURRENT nach Hinzufu:gen einer Arbeits-, 
   800019     9. Februar 2008    Wurzel- und Jailverzeichnisunterstu:tzung    
                                 zur sysctl-Variable kern.proc.filedesc.      
   800020     13. Februar 2008   8.0-CURRENT nach Einfu:hrung der Funktionen  
                                 lockmgr_assert(9) und BUF_ASSERT.            
                                 8.0-CURRENT nach Einfu:hrung von             
   800021     15. Februar 2008   lockmgr_args(9) und Entfernung der Option    
                                 LK_INTERNAL.                                 
   800022     (zuru:ckgezogen)   8.0-CURRENT nach Setzen von BSD ar(1) als    
                                 Systemstandard.                              
                                 8.0-CURRENT nach Prototypena:nderungen an    
   800023     25. Februar 2008   lockstatus(9) und VOP_ISLOCKED(9), eigens    
                                 zur Abschaffung des Parameters               
                                 struct thread.                               
                                 8.0-CURRENT nach Beseitigung der Funktionen  
                                 lockwaiters und BUF_LOCKWAITERS, A:nderung   
   800024     1. Ma:rz 2008      des Ru:ckgabewerts der Funktion brelvp von   
                                 void nach int sowie Einfu:hrung neuer        
                                 Optionen fu:r lockinit(9).                   
   800025     8. Ma:rz 2008      8.0-CURRENT nach Hinzufu:gen des Kommandos   
                                 F_DUP2FD zu fcntl(2).                        
                                 8.0-CURRENT nach A:nderung des Parameters    
   800026     12. Ma:rz 2008     fu:r die Priorita:t an cv_broadcastpri,      
                                 sodass 0 fu:r keine Priorita:t steht.        
                                 8.0-CURRENT nach A:nderung der               
   800027     24. Ma:rz 2008     Monitoring ABI von BPF, als Zero-Copy Puffer 
                                 hinzugefu:gt wurden.                         
   800028     26. Ma:rz 2008     8.0-CURRENT nach Hinzufu:gen von l_sysid zu  
                                 struct flock.                                
                                 8.0-CURRENT nach Wiedereingliederung der     
   800029     28. Ma:rz 2008     Funktion BUF_LOCKWAITERS und Hinzufu:gen von 
                                 lockmgr_waiters(9).                          
   800030     1. April 2008      8.0-CURRENT nach Einfu:hrung der Funktionen  
                                 rw_try_rlock(9) und rw_try_wlock(9).         
   800031     6. April 2008      8.0-CURRENT nach Einfu:hrung der Funktionen  
                                 lockmgr_rw und lockmgr_args_rw.              
                                 8.0-CURRENT nach Implementierung des         
                                 Systemaufrufs openat und seiner Verwandten,  
   800032     8. April 2008      Einfu:hrung der Option O_EXEC in open(2) und 
                                 Bereitstellung der entsprechenden            
                                 Systemaufrufe innerhalb der                  
                                 Linux(R)-Kompatibilita:tsumgebung.           
                                 8.0-CURRENT nach Hinzufu:gen der             
                                 Unterstu:tzung von write(2) in der nativen   
   800033     8. April 2008      Operationsebene von psm(4). Es ko:nnen nun   
                                 beliebig Kommandos nach /dev/psm%d           
                                 geschrieben und der Status dann von dort     
                                 gelesen werden.                              
   800034     10. April 2008     8.0-CURRENT nach Einfu:hrung der Funktion    
                                 memrchr.                                     
   800035     16. April 2008     8.0-CURRENT nach Einfu:hrung der Funktion    
                                 fdopendir.                                   
                                 8.0-CURRENT nach Umstellung des Standards    
   800036     20. April 2008     802.11 auf Unterstu:tzung von Multi-BSS      
                                 (auch vaps).                                 
                                 8.0-CURRENT nach Hinzufu:gen einer           
   800037     9. Mai 2008        Unterstu:tzung fu:r Multi Routing-Tabellen   
                                 (siehe setfib(1), setfib(2)).                
                                 8.0-CURRENT nach Entfernen von netatm und    
   800038     26. Mai 2008       ISDN4BSD sowie dem Hinzufu:gen der Compact C 
                                 Type (CTF)-Tools.                            
   800039     14. Juni 2008      8.0-CURRENT nach Entfernen von sgtty.        
   800040     26. Juni 2008      8.0-CURRENT nach Einfu:hrung eines Clients   
                                 fu:r den Kernel NFS lockd.                   
   800041     22. Juli 2008      8.0-CURRENT nach Hinzufu:gen von             
                                 arc4random_buf(3) und arc4random_uniform(3). 
   800042     8. August 2008     8.0-CURRENT nach Hinzufu:gen von cpuctl(4).  
                                 8.0-CURRENT nach A:nderung von bpf(4) zur    
   800043     13. August 2008    Verwendung einer einzelnen Gera:tedatei      
                                 anstatt von Klonierung.                      
                                 8.0-CURRENT nach U:bernahme des ersten Teils 
                                 aus dem vimage-Projekt durch Erweitern       
   800044     17. August 2008    globaler Variablen um den Pra:fix V_.        
                                 Zuku:nftig werden die virtualisierten        
                                 Variablen dann mit Hilfe von Makros in ihre  
                                 globalen Namen aufgelo:st.                   
                                 8.0-CURRENT nach Eingliederung des           
   800045     20. August 2008    MPSAFE TTY-Layers, einschliesslich           
                                 A:nderungen an diversen Treibern und         
                                 Werkzeugen, die mit ihm kommunizieren.       
   800046     8. September 2008  8.0-CURRENT nach Abschottung der GDT pro CPU 
                                 auf der AMD64-Architektur.                   
   800047     10. September 2008 8.0-CURRENT nach Entfernen von VSVTX, VSGID  
                                 und VSUID.                                   
                                 8.0-CURRENT nach Anpassung des Codes fu:r    
                                 Kernel NFS mount, sodass einzelne            
   800048     16. September 2008 Mountoptionen im Parameter struct iovec an   
                                 nmount() akzeptiert werden und nicht nur ein 
                                 grosses struct nfs_args.                     
   800049     17. September 2008 8.0-CURRENT nach Entfernen von suser(9) und  
                                 suser_cred(9).                               
   800050     20. Oktober 2008   8.0-CURRENT nach API-A:nderungen im Umgang   
                                 mit dem Buffer Cache.                        
   800051     23. Oktober 2008   8.0-CURRENT nach Entfernen der Makros        
                                 MALLOC(9) und FREE(9).                       
                                 8.0-CURRENT nach Einfu:hrung von accmode_t   
   800052     28. Oktober 2008   und Umbennung des Parameters a_mode an       
                                 VOP_ACCESS nach a_accmode.                   
                                 8.0-CURRENT nach A:nderung des Prototyps von 
   800053     2. November 2008   vfs_busy(9) und Einfu:hrung der Optionen     
                                 MBF_NOWAIT sowie MBF_MNTLSTLOCK.             
                                 8.0-CURRENT nach Hinzufu:gen von Funktionen  
                                 im Bereich buf_ring, Memory Barriers und     
                                 ifnet, um mehrere Sendeschlangen auf         
   800054     22. November 2008  Hardwareebene fu:r Karten zu ermo:glichen,   
                                 die dies unterstu:tzen, sowie einer          
                                 Ring Buffer-Implementierung ohne Lock, um    
                                 Treibern zu ermo:glichen, Paketschlangen     
                                 effizienter zu verwalten.                    
                                 8.0-CURRENT nach Hinzufu:gen einer           
   800055     27. November 2008  Unterstu:tzung fu:r Intel(R) Core, Core2 und 
                                 Atom zu hwpmc(4).                            
                                 8.0-CURRENT nach Einfu:hrung von Jails mit   
   800056     29. November 2008  mehreren oder gar keinen                     
                                 IPv4-/IPv6-Adressen.                         
   800057     1. Dezember 2008   8.0-CURRENT nach Wechsel zum                 
                                 ath_hal Quellcode.                           
   800058     12. Dezember 2008  8.0-CURRENT nach Einfu:hrung der Funktion    
                                 VOP_VPTOCNP.                                 
   800059     15. Dezember 2008  8.0-CURRENT gliedert das neue ARPv2 ein.     
   800060     19. Dezember 2008  8.0-CURRENT nach Hinzufu:gen von makefs.     
   800061     15. Januar 2009    8.0-CURRENT nach Umsetzung von               
                                 TCP Appropriate Byte Counting.               
   800062     28. Januar 2009    8.0-CURRENT nach Entfernen von minor(),      
                                 minor2unit(), unit2minor() usw.              
                                 8.0-CURRENT nach A:nderung der               
   800063     18. Februar 2009   GENERIC-Konfiguration zur Verwendung des     
                                 USB2-Stack und Hinzufu:gen von fdevname(3).  
   800064     23. Februar 2009   8.0-CURRENT, nachdem der USB2-Stack nach     
                                 dev/usb verschoben wurde, um es zu ersetzen. 
   800065     26. Februar 2009   8.0-CURRENT nach Umbenennen aller Funktionen 
                                 in libmp(3).                                 
   800066     27. Februar 2009   8.0-CURRENT nach Anpassung des               
                                 devfs-Verhaltens im Zusammenhang mit USB.    
                                 8.0-CURRENT nach Hinzufu:gen von getdelim(), 
   800067     28. Februar 2009   getline(), stpncpy(), strnlen(), wcsnlen(),  
                                 wcscasecmp() und wcsncasecmp().              
   800068     2. Ma:rz 2009      8.0-CURRENT nach Umbenennen der              
                                 Gera:teklasse ushub in uhub.                 
   800069     9. Ma:rz 2009      8.0-CURRENT nach Umbenennen von              
                                 libusb20.so.1 in libusb.so.1.                
                                 8.0-CURRENT nach der Einfu:hrung von IGMPv3  
   800070     9. Ma:rz 2009      und Source-Specific-Multicast (SSM) in den   
                                 IPv4-Stack.                                  
                                 8.0-CURRENT nach der Anpassung von gcc zur   
   800071     14. Ma:rz 2009     Verwendung der C99-Inline-Semantik in den    
                                 Modi c99 und gnu99.                          
                                 8.0-CURRENT, nachdem die Option              
   800072     15. Ma:rz 2009     IFF_NEEDSGIANT entfernt wurde;               
                                 Netzwerktreiber, die nicht MPSAFE sind,      
                                 werden nicht mehr unterstu:tzt.              
                                 8.0-CURRENT, nachdem die dynamische          
   800073     18. Ma:rz 2009     Ersetzung von Zeichenkettenku:rzeln fu:r     
                                 rpath und beno:tigte Pfade implementiert     
                                 wurde.                                       
   800074     24. Ma:rz 2009     8.0-CURRENT nach dem Einfliessen von         
                                 tcpdump 4.0.0 und libpcap 1.0.0.             
                                 8.0-CURRENT, nachdem die Deklarationen von   
   800075     6. April 2009      struct vnet_net, struct vnet_inet und        
                                 struct vnet_ipfw gea:ndert wurden.           
   800076     9. April 2009      8.0-CURRENT nach dem Hinzufu:gen von         
                                 Laufzeitprofilen in dummynet.                
   800077     14. April 2009     8.0-CURRENT nach dem Entfernen von           
                                 VOP_LEASE() und vop_vector.vop_lease.        
                                 8.0-CURRENT, nachdem die Felder aus          
                                 struct rt_weight zu struct rt_metrics und    
                                 struct rt_metrics_lite hinzugefu:gt wurden,  
   800078     15. April 2009     wobei die Deklaration von                    
                                 struct rt_metrics_lite gea:ndert wurde.      
                                 RTM_VERSION wurde hochgeza:hlt               
                                 (zuru:ckgezogen).                            
                                 8.0-CURRENT, nachdem Pointer auf             
   800079     15. April 2009     struct llentry zu struct route und           
                                 struct route_in6 hinzugefu:gt wurden.        
   800080     15. April 2009     8.0-CURRENT nach A:nderung der Deklaration   
                                 von struct inpcb.                            
   800081     19. April 2009     8.0-CURRENT nach A:nderung der Deklaration   
                                 von struct malloc_type.                      
                                 8.0-CURRENT nach A:nderung der Deklaration   
   800082     21. April 2009     von struct ifnet und Hinzufu:gen von         
                                 if_ref() und if_rele() zur Verwaltung von    
                                 Referenzen auf ifnet.                        
   800083     22. April 2009     8.0-CURRENT nach der Implementierung einer   
                                 systemnahen Bluetooth-HCI-API.               
   800084     29. April 2009     8.0-CURRENT nach A:nderungen an IPv6-SSM und 
                                 MLDv2.                                       
                                 8.0-CURRENT, nachdem der Bau von             
   800085     30. April 2009     VIMAGE-Kernel mit einem aktiven Image        
                                 unterstu:tzt wird.                           
                                 8.0-CURRENT nach Hinzufu:gen der             
   800086     8. Mai 2009        Unterstu:tzung fu:r Eingabezeilen mit        
                                 beliebiger La:nge durch patch(1).            
                                 8.0-CURRENT nach einigen A:nderungen im      
                                 Zusammenhang mit dem VFS-KPI. Der            
                                 Thread-Parameter wurde von den FSD-Teilen    
   800087     11. Mai 2009       des VFS entfernt. VFS_*-Funktionen           
                                 beno:tigen den Kontext nicht mehr, da er     
                                 sich immer auf curthread bezieht. In wenigen 
                                 Sonderfa:llen ist das bisherige Verhalten    
                                 nicht gea:ndert worden.                      
   800088     20. Mai 2009       8.0-CURRENT nach A:nderungen am              
                                 net80211-Monitormodus.                       
   800089     23. Mai 2009       8.0-CURRENT nach dem Hinzufu:gen der         
                                 Unterstu:tzung von UDP-Kontrollblocks.       
   800090     23. Mai 2009       8.0-CURRENT nach der Virtualisierung der     
                                 Schnittstellenklonierung.                    
                                 8.0-CURRENT nach dem Hinzufu:gen von         
   800091     27. Mai 2009       hierarchischen Jails und dem Entfernen des   
                                 globalen securelevel.                        
                                 8.0-CURRENT nach der A:nderung des           
                                 sx_init_flags()-KPI. SX_ADAPTIVESPIN wurde   
   800092     29. Mai 2009       zuru:ckgezogen und eine neue Option          
                                 SX_NOADAPTIVE wurde eingefu:hrt, um die      
                                 umgekehrte Logik zu behandeln.               
   800093     29. Mai 2009       8.0-CURRENT nach dem Hinzufu:gen von         
                                 mnt_xflag zu struct mount.                   
   800094     30. Mai 2009       8.0-CURRENT nach dem Hinzufu:gen von         
                                 VOP_ACCESSX(9).                              
                                 8.0-CURRENT nach der A:nderung des           
                                 Polling-KPI. Die Polling-Handler liefern nun 
                                 die Zahl der verarbeiteten Pakete zuru:ck.   
   800095     30. Mai 2009       Die neue Option IFCAP_POLLING_NOCOUNT wurde  
                                 weiter eingefu:hrt, um anzugeben, dass der   
                                 Ru:ckgabewert nicht von Bedeutung ist und    
                                 das Za:hlen der Pakete ausgelassen werden    
                                 soll.                                        
                                 8.0-CURRENT nach der Aktualisierung der      
   800096     1. Juni 2009       netisr-Implementierung und nachdem die       
                                 Weise, wie FIBs gespeichert werden und wie   
                                 auf sie zugegriffen wird, gea:ndert wurde.   
                                 8.0-CURRENT nach Einfu:hrung der             
   800097     8. Juni 2009       Destruktor-Infrastruktur fu:r vnet           
                                 einschliesslich Hooks.                       
                                 8.0-CURRENT nach Einfu:hrung eines           
                                 Erkennungssystems fu:r ausgehende Pakete,    
   800097     11. Juni 2009      die direkt wieder in netgraph gelangen und   
                                 deswegen eingereiht werden. Dabei wurde auch 
                                 die Definition von struct thread gea:ndert.  
   800098     14. Juni 2009      8.0-CURRENT nach dem Einfliessen von OpenSSL 
                                 0.9.8k.                                      
                                 8.0-CURRENT nach der Aktualisierung von      
   800099     22. Juni 2009      NGROUPS und dem Verschieben der              
                                 Routing-Virtualisierung in ein eigenes       
                                 VImage-Modul.                                
   800100     24. Juni 2009      8.0-CURRENT nach A:nderung der SYSVIPC-ABI.  
                                 8.0-CURRENT nach dem Entfernen der           
   800101     29. Juni 2009      zeichenorientierten Gera:te aus /dev/net,    
                                 von denen fu:r jede Schnittstelle eines      
                                 existiert.                                   
                                 8.0-CURRENT, nachdem struct sackhint, struct 
   800102     12. Juli 2009      tcpcb und struct tcpstat mit Padding-Bytes   
                                 aufgefu:llt wurden.                          
                                 8.0-CURRENT, nachdem struct tcpopt durch     
   800103     13. Juli 2009      struct toeopt in der Schnittstelle zwischen  
                                 dem TOE-Treiber und dem TCP-SYN-Cache        
                                 ersetzt wurde.                               
                                 8.0-CURRENT nach dem Hinzufu:gen einer       
   800104     19. Juli 2009      vnet-spezifischen Speicherzuweisung, die auf 
                                 dem Linker-Set-Verfahren basiert.            
                                 8.0-CURRENT nach der Inkrementierung der     
   800105     19. Juli 2009      Versionsnummer aller Shared-Libraries, die   
                                 Symbol-Versioning nicht aktiviert haben.     
   800106     24. Juli 2009      8.0-CURRENT nach Einfu:hrung des             
                                 VM-Objekttyps OBJT_SG.                       
                                 8.0-CURRENT nach Befreiung des               
   800107     2. August 2009     Newbus-Subsystems von Giant durch            
                                 Hinzufu:gen von sxlock und 8.0-RELEASE.      
   800108     21. November 2009  8.0-CURRENT nach Implementierung des         
                                 kevent-Filters EVFILT_USER.                  
                                 8.0-STABLE nach Erho:hung von                
   800500     7. Januar 2010     __FreeBSD_version, damit pkg_add -r          
                                 packages-8-stable verwendet.                 
                                 8.0-STABLE, nachdem die Prototypen von       
   800501     24. Januar 2010    scandir(3) und alphasort(3) gea:ndert        
                                 wurden, um der SUSv4 zu entsprechen.         
   800502     31. Januar 2010    8.0-STABLE nach Hinzufu:gen von sigpause(3). 
                                 8.0-STABLE nach dem Hinzufu:gen der ioctls   
                                 SIOCGIFDESCR und SIOCSIFDESCR fu:r           
                                 Netzwerk-Schnittstellen. Diese ioctls        
   800503     25. Februar 2010   ko:nnen, nach dem Vorbild von OpenBSD, dazu  
                                 verwendet werden,                            
                                 Schnittstellenbeschreibungen zu bearbeiten   
                                 und auszulesen.                              
                                 8.0-STABLE, nachdem x86emu, ein              
   800504     1. Ma:rz 2010      Software-Emulator von OpenBSD fu:r           
                                 x86-Prozessoren im Real-Mode, von CURRENT    
                                 u:bernommen wurde.                           
   800505     18. Mai 2010       8.0-STABLE nach dem Einfliessen von liblzma, 
                                 xz, xzdec und lzmainfo.                      
   801000     14. Juni 2010      8.1-RELEASE                                  
   801500     14. Juni 2010      8.1-STABLE nach 8.1-RELEASE.                 
                                 8.1-STABLE nach der KBI-A:nderung in struct  
   801501     November 3, 2010   sysentve und der Implementierung von         
                                 PL_FLAG_SCE/SCX/EXEC/SI und pl_siginfo fu:r  
                                 ptrace(PT_LWPINFO) .                         
   802000     22. Dezember 2010  8.2-RELEASE                                  
   802500     22. Dezember 2010  8.2-STABLE, nachdem 8.2-RELEASE erzeugt      
                                 wurde.                                       
                                 8.2-STABLE, nachdem DTrace aktualisiert      
   802501     28. Februar 2011   wurde (so wird nun auch Userland-Tracing     
                                 unterstu:tzt).                               
   802502     6. Ma:rz 2011      8.2-STABLE, nachdem log2 und log2f in libm   
                                 aufgenommen wurden.                          
                                 8.2-STABLE, nachdem gcc auf die letzte unter 
   802503     1. Mai 2011        der GPLv2 stehenden Version (aus dem FSF     
                                 gcc-4_2-Zweig) aktualisiert wurde.           
                                 8.2-STABLE, nachdem KPI sowie die            
   802504     28. Mai 2011       Infrastruktur zur Unterstu:tzung von         
                                 "modular congestion control" implementiert   
                                 wurden.                                      
   802505     28. Mai 2011       8.2-STABLE, nachdem die KPIs Hhook und Khelp 
                                 implementiert wurden.                        
   802506     M28. Mai 2011      8.2-STABLE, nachdem OSD in die Struktur      
                                 tcpcb eingebaut wurde.                       
   802507     6. Juni 2011       8.2-STABLE nach dem Import von ZFS v28.      
   802508     8. Juni 2011       8.2-STABLE, nach dem Entfernen der Methode   
                                 sv_schedtail struct sysvec.                  
   802509     14. Juli 2011      8.2-STABLE, nachdem die binutils um die      
                                 SSSE3-Unterstu:tzung erweitert wurden.       
   802510     19. Juli 2011      8.2-STABLE, nach dem Hinzufu:gen des Flags   
                                 RFTSIGZMB zu rfork(2).                       
   900000     22. August 2009    9.0-CURRENT.                                 
                                 9.0-CURRENT nach dem Import von x86emu,      
   900001     8. September 2009  einem Software-Emulator von OpenBSD fu:r     
                                 x86-Prozessoren im Real-Mode.                
   900002     23. September 2009 9.0-CURRENT nach Implementierung des         
                                 kevent-Filters EVFILT_USER.                  
   900003     2. Dezember 2009   9.0-CURRENT nach Hinzufu:gen von sigpause(3) 
                                 und der PIE-Unterstu:tzung zu csu.           
                                 9.0-CURRENT nach Hinzufu:gen von libulog und 
   900004     6. Dezember 2009   dessen                                       
                                 libutempter-Kompatibilita:tsschnittstelle.   
                                 9.0-CURRENT nach Hinzufu:gen von             
                                 sleepq_sleepcnt(), das dazu verwendet werden 
   900005     12. Dezember 2009  kann, die Anzahl der in einer bestimmten     
                                 Warteschlange eingereihten Threads           
                                 abzufragen.                                  
                                 9.0-CURRENT, nachdem die Prototypen von      
   900006     4. Januar 2010     scandir(3) und alphasort(3) gea:ndert        
                                 wurden, um der SUSv4 zu entsprechen.         
                                 9.0-CURRENT nach dem Entfernen von utmp(5)   
   900007     13. Januar 2010    und dem Hinzufu:gen von utmpx (siehe         
                                 getutxent(3)) zur besseren Erfassung von     
                                 Benutzeranmeldungen und Systemereignissen.   
   900008     20. Januar 2010    9.0-CURRENT nach der Einfu:hrung von BSDL    
                                 bc/dc zur Ersetzung von GNU bc/dc.           
                                 9.0-CURRENT nach dem Hinzufu:gen der ioctls  
                                 SIOCGIFDESCR und SIOCSIFDESCR fu:r           
                                 Netzwerk-Schnittstellen. Diese ioctls        
   900009     26. Januar 2010    ko:nnen, nach dem Vorbild von OpenBSD, dazu  
                                 verwendet werden,                            
                                 Schnittstellenbeschreibungen zu bearbeiten   
                                 und auszulesen.                              
   900010     22. Ma:rz 2010     9.0-CURRENT nach dem Import von zlib 1.2.4.  
   900011     24. April 2010     9.0-CURRENT nach Hinzufu:gen von Soft        
                                 Updates Journaling.                          
   900012     10. Mai 2010       9.0-CURRENT nach Hinzufu:gen von liblzma,    
                                 xz, xzdec und lzmainfo.                      
   900013     24. Mai 2010       9.0-CURRENT nach Einbringen von              
                                 USB-Fehlerbehebungen in linux(4).            
   900014     10. Juni 2010      9.0-CURRENT nach Hinzufu:gen von Clang.      
   900015     22. Juli 2010      9.0-CURRENT nach dem Import von BSD grep.    
   900016     28. Juli 2010      9.0-CURRENT, nachdem mti_zone zu struct      
                                 malloc_type_internal hinzugefu:gt wurde.     
                                 9.0-CURRENT nach dem Zuru:ckkehren zu GNU    
   900017     23. August 2010    grep als Standard und Hinzufu:gen der Option 
                                 WITH_BSD_GREP.                               
                                 9.0-CURRENT, nachdem das von pthread_kill(3) 
   900018     24. August 2010    generierte Signal in si_code als SI_LWP      
                                 bezeichnet wird. Zuvor war si_code SI_USER.  
   900019     28. August 2010    9.0-CURRENT nach Hinzufu:gen des Schalters   
                                 MAP_PREFAULT_READ zu mmap(2).                
                                 9.0-CURRENT, nachdem "drain"-Funktionalita:t 
   900020     9. September 2010  in sbufs integriert wurde (wodurch sich auch 
                                 das Layout von struct sbuf gea:ndert hat).   
   900021     13. September 2010 9.0-CURRENT, nachdem "Userland tracing" in   
                                 DTrace eingefu:hrt wurde.                    
                                 9.0-CURRENT nach Hinzufu:gen der BSDL        
   900022     2. Oktober 2010    man-Utilities (und gleichzeitigem Entfernen  
                                 der GNU/GPL man-Utilities).                  
   900023     11. Oktober 2010   9.0-CURRENT nach der Aktualisierung von xz   
                                 auf den git-Snapshot 20101010.               
   900024     11. November 2010  9.0-CURRENT, nachdem libgcc.a durch          
                                 libcompiler_rt.a.                            
   900025     12. November 2010  9.0-CURRENT nach der Einfu:hrung von         
                                 "modularised congestion control".            
                                 9.0-CURRENT nach der Einfu:hrung von "Serial 
   900026     30. November 2010  Management Protocol (SMP) passthrough" sowie 
                                 den XPT_SMP_IO und XPT_GDEV_ADVINFO CAM      
                                 CCBs.                                        
   900027     5. Dezember 2010   9.0-CURRENT, nachdem log2 zu libm            
                                 hinzugefu:gt wurde.                          
                                 9.0-CURRENT, nach dem HInzufu:gen von Hhook  
   900028     21. Dezember 2010  (Helper Hook), Khelp (Kernel Helpers) und    
                                 Object Specific Data (OSD) KPIs.             
                                 9.0-CURRENT, nach der TCP-Stack modifiziert  
                                 wurde, um es den Khelp-Modulen zu erlauben,  
   900029     28. Dezember 2010  mit ihm u:ber Helper Hook Points zu          
                                 kommunizieren und Verbindungsdaten im        
                                 TCP-Kontrollblock zu speichern.              
   900030     12. Januar 2011    9.0-CURRENT, nachdem libdialog auf die       
                                 Version 20100428 aktualisiert wurde.         
   900031     7. Februar 2011    9.0-CURRENT, nach dem Hinzufu:gen von        
                                 pthread_getthreadid_np(3).                   
   900032     8. Februar 2011    9.0-CURRENT, nachdem Prototyp und Symbol     
                                 fu:r uio_yield entfernt wurden.              
   900033     18. Februar 2011   9.0-CURRENT, nachdem die binutils auf        
                                 Version 2.17.50 aktualisiert wurden.         
   900034     8. Ma:rz 2011      9.0-CURRENT, nachdem die Struktur sysvec     
                                 (sv_schedtail) modifiziert wurde.            
                                 9.0-CURRENT, nach dem Update des im          
   900035     29. Ma:rz 20111    Basissystem enthaltenen gcc sowie von        
                                 libstdc++ auf die letzten unter GPLv2        
                                 lizenzierten Versionen.                      
                                 9.0-CURRENT, nachdem libobjc und die         
   900036     18. April 2011     Unterstu:tzung fu:r Objective-C aus dem      
                                 Basissystem entfernt wurden.                 
                                 9.0-CURRENT, nach dem Import der             
   900037     13. Mai 2011       libprocstat(3)-Bibliothek sowie von fuser(1) 
                                 in das Basissystem.                          
   900038     22. Mai 2011       9.0-CURRENT, nachdem ein Lock-Flag zu        
                                 VFS_FHTOVP(9) hinzugefu:gt wurde.            
   900039     28. Juni 2011      9.0-CURRENT, nachdem pf von OpenBSD 4.5      
                                 importiert wurde.                            
                                 Standardma:ssige Erho:hung von MAXCPU fu:r   
   900040     19. Juli 2011      FreeBSD auf 64 fu:r amd64 und ia64 und auf   
                                 128 fu:r XLP (mips).                         
                                 9.0-CURRENT, nachdem                         
   900041     13. August 2011    Capsicum-Funktionalita:ten implementiert     
                                 wurden. Zusa:tzlich wurde fget(9) um ein     
                                 Rechte-Argument erweitert.                   
                                 Versionsspru:nge fu:r Shared-Libraries deren 
   900042     28. August 2011    ABI sich gea:ndert hat, in Vorbereitung fu:r 
                                 9.0.                                         
                                 Automatische Erkennung von                   
   900043     2. September 2011  USB-Massenspeicher Gera:ten, die das no      
                                 synchronize cache SCSI Kommando nicht        
                                 unterstu:tzen.                               
   900044     10. September 2011 Re-factor auto-quirk.                        
                                 Allen nicht-kompatiblen                      
   900045     13. Oktober 2011   Systemaufruf-Einstiegspunkten wurde ein sys_ 
                                 vorangestellt.                               

  Anmerkung:

   Beachten Sie, dass 2.2-STABLE sich nach dem 2.2.5-RELEASE manchmal als
   "2.2.5-STABLE" identifiziert. Das Muster war fru:her das Jahr gefolgt von
   dem Monat, aber wir haben uns entschieden, ab 2.2. einen geradlinigeren
   Ansatz mit major/minor-Nummern zu benutzen. Dies liegt daran, dass
   gleichzeitiges Entwickeln an mehreren Zweigen es unmo:glich macht, die
   Versionen nur mit Hilfe des Datums des Releases zu unterteilen. Wenn Sie
   jetzt einen Port erstellen brauchen Sie sich nicht um alte -CURRENTs zu
   ku:mmern; diese sind hier nur als Referenz augefu:hrt.

12.6. Etwas hinter die bsd.port.mk-Anweisung schreiben

   Schreiben Sie bitte nichts hinter die .include <bsd.port.mk>-Zeile.
   Normalerweise kann dies vermieden werden, indem Sie die Datei
   bsd.port.pre.mk irgendwo in der Mitte Ihres Makefiles und bsd.port.post.mk
   am Ende einfu:gen.

  Anmerkung:

   Sie du:rfen entweder nur das bsd.port.pre.mk/bsd.port.post.mk-Paar oder
   bsd.port.mk alleine hinzufu:gen; vermischen Sie diese Verwendungen nicht!

   bsd.port.pre.mk definiert nur einige Variablen, welche in Tests im
   Makefile benutzt werden ko:nnen, bsd.port.post.mk definiert den Rest.

   Hier sind einige wichtige Variablen, welche in bsd.port.pre.mk definiert
   sind (dies ist keine vollsta:ndige Liste, lesen Sie bitte bsd.port.mk fu:r
   eine vollsta:ndige Auflistung).

     Variable                            Beschreibung                         
   ARCH          Die Architektur, wie von uname -m zuru:ckgegeben (z.B. i386) 
   OPSYS         Der Typ des Betriebsystems, wie von uname -s zuru:ckgegeben  
                 (z.B. FreeBSD)                                               
   OSREL         Die Release Version des Betriebssystems (z.B., 2.1.5 oder    
                 2.2.7)                                                       
   OSVERSION     Die numerische Version des Betriebssystems; gleichbedeutend  
                 mit __FreeBSD_version.                                       
                 Das Objektformat des Systems (elf oder aout; beachten Sie,   
   PORTOBJFORMAT dass fu:r "moderne" Versionen von FreeBSD aout veraltet      
                 ist).                                                        
   LOCALBASE     Die Basis des "local" Verzeichnisbaumes (z.B. /usr/local/)   
   PREFIX        Wo der Port sich selbst installiert (siehe Mehr              
                 Informationen u:ber PREFIX).                                 

  Anmerkung:

   Falls Sie die Variablen USE_IMAKE, USE_X_PREFIX, oder MASTERDIR definieren
   mu:ssen, sollten Sie dies vor dem Einfu:gen von bsd.port.pre.mk machen.

   Hier sind ein paar Beispiele von Dingen, die Sie hinter die Anweisung
   bsd.port.pre.mk schreiben ko:nnen:

 # lang/perl5 muss nicht kompliliert werden, falls perl5 schon auf dem System ist
 .if ${OSVERSION} > 300003
 BROKEN= perl ist im System
 .endif

 # nur eine Versionsnummer fu:r die ELF Version der shlib
 .if ${PORTOBJFORMAT} == "elf"
 TCL_LIB_FILE=  ${TCL_LIB}.${SHLIB_MAJOR}
 .else
 TCL_LIB_FILE=  ${TCL_LIB}.${SHLIB_MAJOR}.${SHLIB_MINOR}
 .endif

 # die Software erstellt schon eine Verknu:pfung fu: ELF, aber nicht fu: a.out
 post-install:
 .if ${PORTOBJFORMAT} == "aout"
        ${LN} -sf liblinpack.so.1.0 ${PREFIX}/lib/liblinpack.so
 .endif

   Sie haben sich daran erinnert Tabulator statt Leerzeichen nach BROKEN= und
   TCL_LIB_FILE= zu benutzen, oder? :-).

12.7. Benutzen Sie die exec-Anweisung in Wrapper-Skripten

   Falls der Port ein Shellskript installiert, dessen Zweck es ist ein
   anderes Programm zu starten, und falls das Starten des Programmes die
   letzte Aktion des Skripts ist, sollten Sie sicherstellen, dass Sie die
   Funktion exec dafu:r benutzen; zum Beispiel:

 #!/bin/sh
 exec %%LOCALBASE%%/bin/java -jar %%DATADIR%%/foo.jar "$@"

   Die Funktion exec ersetzt den Shell-Prozess mit dem angegebenen Programm.
   Falls exec ausgelassen wird, verbleibt der Shell-Prozess im Speicher
   wa:hrend das Programm ausgefa:hrt wird und verbraucht unno:tig
   Systemressourcen.

12.8. Aufgaben vernu:nftig lo:sen

   Das Makefile sollte die no:tigen Schritte einfach und vernu:nftig
   durchfu:hren. Wenn Sie ein einige Zeilen einsparen oder die Lesbarkeit
   verbessern ko:nnen, dann machen Sie dies bitte. Beispiele sind: Ein
   make-Konstrukt .if anstatt eines Shellkonstrukt if zu verwenden, anstatt
   do-extract neu zu definieren, dies mit EXTRACT* machen, oder GNU_CONFIGURE
   anstelle von CONFIGURE_ARGS += --prefix=${PREFIX} zu verwenden.

   Falls Sie sich in einer Situation wiederfinden, in der Sie viel Code neu
   schreiben mu:ssen, um etwas zu testen, sollten Sie zuerst bsd.port.mk
   erneut konsultieren und nachpru:fen ob es nicht bereits eine Lo:sung fu:r
   Ihr Problem entha:lt. Es ist zwar schwer zu lesen, beinhaltet jedoch eine
   Menge kurzer Lo:sungen fu:r viele scheinbar schwierige Probleme.

12.9. Beru:cksichtigen Sie sowohl CC als auch CXX

   Der Port sollte sowohl die CC- wie auch die CXX-Variable beru:cksichtigen.
   Damit ist gemeint, dass der Port diese Variablen nicht ohne Ru:cksicht auf
   eventuell schon gesetzte Werte einfach u:berschreiben sollte; stattdessen
   sollten neue Werte an schon existierende angeha:ngt werden. Dadurch
   ko:nnen Build-Optionen, die alle Ports betreffen, global definiert werden.

   Falls der Port diese Variablen nicht beru:cksichtigt, sollte
   NO_PACKAGE=ignores either cc or cxx ins Makefile eingefu:gt werden.

   Im Folgenden wird ein Beispiel eines Makefiles gezeigt, welches die beiden
   Variablen CC und CXX beru:cksichtigt. Beachten Sie das ?=:

 CC?= gcc

 CXX?= g++

   Nachfolgend ein Beispiel, welches weder CC noch CXX beru:cksichtigt:

 CC= gcc

 CXX= g++

   Die Variablen CC und CXX ko:nnen auf FreeBSD-Systemen in /etc/make.conf
   definiert werden. Im ersten Beispiel wird ein Wert nur dann gesetzt, falls
   dieser vorher noch nicht gesetzt war, um so systemweite Definitionen zu
   beru:cksichtigen. Im zweiten Beispiel werden die Variablen ohne Ru:cksicht
   u:berschrieben.

12.10. Beru:cksichtigen Sie CFLAGS

   Der Port sollte die Variable CFLAGS beru:cksichtigen. Damit ist gemeint,
   dass der Port den Wert dieser Variablen nicht absolut setzen und damit
   existierende Werte u:berschreiben sollte; stattdessen sollte er weitere
   Werte der Variablen durch Anha:ngen hinzufu:gen. Dadurch ko:nnen
   Build-Optionen, die alle Ports betreffen, global definiert werden.

   Falls der Port diese Variablen nicht beru:cksichtigt, sollte
   NO_PACKAGE=ignores cflags ins Makefile eingefu:gt werden.

   Im Folgenden wird ein Beispiel eines Makefiles gezeigt, welches die
   Variable CFLAGS beru:cksichtigt. Beachten Sie das +=:

 CFLAGS+= -Wall -Werror

   Nachfolgend finden Sie ein Beispiel, welches die CFLAGS-Variable nicht
   beru:cksichtigt:

 CFLAGS= -Wall -Werror

   Die Variable CFLAGS wird auf FreeBSD-Systemen in /etc/make.conf definiert.
   Im ersten Beispiel werden weitere Flags an die Variable CFLAGS angeha:ngt
   und somit der bestehende Wert nicht gelo:scht. Im zweiten Beispiel wird
   die Variable ohne Ru:cksicht u:berschrieben.

   Sie sollten Optimierungsflags aus Makefiles Dritter entfernen. Die CFLAGS
   des Systems beinhalten systemweite Optimierungsflags. Ein Beispiel eines
   unvera:nderten Makefiles:

 CFLAGS= -O3 -funroll-loops -DHAVE_SOUND

   Werden nun systemweite Optimierungsflags verwendet so wu:rde das Makefile
   in etwa folgendermassen aussehen:

 CFLAGS+= -DHAVE_SOUND

12.11. Threading-Bibliotheken

   Die Threading-Bibliothek muss mit Hilfe eines speziellen Linker-Flags
   -pthread in die Bina:rdateien unter FreeBSD gebunden werden. Falls ein
   Port auf ein direktes Verlinken gegen -lpthread oder -lc_r besteht, passen
   Sie den Port bitte so an, dass er die durch das Port-Framework
   bereitgestellte Variable PTHREAD_LIBS verwendet. Diese Variable hat
   u:blicherweise den Wert -pthread, kann aber auf einigen Architekturen und
   FreeBSD-Versionen abweichende Werte haben und daher sollte nie -pthread
   direkt in Patches geschrieben werden, sondern immer PTHREAD_LIBS.

  Anmerkung:

   Falls durch das Setzen von PTHREAD_LIBS der Bau des Ports mit der
   Fehlermeldung unrecognized option '-pthread' abbricht, kann die Verwendung
   des gcc als Linker durch setzen von CONFIGURE_ENV auf LD=${CC} helfen. Die
   Option -pthread wird nicht direkt von ld unterstu:tzt.

12.12. Ru:ckmeldungen

   Brauchbare A:nderungen/Patches sollten an den urspru:nglichen
   Autor/Maintainer der Software geschickt werden, damit diese in der
   na:chsten Version der Software mit aufgenommen werden ko:nnen. Dadurch
   wird Ihre Aufgabe fu:r die na:chste Version der Software deutlich
   einfacher.

12.13. README.html

   Nehmen Sie bitte keine README.html in den Port auf. Diese Datei ist kein
   Bestandteil der CVS-Sammlung sondern wird durch make readme erzeugt.

12.14. Einen Port durch BROKEN, FORBIDDEN oder IGNORE als nicht installierbar
markieren

   In manchen Fa:llen sollten Benutzer davon abgehalten werden einen Port zu
   installieren. Um einem Benutzer mitzuteilen, dass ein Port nicht
   installiert werden sollte, gibt es mehrere Variablen fu:r make, die im
   Makefile des Ports genutzt werden ko:nnen. Der Wert der folgenden
   make-Variablen wird dem Benutzer als Grund fu:r die Ablehnung der
   Installation des Ports zuru:ckgegeben. Bitte benutzen Sie die richtige
   make-Variable, denn jede entha:lt eine vo:llig andere Bedeutung fu:r den
   Benutzer und das automatische System, das von dem Makefile abha:ngt, wie
   der Ports-Build-Custer, FreshPorts und portsmon.

  12.14.1. Variablen

     * BROKEN ist reserviert fu:r Ports, welche momentan nicht korrekt
       kompiliert, installiert oder deinstalliert werden. Es sollte fu:r
       Ports benutzt werden, von denen man annimmt, dass dies ein tempora:res
       Problem ist.

       Falls angegeben, wird der Build-Cluster dennoch versuchen den Port zu
       bauen, um zu sehen, ob das zugrunde liegende Problem behoben wurde
       (das ist jedoch im Allgemeinen nicht der Fall).

       Benutzen Sie BROKEN zum Beispiel, wenn ein Port:

          * nicht kompiliert

          * beim Konfiguration- oder Installation-Prozess scheitert

          * Dateien ausserhalb von ${LOCALBASE} installiert

          * beim Deinstallieren nicht alle seine Dateien sauber entfernt
            (jedoch kann es akzeptable und wu:nschenswert sein, Dateien, die
            vom Nutzer vera:ndert wurden, nicht zu entfernen)

     * FORBIDDEN wird fu:r Ports verwendet, die Sicherheitslu:cken enthalten
       oder die ernste Sicherheitsbedenken fu:r das FreeBSD-System aufwerfen,
       wenn sie installiert sind (z.B. ein als unsicher bekanntes Programm,
       oder ein Programm, das einen Dienst zur Verfu:gung stellt, der leicht
       kompromittiert werden kann). Ports sollten als FORBIDDEN
       gekennzeichnet werden, sobald ein Programm eine Schwachstelle hat und
       kein Update vero:ffentlicht wurde. Idealerweise sollten Ports so bald
       wie mo:glich aktualisiert werden wenn eine Sicherheitslu:cke entdeckt
       wurde, um die Zahl verwundbarer FreeBSD-Hosts zu verringern (wir
       scha:tzen es fu:r unsere Sicherheit bekannt zu sein), obwohl es
       manchmal einen beachtlichen Zeitabstand zwischen der Bekanntmachung
       einer Schwachstelle und dem entsprechenden Update gibt. Bitte
       kennzeichnen Sie einen Port nicht aus irgendeinem Grund ausser
       Sicherheit als FORBIDDEN.

     * IGNORE ist fu:r Ports reserviert, die aus anderen Gru:nden nicht
       gebaut werden sollten. Es sollte fu:r Ports verwendet werden, in denen
       ein strukturelles Problem vermutet wird. Der Build-Cluster wird unter
       keinen Umsta:nden Ports, die mit IGNORE markiert sind, erstellen.
       Verwenden Sie IGNORE zum Beispiel, wenn ein Port:

          * kompiliert, aber nicht richtig la:uft

          * nicht auf der installierten Version von FreeBSD la:uft

          * FreeBSD Kernelquelltext zum Bauen beno:tigt, aber der Benutzer
            diese nicht installiert hat

          * ein Distfile beno:tigt, welches aufgrund von
            Lizenzbeschra:nkungen nicht automatisch abgerufen werden kann

          * nicht korrekt mit einem momentan installiertem Port arbeitet (der
            Port ha:ngt zum Beispiel von www/apache21 ab, aber www/apache13
            ist installiert)

  Anmerkung:

       Wenn ein Port mit einem momentan installiertem Port kollidiert (zum
       Beispiel, wenn beide eine Datei an die selbe Stelle installieren,
       diese aber eine andere Funktion hat), benutzen Sie stattdessen
       CONFLICTS. CONFLICTS setzt IGNORE dann selbststa:ndig.

     * Um einen Port nur auf bestimmte Systemarchitekturen mit IGNORE zu
       markieren, gibt es zwei Variablen, die automatisch IGNORE fu:r Sie
       setzen: ONLY_FOR_ARCHS und NOT_FOR_ARCHS. Beispiele:

 ONLY_FOR_ARCHS= i386 amd64

 NOT_FOR_ARCHS= alpha ia64 sparc64

       Eine eigene IGNORE-Ausgabe kann mit ONLY_FOR_ARCHS_REASON und
       NOT_FOR_ARCHS_REASON festgelegt werden. Fu:r eine bestimmte
       Architektur sind Angaben durch ONLY_FOR_ARCHS_REASON_ARCH und
       NOT_FOR_ARCHS_REASON_ARCH mo:glich.

     * Wenn ein Port i386-Bina:rdateien herunterla:dt und installiert, sollte
       IA32_BINARY_PORT gesetzt werden. Wenn die Variable gesetzt ist, wird
       u:berpru:ft, ob das Verzeichnis /usr/lib32 fu:r IA32-Versionen der
       Bibliotheken vorhanden ist, und ob der Kernel mit IA32-Kompatibilita:t
       gebaut wurde. Wenn eine dieser zwei Voraussetzungen nicht erfu:llt
       ist, wird IGNORE automatisch gesetzt.

  12.14.2. Anmerkungen zur Implementierung

   Zeichenketten sollten nicht in Anfu:hrungszeichen gesetzt werden. Auch die
   Wortwahl der Zeichenketten sollte die Art und Weise beachten, wie die
   Informationen dem Nutzer angezeigt werden. Beispiele:

 BROKEN= this port is unsupported on FreeBSD 5.x

 IGNORE= is unsupported on FreeBSD 5.x

   resultieren in den folgenden Ausgaben von make describe:

 ===>  foobar-0.1 is marked as broken: this port is unsupported on FreeBSD 5.x.

 ===>  foobar-0.1 is unsupported on FreeBSD 5.x.

12.15. Kennzeichnen eines Ports zur Entfernung durch DEPRECATED oder
EXPIRATION_DATE

   Denken Sie bitte daran, dass BROKEN und FORBIDDEN nur als tempora:rer
   Ausweg verwendet werden sollten, wenn ein Port nicht funktioniert.
   Dauerhaft defekte Ports sollten komplett aus der Ports-Sammlung entfernt
   werden.

   Wenn es sinnvoll ist, ko:nnen Benutzer vor der anstehenden Entfernung
   eines Ports mit DEPRECATED und EXPIRATION_DATE gewarnt werden. Ersteres
   ist einfach eine Zeichenkette, die angibt, warum der Port entfernt werden
   soll. Letzteres ist eine Zeichenkette im ISO 8601-Format (JJJJ-MM-TT).
   Beides wird dem Benutzer gezeigt.

   Es ist mo:glich DEPRECATED ohne EXPIRATION_DATE zu setzen (zum Beispiel,
   um eine neuere Version des Ports zu empfehlen), aber das Gegenteil ist
   sinnlos.

   Es gibt keine Vorschrift wie lange die Vorwarnzeit sein muss. Gegenwa:rtig
   ist es u:blich einen Monat fu:r sicherheitsrelevante Probleme und zwei
   Monate fu:r Build-Probleme anzusetzen. Dies gibt allen interessierten
   Committern ein wenig Zeit die Probleme zu beheben.

12.16. Vermeiden Sie den Gebrauch des .error-Konstruktes

   Der korrekte Weg eines Makefile anzuzeigen, dass der Port aufgrund eines
   externen Grundes nicht installiert werden kann (zum Beispiel, weil der
   Benutzer eine ungu:ltige Kombination von Build-Optionen angegeben hat),
   ist IGNORE auf einen nicht leeren Wert zu setzen. Dieser wird dann
   formatiert und dem Benutzer von make install ausgegeben.

   Es ist ein verbreiteter Fehler .error fu:r diesem Zweck zu verwenden. Das
   Problem dabei ist, dass viele automatisierte Werkzeuge, die mit dem
   Ports-Baum arbeiten, in dieser Situation fehlschlagen. Am Ha:ufigsten
   tritt das Problem beim Versuch /usr/ports/INDEX zu bauen auf (siehe
   Abschnitt 9.1, "make describe ausfu:hren"). Jedoch schlagen auch
   trivialere Befehle wie make maintainer in diesem Fall fehl. Dies ist nicht
   akzeptabel!

   Beispiel 12.1. Wie vermeidet man die Verwendung von .error

   Nehmen Sie an, dass die Zeile

 USE_POINTYHAT=yes

   in make.conf enthalten ist. Der erste der folgenden zwei
   Makefile-Schnipsel la:sst make index fehlschlagen, wa:hrend der zweite
   dies nicht tut.

 .if USE_POINTYHAT
 .error "POINTYHAT is not supported"
 .endif

 .if USE_POINTYHAT
 IGNORE=POINTYHAT is not supported
 .endif

12.17. Verwendung von sysctl

   Vom Gebrauch von sysctl wird, ausser in Targets, abgeraten. Das liegt
   daran, dass die Auswertung aller makevars, wie sie wa:hrend make index
   verwendet werden, dann den Befehl ausfu:hren muss, welches den Prozess
   weiter verlangsamt.

   Die Verwendung von sysctl(8) sollte immer durch die Variable SYSCTL
   erfolgen, da diese den vollsta:ndigen Pfad entha:lt und u:berschrieben
   werden kann, so dies als notwendig erachtet wird.

12.18. Erneutes Ausliefern von Distfiles

   Manchmal a:ndern die Autoren der Software den Inhalt vero:ffentlichter
   Distfiles, ohne den Dateinamen zu a:ndern. Sie mu:ssen u:berpru:fen, ob
   die A:nderungen offizell sind und vom Autor durchgefu:hrt wurden. Es ist
   in der Vergangenheit vorgekommen, dass Distfiles still und heimlich auf
   dem Download-Server gea:ndert wurden, um Schaden zu verursachen oder die
   Sicherheit der Nutzer zu kompromittieren.

   Verschieben Sie das alte Distfile und laden Sie das neue herunter.
   Entpacken Sie es und vergleichen Sie den Inhalt mittels diff(1). Wenn Sie
   nichts Verda:chtiges sehen ko:nnen Sie distinfo aktualisieren. Stellen Sie
   sicher, dass die A:nderungen in Ihrem PR oder Commit-Protokoll
   zusammengefasst sind, um zu Gewa:hrleisten, dass nichts Negatives passiert
   ist.

   Sie ko:nnen auch mit den Autoren der Software in Verbindung treten und
   sich die A:nderungen besta:tigen lassen.

12.19. Verschiedenes

   Die Dateien pkg-descr und pkg-plist sollten beide doppelt kontrolliert
   werden. Wenn Sie einen Port nachpru:fen und glauben, dass man es besser
   machen kann, dann verbessern Sie ihn bitte.

   Bitte kopieren Sie nicht noch mehr Exemplare der GNU General Public
   License in unser System.

   Bitte u:berpru:fen Sie alle gesetzlichen Punkte gru:ndlich! Lassen Sie uns
   bitte keine illegale Software verbreiten!

                      Kapitel 13. Beispiel eines Makefile

   Hier ein Beispiel fu:r ein Makefile, welches als Vorlage fu:r einen neuen
   Port dienen kann. Alle zusa:tzlichen Kommentare in eckigen Klammern
   mu:ssen entfernt werden!

   Es wird empfohlen, die hier gezeigte Formatierung zu u:bernehmen
   (Reihenfolge der Variablen, Leerzeichen zwischen einzelnen Abschnitten,
   usw.). Dadurch werden die wichtigen Informationen sofort ersichtlich. Zur
   U:berpru:fung Ihres Makefiles sollten Sie portlint verwenden.

 [the header...just to make it easier for us to identify the ports.]
 # New ports collection makefile for:   xdvi
 [the "version required" line is only needed when the PORTVERSION
  variable is not specific enough to describe the port.]
 # Date created:                26 May 1995
 [this is the person who did the original port to FreeBSD, in particular, the
 person who wrote the first version of this Makefile.  Remember, this should
 not be changed when upgrading the port later.]
 # Whom:                        Satoshi Asami <asami@FreeBSD.org>
 #
 # $FreeBSD$
 [ ^^^^^^^^^ This will be automatically replaced with RCS ID string by CVS
 when it is committed to our repository.  If upgrading a port, do not alter
 this line back to "$FreeBSD$".  CVS deals with it automatically.]
 #

 [section to describe the port itself and the master site - PORTNAME
  and PORTVERSION are always first, followed by CATEGORIES,
  and then MASTER_SITES, which can be followed by MASTER_SITE_SUBDIR.
  PKGNAMEPREFIX and PKGNAMESUFFIX, if needed, will be after that.
  Then comes DISTNAME, EXTRACT_SUFX and/or DISTFILES, and then
  EXTRACT_ONLY, as necessary.]
 PORTNAME=      xdvi
 PORTVERSION=   18.2
 CATEGORIES=    print
 [do not forget the trailing slash ("/")!
  if you are not using MASTER_SITE_* macros]
 MASTER_SITES=  ${MASTER_SITE_XCONTRIB}
 MASTER_SITE_SUBDIR= applications
 PKGNAMEPREFIX= ja-
 DISTNAME=      xdvi-pl18
 [set this if the source is not in the standard ".tar.gz" form]
 EXTRACT_SUFX=  .tar.Z

 [section for distributed patches -- can be empty]
 PATCH_SITES=   ftp://ftp.sra.co.jp/pub/X11/japanese/
 PATCHFILES=    xdvi-18.patch1.gz xdvi-18.patch2.gz

 [maintainer; *mandatory*!  This is the person who is volunteering to
  handle port updates, build breakages, and to whom a users can direct
  questions and bug reports.  To keep the quality of the Ports Collection
  as high as possible, we no longer accept new ports that are assigned to
  "ports@FreeBSD.org".]
 MAINTAINER=    asami@FreeBSD.org
 COMMENT=       A DVI Previewer for the X Window System

 [dependencies -- can be empty]
 RUN_DEPENDS=   gs:${PORTSDIR}/print/ghostscript
 LIB_DEPENDS=   Xpm.5:${PORTSDIR}/graphics/xpm

 [this section is for other standard bsd.port.mk variables that do not
  belong to any of the above]
 [If it asks questions during configure, build, install...]
 IS_INTERACTIVE=        yes
 [If it extracts to a directory other than ${DISTNAME}...]
 WRKSRC=                ${WRKDIR}/xdvi-new
 [If the distributed patches were not made relative to ${WRKSRC}, you
  may need to tweak this]
 PATCH_DIST_STRIP=      -p1
 [If it requires a "configure" script generated by GNU autoconf to be run]
 GNU_CONFIGURE= yes
 [If it requires GNU make, not /usr/bin/make, to build...]
 USE_GMAKE=     yes
 [If it is an X application and requires "xmkmf -a" to be run...]
 USE_IMAKE=     yes
 [et cetera.]

 [non-standard variables to be used in the rules below]
 MY_FAVORITE_RESPONSE=  "yeah, right"

 [then the special rules, in the order they are called]
 pre-fetch:
     i go fetch something, yeah

 post-patch:
     i need to do something after patch, great

 pre-install:
     and then some more stuff before installing, wow

 [and then the epilogue]
 .include <bsd.port.mk>

                     Kapitel 14. Auf dem Laufenden bleiben

   Inhaltsverzeichnis

   14.1. FreshPorts

   14.2. Die Webschnittstelle zum Quelltext-Repository

   14.3. Die FreeBSD Ports-Mailingliste

   14.4. Der Cluster zum Bauen von FreeBSD-Ports auf pointyhat.FreeBSD.org

   14.5. Der FreeBSD Ports-Distfile-Scanner

   14.6. Das FreeBSD Ports-Monitoring-System

   Die FreeBSD Ports-Sammlung vera:ndert sich sta:ndig. Hier finden Sie
   einige Informationen, wie Sie auf dem Laufenden bleiben.

14.1. FreshPorts

   Einer der einfachsten Wege, um sich u:ber Aktualisierungen, die bereits
   durchgefu:hrt wurden, zu informieren, ist sich bei FreshPorts anzumelden.
   Sie ko:nnen dort beliebige Ports auswa:hlen, die Sie beobachten mo:chten.
   Maintainern wird ausdru:cklich empfohlen sich anzumelden, da Sie nicht nur
   u:ber Ihre eigenen A:nderungen informiert werden, sondern auch u:ber die
   aller anderen Committer (Diese sind oft no:tig, um u:ber A:nderungen des
   zugrunde liegenden Frameworks informiert zu bleiben. Obwohl es ho:flich
   wa:re, vorher u:ber solche A:nderungen benachrichtigt zu werden, wird es
   manchmal vergessen oder ist einfach nicht mo:glich. Ausserdem sind die
   A:nderungen manchmal nur sehr klein. Wir erwarten von jedem in solchen
   Fa:llen nach bestem Gewissen zu urteilen).

   Wenn Sie Fresh-Ports benutzen mo:chten, beno:tigen Sie nur einen Account.
   Falls Sie sich mit einer @FreeBSD.org E-Mailadresse registriert haben,
   werden Sie den Anmeldelink am rechten Rand der Seite finden. Diejenigen,
   die bereits einen FeshPorts-Account haben, aber nicht Ihre @FreeBSD.org
   E-Mailadresse benutzen, ko:nnen einfach Ihre E-Mailadresse auf
   @FreeBSD.org a:ndern, sich anmelden, und dann die A:nderung ru:ckga:ngig
   machen.

   FreshPorts bietet auch eine U:berpru:fungsfunktion, die automatisch alle
   Committs zum FreeBSD Ports-Baum testet. Wenn Sie sich fu:r diesen Dienst
   anmelden, werden Sie u:ber alle Fehler, die bei der U:berpru:fung Ihres
   Committs auftreten, informiert.

14.2. Die Webschnittstelle zum Quelltext-Repository

   Es ist mo:glich die Dateien des Quellen-Repositories mit Hilfe einer
   Webschnittstelle durchzusehen. A:nderungen, die das gesamte Ports-System
   betreffen, werden jetzt in der Datei CHANGES dokumentiert. Solche, die nur
   bestimmte Ports betreffen, in der Datei UPDATING. Aber die massgebliche
   Antwort auf alle Fragen liegt zweifellos darin, den Quelltext von
   bsd.port.mk und dazugeho:rige Dateien zu lesen.

14.3. Die FreeBSD Ports-Mailingliste

   Wenn Sie Maintainer sind, sollten Sie in Erwa:gung ziehen die FreeBSD
   ports-Mailingliste zu verfolgen. Wichtige A:nderungen an der grundlegenden
   Funktionsweise von Ports werden dort angeku:ndigt und dann in CHANGES
   committet.

14.4. Der Cluster zum Bauen von FreeBSD-Ports auf pointyhat.FreeBSD.org

   Eine der weniger bekannten Sta:rken von FreeBSD ist es, dass ein ganzer
   Cluster von Maschinen nur dafu:r reserviert ist, andauernd die
   Ports-Sammlung zu bauen, und zwar fu:r jedes grosse FreeBSD Release und
   jede Tier-1-Architektur. Die Ergebnisse ko:nnen Sie unter package building
   logs and errors finden.

   Alle Ports ausser denjenigen, die als IGNORE markiert sind, werden gebaut.
   Ports, die als BROKEN markiert sind, werden dennoch ausprobiert, um zu
   sehen, ob das zugrunde liegende Problem gelo:st wurde (Dies wird erreicht,
   indem TRYBROKEN an das Makefile des Ports u:bergeben wird).

14.5. Der FreeBSD Ports-Distfile-Scanner

   Der Build-Cluster ist dazu bestimmt, das neueste Release jedes Ports aus
   bereits heruntergeladenden Distfiles zu bauen. Da sich das Internet aber
   sta:ndig vera:ndert, ko:nnen Distfiles schnell verloren gehen. Der FreeBSD
   Ports-Distfile-Scanner versucht jeden Download-Standort fu:r jeden Port
   anzufragen, um herauszufinden, ob jedes Distfile noch verfu:gbar ist.
   Maintainer werden gebeten diesen Bericht regelma:ssig durchzusehen, nicht
   nur, um den Build-Prozess fu:r die Nutzer zu beschleunigen, sondern auch
   um zu vermeiden, dass auf den Maschinen, die freiwillig zur Verfu:gung
   gestellt werden, um all diese Dateien anzubieten, Ressourcen verschwendet
   werden.

14.6. Das FreeBSD Ports-Monitoring-System

   Eine weitere praktische Ressource ist das FreeBSD Ports-Monitoring-System
   (auch bekannt als portsmon). Dieses System besteht aus einer Datenbank,
   die Informationen von mehreren Quellen bezieht und es erlaubt diese u:ber
   ein Webinterface abzufragen. Momentan werden die Ports-Problemberichte
   (PRs), die Fehlerprotokolle des Build-Clusters und die einzelnen Dateien
   der Ports-Sammlung verwendet. In Zukunft soll das auf die
   Distfile-Pru:fung und weitere Informationsquellen ausgedehnt werden.

   Als Ausgangspunkt ko:nnen Sie alle Informationen eines Ports mit Hilfe der
   U:bersicht eines Ports betrachten.

   Zum Zeitpunkt des Schreibens ist dies die einzige Quelle, die GNATS
   PR-Eintra:ge auf Portnamen abbildet (PR-Einreicher geben den Portnamen
   nicht immer in der Zusammenfassung an, obwohl wir uns das wu:nschen
   wu:rden). Also ist portsmon ein guter Anlaufpunkt, wenn Sie herausfinden
   wollen, ob zu einem existierenden Port PRs oder Buildfehler eingetragen
   sind. Oder um herauszufinden, ob ein neuer Port, den Sie erstellen wollen,
   bereits eingereicht wurde.
