                      Das FreeBSD Porter-Handbuch

  The FreeBSD German Documentation Project

   Copyright (c) 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007,
   2008, 2009 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, und Java 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.

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

   Inhaltsverzeichnis

   1. Einfu:hrung

   2. Einen neuen Port erstellen

   3. Port erstellen auf die Schnelle

                3.1. Das Makefile schreiben

                3.2. Die Beschreibungsdateien erstellen

                             3.2.1. pkg-descr

                             3.2.2. pkg-plist

                3.3. Die Checksummendatei erzeugen

                3.4. Den Port testen

                3.5. Ihren Port mit portlint u:berpru:fen

                3.6. Den 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.2.1. PORTNAME und PORTVERSION

                             5.2.2. PORTREVISION und PORTEPOCH

                             5.2.3. PKGNAMEPREFIX und PKGNAMESUFFIX

                             5.2.4. LATEST_LINK

                             5.2.5. Namensregeln fu:r Pakete

                5.3. Kategorisierung

                             5.3.1. CATEGORIES

                             5.3.2. Aktuelle Liste der Kategorien

                             5.3.3. Wa:hlen der richtigen Kategorie

                             5.3.4. Eine neue Kategorie vorschlagen

                             5.3.5. Vorschlagen einer Neuorganisation
                             aller Kategorien

                5.4. Die Distributionsdateien

                             5.4.1. DISTVERSION/DISTNAME

                             5.4.2. MASTER_SITES

                             5.4.3. EXTRACT_SUFX

                             5.4.4. DISTFILES

                             5.4.5. EXTRACT_ONLY

                             5.4.6. PATCHFILES

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

                             5.4.8. DIST_SUBDIR

                             5.4.9. ALWAYS_KEEP_DISTFILES

                5.5. MAINTAINER

                5.6. COMMENT

                5.7. Abha:ngigkeiten (dependencies)

                             5.7.1. LIB_DEPENDS

                             5.7.2. RUN_DEPENDS

                             5.7.3. BUILD_DEPENDS

                             5.7.4. FETCH_DEPENDS

                             5.7.5. EXTRACT_DEPENDS

                             5.7.6. PATCH_DEPENDS

                             5.7.7. USE_*

                             5.7.8. Minimale Version einer
                             Abha:ngigkeit

                             5.7.9. Anmerkungen zu Abha:ngigkeiten

                             5.7.10. Zirkula:re Abha:ngigkeiten sind
                             fatal

                5.8. MASTERDIR

                5.9. Manualpages

                5.10. Info-Dateien

                5.11. Makefile-Optionen

                             5.11.1. KNOBS (Einstellungen)

                             5.11.2. OPTIONS

                             5.11.3. Automatische Aktivierung von
                             Funktionen

                5.12. Die Festlegung des Arbeitsverzeichnisses

                             5.12.1. WRKSRC

                             5.12.2. NO_WRKSUBDIR

                5.13. CONFLICTS

                5.14. Installation von Dateien

                             5.14.1. INSTALL_* macros

                             5.14.2. Zerlegen von Bina:rdateien

                             5.14.3. Installation eines ganzen
                             Verzeichnisbaums inklusive Dateien

                             5.14.4. Installation zusa:tzlicher
                             Dokumentation

                             5.14.5. Unterverzeichnisse mit PREFIX

   6. Besonderheiten

                6.1. Shared-Libraries

                6.2. Ports mit beschra:nkter Verbreitung

                             6.2.1. NO_PACKAGE

                             6.2.2. NO_CDROM

                             6.2.3. NOFETCHFILES

                             6.2.4. RESTRICTED

                             6.2.5. RESTRICTED_FILES

                6.3. Build-Mechanismen

                             6.3.1. Paralleles Bauen von Ports

                             6.3.2. make, gmake und imake

                             6.3.3. configure Skript

                             6.3.4. Benutzung von scons

                6.4. Benutzung von GNU autotools

                             6.4.1. Einfu:hrung

                             6.4.2. libtool

                             6.4.3. libltdl

                             6.4.4. autoconf und autoheader

                             6.4.5. automake und aclocal

                6.5. Benutzung von GNU gettext

                             6.5.1. Grundlegende Benutzung

                             6.5.2. Optionale Benutzung

                             6.5.3. Behandlung von
                             Message-Catalog-Verzeichnissen

                6.6. Die Benutzung von perl

                6.7. Benutzung von X11

                             6.7.1. X.Org-Komponenten

                             6.7.2. Ports, die Motif beno:tigen

                             6.7.3. X11 Schriftarten

                             6.7.4. Erzeugen eines ku:nstlichen
                             DISPLAY durch Xvfb

                             6.7.5. Desktop-Eintra:ge

                6.8. Benutzung von GNOME

                6.9. Benutzung von KDE

                             6.9.1. Variablen-Definitionen

                             6.9.2. Ports, die Qt beno:tigen

                             6.9.3. Komponentenauswahl (nur bei Qt
                             4.x)

                             6.9.4. Zusa:tzliche Besonderheiten

                6.10. Benutzung von Java

                             6.10.1. Variablen-Definitionen

                             6.10.2. Kompilieren mit Ant

                             6.10.3. Optimales Verfahren

                6.11. Webanwendungen, Apache und PHP

                             6.11.1. Apache

                             6.11.2. Webanwendungen

                             6.11.3. PHP

                             6.11.4. PEAR Module

                6.12. Python benutzen

                6.13. Benutzung von Tcl/Tk

                6.14. Emacs benutzen

                6.15. Ruby benutzen

                6.16. SDL verwenden

                6.17. wxWidgets verwenden

                             6.17.1. Einfu:hrung

                             6.17.2. Auswahl der Version

                             6.17.3. Komponentenauswahl

                             6.17.4. Unicode

                             6.17.5. Feststellen der installierten
                             Version

                             6.17.6. Vordefinierte Variablen

                             6.17.7. Verarbeitung in bsd.port.pre.mk

                             6.17.8. Weitere configure-Argumente

                6.18. Verwendung von Lua

                             6.18.1. Einfu:hrung

                             6.18.2. Auswahl der Version

                             6.18.3. Komponentenauswahl

                             6.18.4. Feststellen der installierten
                             Version

                             6.18.5. Vordefinierte Variablen

                             6.18.6. Verarbeitung in bsd.port.pre.mk

                6.19. Xfce verwenden

                6.20. Benutzung von Datenbanken

                6.21. Starten und Anhalten von Diensten (rc Skripten)

                             6.21.1. Anhalten und Deinstallieren von
                             Diensten

   7. Fortgeschrittene pkg-plist-Methoden

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

                7.2. Leere Verzeichnisse

                             7.2.1. Aufra:umen leerer Verzeichnisse

                             7.2.2. Erstellen leerer 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 Port aktualisieren

   11. Sicherheit der Ports

                11.1. Warum Sicherheit so wichtig ist

                11.2. Sicherheitslu:cken schliessen

                11.3. Die Community informiert halten

                             11.3.1. Die VuXML-Datenbank

                             11.3.2. Eine kurze Einfu:hrung in VuXML

                             11.3.3. Ihre A:nderungen an der
                             VuXML-Datenbank testen

   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. UIDs und GIDs

                12.9. Aufgaben vernu:nftig lo:sen

                12.10. Beru:cksichtigen Sie sowohl CC als auch CXX

                12.11. Beru:cksichtigen Sie CFLAGS

                12.12. Threading-Bibliotheken

                12.13. Ru:ckmeldungen

                12.14. README.html

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

                             12.15.1. Variablen

                             12.15.2. Anmerkungen zur Implementierung

                12.16. Kennzeichnen eines Ports zur Entfernung durch
                DEPRECATED oder EXPIRATION_DATE

                12.17. Vermeiden Sie den Gebrauch des
                .error-Konstruktes

                12.18. Verwendung von sysctl

                12.19. Erneutes Ausliefern von Distfiles

                12.20. Notwendige Abhilfen (Workarounds)

                12.21. 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. Die FreeBSD Port-Distfile-Pru:fung

                14.6. Das FreeBSD Ports-Monitoring-System

   Tabellenverzeichnis

   5-1. Die USE_*-Varibalen

   5-2. 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 KDE benutzen

   6-8. Variablen fu:r Ports, die Qt beno:tigen

   6-9. Zusa:tzliche Variablen fu:r Ports, die Qt 4.xi benutzen

   6-10. Verfu:gbare Qt4-Bibliothekskomponenten

   6-11. Verfu:gbare Qt4-Tool-Komponenten

   6-12. Verfu:gbare Qt4-Plugin-Komponenten

   6-13. Variablen, die von Ports, die Java benutzen, gesetzt werden
   mu:ssen

   6-14. Bereitgestellte Variablen fu:r Ports, die Java benutzen

   6-15. Konstanten, die fu:r Ports, welche Java benutzen, definiert
   sind

   6-16. Variablen fu:r Ports, die Apache verwenden

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

   6-18. Variablen fu:r Ports, die PHP verwenden

   6-19. Nu:tzliche Variablen fu:r Ports, die Python verwenden

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

   6-21. Nu:tzliche Variablen fu:r Ports, die Ruby verwenden

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

   6-23. Variablen, um die wxWidgets-Version festzulegen

   6-24. Verfu:gbare wxWidgets-Versionen

   6-25. Spezifikationen der wxWidgets-Versionen

   6-26. Variablen zur Festlegung der bevorzugten wxWidgets-Version

   6-27. Verfu:gbare wxWidgets-Komponenten

   6-28. Verfu:gbare Typen von wxWidgets-Abha:ngigkeiten

   6-29. Standardtypen der wxWidgets-Abha:ngigkeiten

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

   6-31. Vordefinierte Variablen fu:r Ports, die wxWidgets verwenden

   6-32. Zula:ssige Werte fu:r WX_CONF_ARGS

   6-33. Variablen, um die Lua-Version festzulegen

   6-34. Verfu:gbare Lua-Versionen

   6-35. Spezifikationen der Lua-Versionen

   6-36. Variablen zur Festlegung der bevorzugten Lua-Version

   6-37. Verfu:gbare Lua-Komponenten

   6-38. Verfu:gbare Typen von Lua-Abha:ngigkeiten

   6-39. Standardtypen fu:r Lua-Abha:ngigkeiten

   6-40. Vordefinierte Variablen fu:r Ports, die Lua verwenden

   6-41. Variablen fu:r Ports, die Datenbanken benutzen

   12-1. __FreeBSD_version-Werte

   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. Beispiel eines Makefiles fu:r eine PEAR Klasse

   6-5. Auswahl von wxWidgets-Komponenten

   6-6. Installierte wxWidgets-Versionen und -Komponenten feststellen

   6-7. Verwendung von wxWidgets-Variablen in Kommandos

   6-8. Auswahl der Lua-Version

   6-9. Auswahl von Lua-Komponenten

   6-10. Installierte Lua-Versionen und- Komponenten feststellen

   6-11. Einem Port mitteilen, in welchem Verzeichnis Lua liegt

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

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

               Kapitel 3. Port erstellen auf die Schnelle

   Dieser Abschnitt beschreibt, wie Sie schnell einen 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.

   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 Port einreichen

   Als Erstes sorgen Sie bitte dafu:r, dass Sie den Abschnitt DOs and
   DON'Ts gelesen haben.

   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. Als
   Na:chstes fu:gen Sie bitte einfach die Ausgabe von shar `find
   port_dir` in einen Fehlerbericht (PR - Problem Report) und senden
   diesen mittels 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 das Shar
   (Shell-Archiv) in das ``Fix''-Feld ein.

     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 und ``Update Port: <Kategorie>/<Portname>
     <Kurzbeschreibung des Updates>'' fu:r Portupdates. 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.

   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 Ports, 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

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

   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)

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

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

   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

   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 editors/vim5 und editors/vim-Ports und die
   www/apache*-Familie. 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 verwandt werden diese im
       Format yyyy.mm.dd und nicht dd.mm.yyyy oder gar dem nicht
       Y2K-kompatiblen Format yy.mm.dd vorliegen.

   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 (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  
              Emulatoren fu:r andere        geho:ren zu x11 und          
emulators     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    
ftp           FTP Client- und               als 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   
                                            direkt nur mit der           
java          Software fu:r die             Programmiersprache           
              Java-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,  
misc          Verschiedene Werkzeuge.       falls irgend 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, mbone, news, security oder www passt, da net
       stillschweigend eingeschlossen ist in diesen Kategorien.

     * 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
   X-contrib, 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_XCONTRIB, 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_XCONTRIB}
 MASTER_SITE_SUBDIR=   applications

   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.

   Der Nutzer kann ebenfalls die Variable MASTER_SITE_* in der
   /etc/make.conf setzen. Dadurch werden unsere Vorgaben
   u:berschrieben und stattdessen werden die Spiegel-Server seiner
   Wahl fu:r die popula:ren Archive genutzt.

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

  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.

   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.

   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 als auch
            Beispiel 5-4.

            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.

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

          * 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 iii.ii 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 mit einem 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 sie den Nutzern als einzeilige Zusammenfassung
   des Ports angezeigt wird.

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

5.7. Abha:ngigkeiten (dependencies)

   Viele Ports ha:ngen von anderen Ports ab. Es gibt sieben
   Variablen, welche Sie benutzen 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.

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

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

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

   Tabelle 5-1. 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              
   USE_CDRTOOLS sysutils/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.2. Mit 3.2+ kann die          
   USE_GCC      mindestens erforderliche 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 beschrieben, wa:hrenddessen autoconf, automake und
   libtool in Abschnitt 6.4 beschrieben sind. Perl-spezifische
   Variablen werden in Abschnitt 6.6 behandelt. X11-Variablen sind
   aufgelistet in Abschnitt 6.7. Abschnitt 6.8 behandelt
   GNOME-bezogene Variablen und Abschnitt 6.9 KDE-bezogene Variablen.
   Abschnitt 6.10 dokumentiert Java-Variablen, wa:hrend Abschnitt
   6.11Informationen zu Apache, PHP und PEAR-Modulen entha:lt. Python
   wird in Abschnitt 6.12 und Ruby in Abschnitt 6.15 ero:rtert.
   Abschnitt 6.16 stellt Variablen fu:r SDL-Programme zur Verfu:gung
   und Abschnitt 6.19 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
   NOMANCOMPRESS 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 NOMANCOMPRESS 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
   MANPREFIX 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/gcc33 Info-Dateien nach PREFIX/INFO_PATH/gcc33,
   wobei INFO etwa so aussieht:

 INFO= gcc33/cpp gcc33/cppinternals gcc33/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-2. 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              
   WITHOUT_X11       normalerweise mit 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. CONFLICTS

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

     Anmerkung: CONFLICTS setzt automatisch die Variable IGNORE,
     welche ausfu:hrlicher in Abschnitt 12.15dokumentiert ist.

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

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

   Wenn Sie eine Datei strippen mu:ssen, aber nicht das
   INSTALL_PROGRAM-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

   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/mozilla 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.               
                    Ersetzt das Standard-Konfigurations-Target.       
   CONFIGURE_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 nachinstalliert u:ber einen       
   PERL            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                                              
   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,
   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.                    
                Soll nicht mehr benutzt werden, ist jetzt a:quivalent 
   USE_X_PREFIX 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       
   X_IMAKE_PORT           Werkzeuge, 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 KDE

  6.9.1. Variablen-Definitionen

   Tabelle 6-7. Variablen fu:r Ports, die KDE benutzen

                   Der Port benutzt KDE-Bibliotheken. Die Variable    
                   spezifiziert die Major Version von KDE, die        
   USE_KDELIBS_VER 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 die Major Version von KDE, die        
   USE_KDEBASE_VER benutzt werden soll, und impliziert USE_QT_VER der 
                   entsprechenden Version. Der einzig mo:gliche Wert  
                   ist 3.                                             

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

  6.9.2. Ports, die Qt beno:tigen

   Tabelle 6-8. Variablen fu:r Ports, die Qt beno:tigen

                 Der Port benutzt das Qt-Toolkit. Mo:gliche Werte     
                 sind 3 und 4; diese spezifizieren die Major Version  
   USE_QT_VER    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 
   QTCPPFLAGS    an das Qt-Toolkit u:bergeben werden. Voreingestellt  
                 entsprechend des USE_QT_VER-Wertes.                  
                 Zusa:tzliche Bibliotheken, die u:ber CONFIGURE_ENV   
   QTCFGLIBS     fu:r das 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-9. 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 
   QMAKESPEC     (nur 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.3. 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-10. 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-11. 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           
   uic   Applikation von Qt-Designer erzeugte *.ui Dateien entha:lt - 
         gilt fu:r praktisch jede Qt-Applikation mit einer GUI)       

   Tabelle 6-12. 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.4. 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 Java

  6.10.1. Variablen-Definitionen

   Wenn Ihr Port ein Java(TM) Development Kit (JDK) 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/jdk15.

   Tabelle 6-13. 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.1[+] 1.2[+] 1.3[+] 1.4[+]).       
                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 ibm blackdown).                   
                Bedeutet, falls gesetzt, dass der ausgewa:hlte        
   JAVA_BUILD   JDK-Port zu den Build-Abha:ngigkeiten des Ports       
                hinzugefu:gt werden soll.                             
                Bedeutet, falls gesetzt, dass der ausgewa:hlte        
   JAVA_RUN     JDK-Port zu den Laufzeit-Abha:ngigkeiten des Ports    
                hinzugefu:gt werden soll.                             
                Bedeutet, falls gesetzt, dass der ausgewa:hlte        
   JAVA_EXTRACT JDK-Port zu den Extract-Abha:ngigkeiten des Ports     
                hinzugefu:gt werden soll.                             
                Legt fest, ob der Port den jikes Bytecode-Compiler    
                zum Kompilieren benutzen soll. Wenn kein Wert fu:r    
                diese Variable gesetzt ist, wird der Port jikes fu:r  
                die Kompilierung benutzen- falls vorhanden. Sie       
                ko:nnen die Benutzung von jikes auch ausdru:cklich    
   USE_JIKES    verbieten oder erzwingen (durch Setzen auf 'no' oder  
                'yes'). Im letzteren Fall wird devel/jikes zu den     
                Build-Abha:ngigkeiten des Ports hinzugefu:gt. In      
                jedem Fall wird, wenn jikes tatsa:chlich statt javac  
                zur Kompilierung benutzt wird, die Variable           
                HAVE_JIKES von bsd.java.mk definiert.                 

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

   Tabelle 6-14. Bereitgestellte Variablen fu:r Ports, die Java
   benutzen

          Variable                                   Wert                          
JAVA_PORT                    Der Name des JDK-Ports (z.B. 'java/jdk14').           
                             Die volle Version des JDK Ports (z.B. '1.4.2'). 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.        
                             'linux').                                             
JAVA_PORT_VENDOR             Der Anbieter des JDK-Ports (z.B. 'sun').              
JAVA_PORT_OS_DESCRIPTION     Beschreibung des vom JDK-Port benutzten               
                             Betriebssystems (z.B. 'Linux').                       
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/jdk1.3.1').                               
                             Pfad zum Java-Compiler, der benutzt werden soll (z.B. 
JAVAC                        '/usr/local/jdk1.1.8/bin/javac' oder                  
                             '/usr/local/bin/jikes').                              
                             Pfad zum jar-Werkzeug, das benutzt werden soll (z.B.  
JAR                          '/usr/local/jdk1.2.2/bin/jar' oder                    
                             '/usr/local/bin/fastjar').                            
APPLETVIEWER                 Pfad zum appletviewer-Werkzeug (z.B.                  
                             '/usr/local/linux-jdk1.2.2/bin/appletviewer').        
                             Pfad zur java Bina:rdatei. Benutzen Sie dies, um      
JAVA                         Java-Programme auszufu:hren (z.B.                     
                             '/usr/local/jdk1.3.1/bin/java').                      
JAVADOC                      Pfad zum javadoc-Werkzeug.                            
JAVAH                        Pfad zum javah-Programm.                              
JAVAP                        Pfad zum javap-Programm.                              
JAVA_KEYTOOL                 Pfad zum keytool-Werkzeug. Diese Variable ist nur     
                             verfu:gbar, wenn das JDK Java 1.2 oder ho:her ist.    
JAVA_N2A                     Pfad zum native2ascii-Werkzeug.                       
JAVA_POLICYTOOL              Pfad zum policytool Programm. Diese Variable ist nur  
                             verfu:gbar, wenn das JDK Java 1.2 oder ho:her ist.    
JAVA_SERIALVER               Pfad zum serialver-Werkzeug.                          
RMIC                         Pfad zum RMI Stub/Skeleton-Generator, rmic.           
RMIREGISTRY                  Pfad zum RMI Registry-Werkzeug, rmiregistry.          
                             Pfad zum RMI Daemon rmid. Diese Variable ist nur      
RMID                         verfu:gbar, wenn das JDK Java 1.2 oder ho:her         
                             unterstu:tzt.                                         
                             Pfad zum Archiv, das die JDK-Klassendateien entha:lt. 
JAVA_CLASSES                 Fu:r das JDK 1.2 oder spa:ter ist dies                
                             ${JAVA_HOME}/jre/lib/rt.jar. Fru:here JDKs benutzten  
                             ${JAVA_HOME}/lib/classes.zip.                         
HAVE_JIKES                   Ist dann gesetzt, wenn jikes vom Port benutzt wird    
                             (s. USE_JIKES oben).                                  

   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-15. 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  
   JAVALIBDIR   Ports installiert wurden, liegen. Standardma:ssig     
                ${LOCALBASE}/share/java/classes.                      

   Die entsprechenden Eintra:ge sind sowohl in PLIST_SUB
   (dokumentiert in Abschnitt 7.1) als auch in SUB_LIST definiert.

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

  6.10.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_TARGETS aufruft. Das a:hnelt dem
   USE_GMAKE-Mechanismus, der in Abschnitt 6.3 dokumentiert ist.

   Wenn jikes anstelle von javac benutzt wird (siehe USE_JIKES in
   Abschnitt 6.10.1), dann wird Ant es automatisch benutzen, um den
   Port zu kompilieren.

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

  6.10.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)
   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 erkla:rt wird.

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

6.11. Webanwendungen, Apache und PHP

  6.11.1. Apache

   Tabelle 6-16. 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 
   WITH_APACHE2     nicht 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 (nur lesbare Variable).      
   APACHE_VERSION   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.   
                    Verzeichnis der Apache-Konfigurationsdateien.     
   APACHEETCDIR     Diese Variable wird automatisch in pkg-plist      
                    ersetzt.                                          

   Tabelle 6-17. 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.11.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.11.3. PHP

   Tabelle 6-18. 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.11.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-4. 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.12. 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-19. 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 werden. Bereiche von        
   USE_PYTHON              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 
   USE_PYDISTUTILS         der Port eine setup.py-Datei 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       
   PYTHON_PKGNAMEPREFIX    Pakete fu:r 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      
   PYTHONPREFIX_SITELIBDIR %%PYTHON_SITELIBDIR%% in 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    
   PYNUMPY                 numerische Erweiterung numpy. (PYNUMERIC   
                           ist vom Anbieter als veraltet deklariert)  
                           Liste der Abha:ngigkeiten fu:r             
   PYXML                   XML-Erweiterungen (wird ab Python 2.0      
                           nicht mehr beno:tigt, da im Basispaket     
                           enthalten).                                
                           Setzt die Abha:ngigkeit des Ports von      
   USE_TWISTED             twistedCore. 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      
   USE_ZOPE                Ports. Setzt die 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.13. 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-20. 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   
   USE_TCL               kann mit 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 neue Variable verwenden. Ein   
   USE_TCL_WRAPPER       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  
   USE_TK                die 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.         
                         Analog zur Variable WITH_TCL_VER und         
   WITH_TK_VER           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.14. Emacs benutzen

   Dieser Abschnitt muss noch geschrieben werden.

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

6.15. Ruby benutzen

   Tabelle 6-21. 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-22. 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.16. 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.17. wxWidgets verwenden

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

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

  6.17.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.17.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-23. Variablen, um die wxWidgets-Version festzulegen

    Variable              Beschreibung                Standardwert    
   USE_WX     Liste der Versionen, die der Port     Alle verfu:gbaren 
              verwenden kann                        Versionen         
   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-24. 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.17.4).

   Die Variablen in Tabelle 6-23 ko:nnen auf einen oder mehrere
   (durch Leerzeichen getrennt) der folgenden Werte gesetzt werden:

   Tabelle 6-25. 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-26. Variablen zur Festlegung der bevorzugten
   wxWidgets-Version

      Name     Bestimmt fu:r 
   WANT_WX_VER den Port      
   WITH_WX_VER den Benutzer  

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

  6.17.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-27. 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-29). Die folgenden Typen sind
   verfu:gbar:

   Tabelle 6-28. 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-29. Standardtypen der wxWidgets-Abha:ngigkeiten

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

   Beispiel 6-5. 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.17.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-30. Variablen, um Unicode in den wxWidgets-Versionen
   auszuwa:hlen

      Variable                 Beschreibung             Bestimmt fu:r 
                   Der Port funktioniert                              
   WX_UNICODE      ausschliesslich mit der              den Port
                   Unicode-Version                      
                   Der Port funktioniert in beiden                    
   WANT_UNICODE    Versionen - bevorzugt wird jedoch    den Port
                   Unicode                              
   WITH_UNICODE    Der Port verwendet die               den Benutzer  
                   Unicode-Version                      
                   Der Port verwendet, falls                          
   WITHOUT_UNICODE unterstu:tzt, die normale Version    den Benutzer
                   (falls WX_UNICODE nicht 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.17.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-6. 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.17.6. Vordefinierte Variablen

   Die folgenden Variablen sind in den Ports verfu:gbar (nachdem sie
   entsprechend Tabelle 6-23 definiert wurden).

   Tabelle 6-31. 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        
   WX_UNICODE definiert, jedoch verwendet wird, dann wird die         
              Unterstu:tzung automatisch aktiviert.                   

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

  6.17.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-7. 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.17.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-32. 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.18. Verwendung von Lua

   Dieser Abschnitt beschreibt den Status der Lua-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 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.18.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-33. 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    Nichts            
               nicht verwenden kann                 

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

   Tabelle 6-34. Verfu:gbare Lua-Versionen

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

   Die Variablen in Tabelle 6-33 ko:nnen auf einen oder mehrere
   (durch Leerzeichen getrennt) der folgenden Werte gesetzt werden:

   Tabelle 6-35. 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-36. Variablen zur Festlegung der bevorzugten Lua-Version

       Name     Bestimmt fu:r 
   WANT_LUA_VER den Port      
   WITH_LUA_VER den Benutzer  

   Beispiel 6-8. 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.18.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-37. Verfu:gbare Lua-Komponenten

   Name             Beschreibung             Versionseinschra:nkungen 
   lua   Hauptbibliothek                     Keine                    
   tolua Bibliothek fu:r die Unterstu:tzung  4.0-5.0                  
         von 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-39). Die folgenden Typen sind
   verfu:gbar:

   Tabelle 6-38. 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-39. 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-9. 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.18.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-10. 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.18.5. Vordefinierte Variablen

   Die folgenden Variablen sind in den Ports verfu:gbar (nachdem sie
   entsprechend Tabelle 6-33 definiert wurden).

   Tabelle 6-40. 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                                  
                     Das Verzeichnis unter ${PREFIX}/bin,             
   LUA_SUBDIR        ${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-11. 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.18.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-12. 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.19. 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.20. Benutzung von Datenbanken

   Tabelle 6-41. 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 annehmen: 2, 3, 40, 41, 42, 43, 
   USE_BDB   44, 45, 46 oder 47. 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/mysql50-server als Abha:ngigkeit hinzu. Die    
             damit verknu:pfte Variable WANT_MYSQL_VER kann Werte wie 
             323, 40, 41, 50, 51 oder 60 annehmen.                    
             Falls die Variable auf yes gesetzt ist, fu:ge eine       
   USE_PGSQL Abha:ngigkeit von databases/postgresql82 hinzu. Die      
             damit verknu:pfte Variable WANT_MYSQL_VER kann Werte wie 
             73, 74, 80, 81, 82 oder 83 annehmen.                     

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

6.21. 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-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. Der einzige
   Unterschied zu einem rc.d-Skript aus dem Basissystem ist, dass die
   Zeile . /etc/rc.subr in . %%RC_SUBR%% umbenannt werden muss, da
   a:ltere Versionen von FreeBSD die Datei /etc/rc.subr nicht
   besitzen. Standarderweiterungen wie SUB_LIST werden ebenfalls
   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 wird
   aber nicht mehr empfohlen.

   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

 # PROVIDE: doormand
 # REQUIRE: LOGIN
 #
 # 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.
 #

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

   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.

   Der Suffix des rc-Skriptes wird durch RC_SUBR_SUFFIX fu:r die
   weitere Verwendung im Makefile des Ports bereitgestellt. Aktuelle
   Versionen von FreeBSD fu:gen keinen Suffix den Skriptnamen hinzu
   im Gegensatz zu a:ltere Versionen, die dies mit dem Suffix .sh
   taten.

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

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

             Kapitel 7. Fortgeschrittene pkg-plist-Methoden

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.

   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

   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

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

   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. Benutzer ko:nnen
   PREFIX setzen, wie sie wollen. 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 Port aktualisieren

   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. Bitte fu:hren Sie die A:nderungen durch und
   speichern Sie die Ausgabe des rekursiven diff des neuen und alten
   Portverzeichnisses (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. 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 2000 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.

   Nun, da Sie all das geschafft haben, werden Sie in Kapitel 14
   nachlesen ko:nnen, wie Sie den Port aktuell halten.

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

                    Kapitel 11. Sicherheit der Ports

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.

   In Ordnung, Sie haben sich also fu:r den schwierigen Weg
   entschieden. Wie vielleicht aus dem Titel hervorgeht, ist die
   VuXMl-Datenbank hauptsa:chlich 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</entry> (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. Wahlweise
           ko:nnen Sie, wenn Sie FreeBSD 4.x verwenden, den Port
           devel/p5-Data-UUID verwenden und folgenden Befehl
           aufrufen:

 perl -MData::UUID -le 'print lc new Data::UUID->create_str'

   (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 sollten Sie eine neue Version der Ports
   ports-mgmt/portaudit und ports-mgmt/portaudit-db installieren.

   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

     Anmerkung: Um packaudit auszufu:hren, mu:ssen Sie die
     Berechtigung haben DATABASEDIR zu schreiben - u:blicherweise ist
     das /var/db/portaudit.

   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

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).                  
                                 4.0-CURRENT nach suser(9) API        
   400005     27. April 1999     A:nderung (auch 4.0-CURRENT nach     
                                 newbus).                             
   400006     31. Mai 1999       4.0-CURRENT nach A:nderung der       
                                 cdevsw-Registrierung.                
                                 4.0-CURRENT nach Hinzufu:gen von     
   400007     17. Juni 1999      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.    
                                 4.0-CURRENT nach der A:nderung des   
   400009     20. Juli 1999      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.                     
                                 4.0-CURRENT nach Hinzufu:gen der     
   400013     4. Dezember 1999   erweiterbaren Linux Mode             
                                 ioctl-Routinen.                      
   400014     18. Januar 2000    4.0-CURRENT nach dem OpenSSL-Import. 
                                 4.0-CURRENT nach der C++ ABI         
   400015     27. Januar 2000    A:nderung in 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   
   400021     8. Juli 2000       von 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          
                                 4.1-STABLE nachdem setproctitle(3)   
   410002     16. September 2000 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       
   420001     10. Januar 2001    libgcc.a und 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).           
                                 4.4-STABLE nachdem die               
   440003     18. Dezember 2001  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               
   450004     16. April 2002     sendmail_enable rc.conf(5) Variable  
                                 gea:ndert worden ist, um den Wert    
                                 NONE zu akzeptieren.                 
                                 4.5-STABLE nachdem XFree86 4 als     
   450005     27. April 2002     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 mehr    
   460001     21. Juni 2002      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 neuen pkg_install-Funktionen  
   460102     1. September 2002  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 Referenzen statt  
   470101     10. November 2002  __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                           
                                 4.9-STABLE nachdem e_sid zu der      
   490101     8. Januar 2004     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  
   491102     16. November 2004  in der 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     
                                 zusa:tzlichen Feldern in den         
   500001     18. April 2000     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 
   500005     3. Juni 2000       libxpg4 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.          
                                 5.0-CURRENT nach der Aktualisierung  
   500008     7. Juli 2000       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 zuru:ck zur          
   500010     16. Juli 2000      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.                
                                 5.0-CURRENT nachdem setproctitle(3)  
   500012     2. September 2000  von libutil nach libc verschoben     
                                 worden ist.                          
   500013     10. September 2000 5.0-CURRENT nach dem ersten          
                                 SMPng-Commit.                        
                                 5.0-CURRENT nachdem <sys/select.h>   
   500014     4. Januar 2001     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  
   500017     18. Februar 2001   struct 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 
   500018     24. Februar 2001   CPUTYPE 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.  
                                 5.0-CURRENT nach d_thread_t, und     
   500024     1. Oktober 2001    nachdem UUCP in die Ports verschoben 
                                 worden ist.                          
                                 5.0-CURRENT nach A:nderungen in der  
   500025     4. Oktober 2001    ABI bei der Weitergabe von           
                                 Deskriptoren und Berechtigungen auf  
                                 64 Bit Plattformen.                  
                                 5.0-CURRENT nachdem XFree86 4 als    
                                 Standard zum Erstellen der Pakete    
   500026     9. Oktober 2001    benutzt wird und die neue libc       
                                 strnstr()-Funktion hinzugefu:gt      
                                 wurde.                               
                                 5.0-CURRENT nachdem die neue libc    
   500027     10. Oktober 2001   strcasestr()-Funktion hinzugefu:gt   
                                 wurde.                               
                                 5.0-CURRENT nachdem die              
   500028     14. Dezember 2001  Userland-Komponenten von smbfs       
                                 importiert wurden.                   
   (nicht                        5.0-CURRENT nachdem die neuen        
   gea:ndert)                    C99-Ganzzahlen mit spezifischer      
                                 Breite hinzugefu:gt wurden.          
                                 5.0-CURRENT nachdem eine A:nderung   
   500029     29. Januar 2002    im Ru:ckgabewert von sendfile(2)     
                                 gemacht wurde.                       
                                 5.0-CURRENT nach der Einfu:hrung des 
   500030     15. Februar 2002   Types 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              
   500033     3. April 2002      sendmail_enable 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 Elementen der                
   500038     24. Juli 2002      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       
   500039     1. September 2002  _FOO_T_DECLARED 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 an Plattenfunktionen     
   500040     20. September 2002 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  
   500042     15. Oktober 2002   von Binutils auf 2.13, bei denen die 
                                 FreeBSD-Emulation, vec und das       
                                 Ausgabeformat gea:ndert wurden.      
                                 5.0-CURRENT nach dem Hinzufu:gen     
   500043     1. November 2002   schwacher 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 wurde, um ohne Giant zu     
   500103     26. Februar 2003   arbeiten, und taskqueue_swi_giant    
                                 hinzugefu:gt wurde, um Giant zu      
                                 verwenden.                           
                                 cdevsw_add() und cdevsw_remove()     
   500104     27. Februar 2003   gibt es 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       
   501105     17. August 2003    dynamisch gebundenen /bin und /sbin  
                                 und Verschieben von Bibliotheken     
                                 nach /lib.                           
                                 5.1-CURRENT nachdem im Kernel        
   501106     8. September 2003  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              
   501110     28. September 2003 standardma:ssige 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      
                                 5.1-CURRENT nachdem /bin und /sbin   
   501114     16. November 2003  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              
   502102     30. Januar 2004    Standard-Thread Bibliothek von       
                                 libc_r zu libpthread gea:ndert       
                                 wurde.                               
   502103     21. Februar 2004   5.2-CURRENT nach dem Gera:tetreiber  
                                 API Megapatch.                       
                                 5.2-CURRENT nachdem                  
   502104     25. Februar 2004   getopt_long_only() hinzugefu:gt      
                                 wurde.                               
                                 5.2-CURRENT nachdem NULL fu:r C in   
   502105     5. Ma:rz 2004      ((void *)0) gea:ndert wurde, was     
                                 mehr Warnungen erzeugt.              
                                 5.2-CURRENT nachdem pf beim Bauen    
   502106     8. Ma:rz 2004      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 fu:r den Intel        
   502108     12. Ma:rz 2004     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()       
   502113     4. Juni 2004       zwingend 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) gea:ndert wurde, 0 
   502115     14. Juni 2004      bei Erfolg und einen von 0           
                                 verschiedenen Fehlercode im Falle    
                                 eines Fehlers zuru:ckzuliefern.      
                                 5.2-CURRENT nach dem A:ndern der     
   502116     16. Juni 2004      Kernel 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   
   502118     17. Juni 2004      fu:r CLOCK_VIRTUAL und CLOCK_PROF zu 
                                 clock_gettime(2) und clock_getres(2) 
                                 hinzugefu:gt wurde.                  
                                 5.2-CURRENT nachdem die              
   502119     22. Juni 2004      U:berpru:fung des Klonens von        
                                 Netzwerk-Schnittstellen gea:ndert    
                                 wurde.                               
                                 5.2-CURRENT nach dem Einfliessen von 
   502120     2. Juli 2004       Revision 20040629 der                
                                 Paket-Werkzeuge.                     
                                 5.2-CURRENT nachdem                  
   502121     9. Juli 2004       Bluetooth-Quelltext als nicht        
                                 i386-spezifisch markiert wurde.      
                                 5.2-CURRENT nach der Einfu:hrung des 
                                 KDB Debugger Frameworks, der         
   502122     11. Juli 2004      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 kinfo_proc  
   502123     12. Juli 2004      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      
   502124     24. Juli 2004      Weise, wie rc.d-Skripte von Ports    
                                 und Altlasten gestartet werden,      
                                 getrennt wurde.                      
                                 5.2-CURRENT nachdem die vorherige    
   502125     28. Juli 2004      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 gea:ndert wurde, um              
   502127     2. August 2004     Konstruktoren und                    
                                 Initialisierungsmethoden zu erlauben 
                                 fehlzuschlagen.                      
                                 5.2-CURRENT nach der A:nderung in    
                                 der vfs_mount Signatur sowie         
   502128     8. August 2004     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 A:nderung aus CURRENT in         
   503104     28. Februar 2005   ifi_epoch statt der lokalen Zeit die 
                                 Betriebszeit des Systems zu          
                                 benutzen.                            
                                 5.4-PRERELEASE nach dem Einfliessen  
   503105     2. Ma:rz 2005      der 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.                  
                                 5.4-STABLE nach dem Vergro:ssern der 
   504101     11. Mai 2005       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                          
                                 6.0-CURRENT nach der festen          
   600001     27. August 2004    Aktivierung von PFIL_HOOKS im        
                                 Kernel.                              
                                 6.0-CURRENT nach der anfa:nglichen   
                                 Einfu:hrung von ifi_epoch zur        
   600002     30. August 2004    Struktur if_data. Wurde nach ein     
                                 paar Tagen wieder ru:ckga:ngig       
                                 gemacht. Benutzen Sie diesen Wert    
                                 bitte nicht.                         
                                 6.0-CURRENT nach dem erneuten        
   600003     8. September 2004  Hinzufu:gen des Elements ifi_epoch   
                                 zur Struktur if_data.                
                                 6.0-CURRENT nach dem Hinzufu:gen der 
   600004     29. September 2004 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() Funktionen und        
   600008     25. Januar 2005    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.                      
                                 6.0-CURRENT nach dem Vergro:ssern    
   600012     15. Februar 2005   der standardma:ssigen Stackgro:sse   
                                 fu:r Threads.                        
                                 6.0-CURRENT nach dem Einfliessen der 
                                 Reparaturen in                       
   600013     19. 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.         
                                 6.0-CURRENT nachdem die              
   600014     21. Februar 2005   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.                 
                                 6.0-CURRENT nachdem das Format von   
   600016     26. Februar 2005   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.                            
                                 Die Optionen LOCAL_CREDS,            
   600023     13. April 2005     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.                         
                                 POSIX ttyname_r(3) wurde u:ber       
   600028     13. Mai 2005       unistd.h und libc zur Verfu:gung     
                                 gestellt.                            
                                 6.0-CURRENT nachdem libpcap zu       
   600029     29. Mai 2005       Version v0.9.1 alpha 096             
                                 aktualisiert wurde.                  
   600030     5. Juni 2005       6.0-CURRENT nach dem Import von      
                                 NetBSDs if_bridge(4).                
                                 6.0-CURRENT nachdem die Struktur     
   600031     10. Juni 2005      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 gemeinsam genutzten            
   600033     25. Juli 2005      Bibliotheken, welche seit RELENG_5   
                                 nicht gea:ndert wurden, erho:ht      
                                 wurden.                              
                                 6.0-STABLE nachdem das Argument      
   600034     13. August 2005    credential 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    
   600101     21. Dezember 2005  Skripten 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.                         
                                 6.0-STABLE nach der                  
   600105     26. Februar 2006   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   
   601103     17. Juli 2006      der Namensauflo:sung zu BIND9 und    
                                 Aufnahme der ablaufinvarianten       
                                 Versionen der netdb-Funktionen.      
                                 6.1-STABLE nachdem Unterstu:tzung    
   601104     8. August 2006     fu:r DSO (dynamic shared objects -   
                                 gemeinsam genutzte, dynamische       
                                 Objekte) in OpenSSL aktiviert wurde. 
                                 6.1-STABLE nachdem 802.11            
   601105     2. September 2006  Reparaturen die 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     
   602103     16. Januar 2007    angefordertes 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)        
   602104     28. Januar 2007    netgraph Knoten und neuen            
                                 Kompressions- und                    
                                 -Verschlu:sselungmodi fu:r den       
                                 ng_ppp(4) Knoten aus CURRENT.        
                                 6.2-STABLE nach dem Einpflegen der   
   602105     20. Februar 2007   BSD lizensierten Version von         
                                 gzip(1), welche von NetBSD portiert  
                                 wurde aus CURRENT.                   
                                 6.2-STABLE nach dem Einpflegen der   
   602106     31. Ma:rz 2007     PCI MSI und MSI-X Unterstu:tzung aus 
                                 CURRENT.                             
                                 6.2-STABLE nach dem Einpflegen von   
   602107     6. April 2007      ncurses 5.6 und Unterstu:tzung fu:r  
                                 Multibyte-Zeichen aus CURRENT.       
                                 6.2-STABLE nach dem Einpflegen des   
                                 'SG' Peripheriegera:tes aus CURRENT  
   602108     11. April 2007     in CAM, welches einen Teil der SCSI  
                                 SG passthrough Gera:te API von Linux 
                                 entha:lt.                            
                                 6.2-STABLE nach dem Einpflegen von   
   602109     17. April 2007     readline 5.2 Patchset 002 aus        
                                 CURRENT.                             
                                 6.2-STABLE nach dem Einpflegen von   
                                 pmap_invalidate_cache(),             
   602110     2. Mai 2007        pmap_change_attr(), 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 Bina:rdateien, die       
   602113     25. Oktober 2007   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 
   603101     7. Dezember 2007   den 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 gemeinsam genutzten            
   700001     23. Juli 2005      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)       
   700004     30. Oktober 2005   modifiziert wurden, um einen         
                                 Backlog-Parameter (Anzahl der        
                                 maximalen wartenden Verbindungen) zu 
                                 akzeptieren.                         
                                 7.0-CURRENT nachdem IFP2ENADDR()     
   700005     11. November 2005  gea:ndert 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   
   700007     2. Dezember 2005   Skripten 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.              
                                 7.0-CURRENT nach ELF-64 Typen        
   700009     19. Dezember 2005  A:nderungen und Symbol               
                                 Versionierung.                       
                                 7.0-CURRENT nach Hinzufu:gen der     
                                 hostb und vgapci Treiber,            
   700010     20. Dezember 2005  Hinzufu:gen von pci_find_extcap()    
                                 und A:nderung der AGP Treiber die    
                                 Apertur nicht la:nger abzubilden.    
                                 7.0-CURRENT nachdem auf allen        
   700011     31. Dezember 2005  Plattformen 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 um                     
   700013     12. Januar 2006    /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 angefordertes Symbol  
   700022     9. September 2006  sowohl in der spezifizierten dso,    
                                 als auch in den impliziten           
                                 Abha:ngigkeiten nachzuschlagen.      
                                 7.0-CURRENT nach dem Hinzufu:gen     
   700023     23. September 2006 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    
   700029     26. Januar 2007    GNU gzip(1) durch eine von NetBSD    
                                 portierte Version, die unter         
                                 BSD-Lizenz steht.                    
                                 7.0-CURRENT nach dem Entfernen der   
   700030     7. Februar 2007    IPIP 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' Peripheriegera:tes in CAM,      
   700037     8. April 2007      welches einen Teil der SCSI SG       
                                 passthrough Gera:te API von Linux    
                                 entha:lt.                            
                                 7.0-CURRENT nachdem getenv(3),       
   700038     30. April 2007     putenv(3), setenv(3) und unsetenv(3) 
                                 gea:ndert wurden, um POSIX konform   
                                 zu sein.                             
                                 7.0-CURRENT nachdem die A:nderungen  
   700039     1. Mai 2007        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           
   700041     13. Mai 2007       Versionierung 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    
   700043     21. Mai 2007       aller Shared-Libraries, welche seit  
                                 RELENG_6 nicht gea:ndert wurden,     
                                 erho:ht worden sind.                 
                                 7.0-CURRENT nachdem das Argument     
   700044     7. Juni 2007       fu:r vn_open()/VOP_OPEN() vom        
                                 Dateideskriptorindex zur Struktur    
                                 file * gea:dert wurde.               
                                 7.0-CURRENT nachdem pam_nologin(8)   
                                 gea:dert wurde, eine                 
   700045     10. Juni 2007      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       
                                 RFC 1724-Verhalten des               
   700048     12. Juni 2007      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         
                                 7.0-CURRENT, nachdem die             
   (nicht                        IPv6-Unterstu:tzung um FAST_IPSEC    
   gea:ndert)                    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.       
                                 7.0-CURRENT, nachdem neue            
   700051     4. Juli 2007       Systemaufrufe (mmap/lseek/usw.)      
                                 implementiert wurden.                
   700052     6. Juli 2007       7.0-CURRENT, nachdem die I4B-Header  
                                 nach include/i4b verschoben wurden.  
                                 7.0-CURRENT, nachdem die             
   700053     30. September 2007 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          
   700055     28. Oktober 2007   PCIOCGETCONF-, 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.                       
                                 7.0-STABLE nach Hinzufu:gen der      
   700106     15. April 2008     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  
   700108     5. Mai 2008        an 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 
   701104     14. Februar 2009   Suspend 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                  
   701105     12. Ma:rz 2009     kern.ipc.shmsegs, um die 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 
   702101     15. Mai 2009       links-ausgerichtete Adressierung von 
                                 Slaves verwendet, um anderen         
                                 SMBus-Kontrollertreibern zu          
                                 entsprechen.                         
   702102     28. Mai 2009       7.2-STABLE nach dem Einfliessen der  
                                 Funktion fdopendir.                  
   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                 
   800002     21. Oktober 2007   kthread_create() und 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          
   800003     24. Oktober 2007   PCIOCGETCONF-, 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)      
   800004     12. November 2007  Treiber 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    
   800006     7. Dezember 2007   der 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     
   800017     6. Februar 2008    Optionen 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   
   800019     9. Februar 2008    Arbeits-, Wurzel- und                
                                 Jailverzeichnisunterstu:tzung zur    
                                 sysctl-Variable kern.proc.filedesc.  
                                 8.0-CURRENT nach Einfu:hrung der     
   800020     13. Februar 2008   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           
   800024     1. Ma:rz 2008      BUF_LOCKWAITERS, A:nderung 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       
   800026     12. Ma:rz 2008     Parameters 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 
   800029     28. Ma:rz 2008     der Funktion BUF_LOCKWAITERS und     
                                 Hinzufu:gen von lockmgr_waiters(9).  
                                 8.0-CURRENT nach Einfu:hrung der     
   800030     1. April 2008      Funktionen rw_try_rlock(9) und       
                                 rw_try_wlock(9).                     
                                 8.0-CURRENT nach Einfu:hrung der     
   800031     6. April 2008      Funktionen lockmgr_rw und            
                                 lockmgr_args_rw.                     
                                 8.0-CURRENT nach Implementierung des 
                                 Systemaufrufs openat und seiner      
                                 Verwandten, Einfu:hrung der Option   
   800032     8. April 2008      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   
   800033     8. April 2008      nativen 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      
   800036     20. April 2008     Standards 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)).               
   800038     26. Mai 2008       8.0-CURRENT nach Entfernen von       
                                 netatm und ISDN4BSD.                 
   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.   
                                 8.0-CURRENT nach Hinzufu:gen von     
   800041     22. Juli 2008      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       
   800043     13. August 2008    bpf(4) zur Verwendung einer          
                                 einzelnen Gera:tedatei anstatt von   
                                 Klonierung.                          
                                 8.0-CURRENT nach U:bernahme des      
                                 ersten Teils aus dem vimage-Projekt  
                                 durch Erweitern globaler Variablen   
   800044     17. August 2008    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   
                                 MPSAFE TTY-Layers, einschliesslich   
   800045     20. August 2008    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        
   800048     16. September 2008 einzelne 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     
   800052     28. Oktober 2008   accmode_t und Umbennung des          
                                 Parameters a_mode an VOP_ACCESS nach 
                                 a_accmode.                           
                                 8.0-CURRENT nach A:nderung des       
   800053     2. November 2008   Prototyps von 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           
                                 Hardwareebene fu:r Karten zu         
   800054     22. November 2008  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     
   800056     29. November 2008  Jails mit 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.       
                                 8.0-CURRENT nach Entfernen von       
   800062     28. Januar 2009    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).                         
                                 8.0-CURRENT, nachdem der USB2-Stack  
   800064     23. Februar 2009   nach dev/usb verschoben wurde, um es 
                                 zu ersetzen.                         
   800065     26. Februar 2009   8.0-CURRENT nach Umbenennen aller    
                                 Funktionen in libmp(3).              
                                 8.0-CURRENT nach Anpassung des       
   800066     27. Februar 2009   devfs-Verhaltens im Zusammenhang mit 
                                 USB.                                 
                                 8.0-CURRENT nach Hinzufu:gen von     
   800067     28. Februar 2009   getdelim(), 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 
   800070     9. Ma:rz 2009      IGMPv3 und                           
                                 Source-Specific-Multicast (SSM) in   
                                 den IPv4-Stack.                      
                                 8.0-CURRENT nach der Anpassung von   
   800071     14. Ma:rz 2009     gcc zur Verwendung der               
                                 C99-Inline-Semantik in den Modi c99  
                                 und gnu99.                           
                                 8.0-CURRENT, nachdem die Option      
                                 IFF_NEEDSGIANT entfernt wurde;       
   800072     15. Ma:rz 2009     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             
   800075     6. April 2009      Deklarationen von 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.        
                                 8.0-CURRENT nach dem Entfernen von   
   800077     14. April 2009     VOP_LEASE() und                      
                                 vop_vector.vop_lease.                
                                 8.0-CURRENT, nachdem die Felder aus  
                                 struct rt_weight zu                  
                                 struct rt_metrics und                
   800078     15. April 2009     struct rt_metrics_lite hinzugefu:gt  
                                 wurden, 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 von struct ifnet und     
   800082     21. April 2009     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 des VFS entfernt.         
   800087     11. Mai 2009       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.               
                                 8.0-CURRENT nach dem Hinzufu:gen der 
   800089     23. Mai 2009       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 
   800092     29. Mai 2009       wurde 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. Die    
   800095     30. Mai 2009       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 netisr-Implementierung und       
   800096     1. Juni 2009       nachdem die Weise, wie FIBs          
                                 gespeichert werden und wie auf sie   
                                 zugegriffen wird, gea:ndert wurde.   

     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;         
   PORTOBJFORMAT beachten Sie, 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. UIDs und GIDs

   Die aktuellen Listen von reservierten UIDs und GIDs sind in
   ports/UIDs und ports/GIDs zu finden.

   Falls Ihr Port einen bestimmten Benutzer auf dem zu
   installierendem System beno:tigt, lassen Sie das
   pkg-install-Skript den Aufruf von pw machen, um ihn automatisch
   anzulegen. Schauen Sie sich fu:r ein Beispiel sysutils/symon an.
   Ihr Port muss eine feste Benutzer/Gruppen-ID verwenden. Sie
   mu:ssen eine nicht benutzte UID zwischen 50 und 999 benutzen und
   entweder in ports/UIDs (fu:r Benutzer) oder in ports/GIDs (fu:r
   Gruppen) registrieren.

   Stellen Sie sicher, dass Sie keine UIDs verwenden, welche schon
   vom System oder von einem anderen Port gebraucht werden.

   Bitte fu:gen Sie einen Patch fu:r diese beiden Datei hinzu, falls
   fu:r Ihren Port ein neuer Benutzer oder Gruppe angelegt werden
   muss.

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

12.9. 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.10. 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.11. 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.12. 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.13. 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.14. 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.15. 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.15.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.15.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.16. 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.17. 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). Jedoch
   schlagen auch trivialere Befehle wie make -V 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.18. 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.19. 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.20. Notwendige Abhilfen (Workarounds)

   Manchmal ist es no:tig Fehler in Programmen, die mit a:lteren
   Versionen von FreeBSD ausgeliefert werden, zu umgehen.

     * Einige Versionen von make(1) waren zumindest auf FreeBSD 4.8
       und 5.0 in Bezug auf die Behandlung von Vergleichen mit
       OSVERSION defekt. Dies fu:hrte ha:ufig zu Fehlern wa:hrend
       make describe (und damit auch wa:hrend des make index fu:r
       alle Ports). Abhilfe schafft hier, den bedingten Vergleich in
       Leerzeichen einzuschliessen, z.B.:

 if ( ${OSVERSION} > 500023
             )

       Beachten Sie, dass eine Test-Installation eines Ports auf 4.9
       oder 5.2 dieses Problem nicht aufspu:rt.

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

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

   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. Die FreeBSD Port-Distfile-Pru:fung

   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. Die FreeBSD Ports Distfiles Pru:fung 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.

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

   Fragen zum FreeBSD Ports-System richten Sie bitte an
   <ports@FreeBSD.org>, Fragen zu diesem Dokument hingegen an
   <de-bsd-translators@de.FreeBSD.org>.
