                      Das FreeBSD Porter-Handbuch

  The FreeBSD German Documentation Project

   Copyright (c) 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007,
   2008, 2009, 2010, 2011 The FreeBSD German Documentation Project

   FreeBSD ist ein eingetragenes Warenzeichen von der FreeBSD
   Foundation.

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

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

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

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

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

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

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

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

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

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

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

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

   Inhaltsverzeichnis

   1. Einfu:hrung

   2. Einen neuen Port erstellen

   3. Einen neuen Port erstellen

                3.1. Das Makefile schreiben

                3.2. Die Beschreibungsdateien erstellen

                             3.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 neuen Port einreichen

   4. Einen Port in aller Ruhe erstellen

                4.1. Die Funktionsweise

                4.2. Den originalen Quelltext besorgen

                4.3. Den Port bearbeiten

                4.4. Fehlerbehebung (Patches)

                4.5. Konfigurieren

                4.6. Handhabung von Benutzereingaben

   5. Die Konfiguration des Makefile

                5.1. Der originale Quelltext

                5.2. Bezeichnungen

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

                             5.13.1. CONFLICTS_INSTALL

                             5.13.2. CONFLICTS_BUILD

                             5.13.3. CONFLICTS

                5.14. Installation von Dateien

                             5.14.1. INSTALL_* macros

                             5.14.2. Zerlegen von Bina:rdateien und
                             Shared-Libraries

                             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 Qt

                             6.9.1. Ports, die Qt beno:tigen

                             6.9.2. Komponentenauswahl (nur bei Qt
                             4.x)

                             6.9.3. Zusa:tzliche Besonderheiten

                6.10. Benutzung von KDE

                             6.10.1. Variablen-Definitionen (KDE 3)

                             6.10.2. Variablen-Definitionen (KDE 4)

                6.11. Benutzung von Java

                             6.11.1. Variablen-Definitionen

                             6.11.2. Kompilieren mit Ant

                             6.11.3. Optimales Verfahren

                6.12. Webanwendungen, Apache und PHP

                             6.12.1. Apache

                             6.12.2. Webanwendungen

                             6.12.3. PHP

                             6.12.4. PEAR Module

                6.13. Python benutzen

                6.14. Benutzung von Tcl/Tk

                6.15. Emacs benutzen

                6.16. Ruby benutzen

                6.17. SDL verwenden

                6.18. wxWidgets verwenden

                             6.18.1. Einfu:hrung

                             6.18.2. Auswahl der Version

                             6.18.3. Komponentenauswahl

                             6.18.4. Unicode

                             6.18.5. Feststellen der installierten
                             Version

                             6.18.6. Vordefinierte Variablen

                             6.18.7. Verarbeitung in bsd.port.pre.mk

                             6.18.8. Weitere configure-Argumente

                6.19. Verwendung von Lua

                             6.19.1. Einfu:hrung

                             6.19.2. Auswahl der Version

                             6.19.3. Komponentenauswahl

                             6.19.4. Feststellen der installierten
                             Version

                             6.19.5. Vordefinierte Variablen

                             6.19.6. Verarbeitung in bsd.port.pre.mk

                6.20. Xfce verwenden

                6.21. Mozilla verwenden

                6.22. Benutzung von Datenbanken

                6.23. Starten und Anhalten von Diensten (rc Skripten)

                             6.23.1. Anhalten und Deinstallieren von
                             Diensten

                6.24. Hinzufu:gen von Benutzern und Gruppen

                6.25. Von Kernelquellen abha:ngige Ports

   7. Fortgeschrittene pkg-plist-Methoden

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

                7.2. Leere Verzeichnisse

                             7.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 existierenden Port aktualisieren

                10.1. Patches mit CVS erstellen

                10.2. Die Dateien UPDATING und MOVED

   11. Sicherheit der Ports

                11.1. Warum Sicherheit so wichtig ist

                11.2. Sicherheitslu:cken schliessen

                11.3. Die Community informiert halten

                             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. Aufgaben vernu:nftig lo:sen

                12.9. Beru:cksichtigen Sie sowohl CC als auch CXX

                12.10. Beru:cksichtigen Sie CFLAGS

                12.11. Threading-Bibliotheken

                12.12. Ru:ckmeldungen

                12.13. README.html

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

                             12.14.1. Variablen

                             12.14.2. Anmerkungen zur Implementierung

                12.15. Kennzeichnen eines Ports zur Entfernung durch
                DEPRECATED oder EXPIRATION_DATE

                12.16. Vermeiden Sie den Gebrauch des
                .error-Konstruktes

                12.17. Verwendung von sysctl

                12.18. Erneutes Ausliefern von Distfiles

                12.19. Verschiedenes

   13. Beispiel eines Makefile

   14. Auf dem Laufenden bleiben

                14.1. FreshPorts

                14.2. Die Webschnittstelle zum Quelltext-Repository

                14.3. Die FreeBSD Ports-Mailingliste

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

                14.5. Der FreeBSD Ports-Distfile-Scanner

                14.6. Das FreeBSD Ports-Monitoring-System

   Tabellenverzeichnis

   5-1. Beliebte magic MASTER_SITES-Makros

   5-2. Die USE_*-Varibalen

   5-3. Ha:ufige WITH_* und   WITHOUT_*-Variablen

   6-1. Port-Variablen im Zusammenhang mit gmake

   6-2. Variablen fu:r Ports, die configure benutzen

   6-3. Variablen fu:r Ports, die scons benutzen

   6-4. Variablen fu:r Ports, die perl benutzen

   6-5. Variablen fu:r Ports, die X benutzen

   6-6. Variablen bei Abha:ngigkeit von einzelnen Teilen von X11

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

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

   6-9. Verfu:gbare Qt4-Bibliothekskomponenten

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

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

   6-12. Variablen fu:r Ports, die KDE 3 benutzen

   6-13. Verfu:gbare KDE 4-Komponenten

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

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

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

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

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

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

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

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

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

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

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

   6-25. Verfu:gbare wxWidgets-Versionen

   6-26. Spezifikationen der wxWidgets-Versionen

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

   6-28. Verfu:gbare wxWidgets-Komponenten

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

   6-30. Standardtypen der wxWidgets-Abha:ngigkeiten

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

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

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

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

   6-35. Verfu:gbare Lua-Versionen

   6-36. Spezifikationen der Lua-Versionen

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

   6-38. Verfu:gbare Lua-Komponenten

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

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

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

   6-42. Variablen fu:r Ports, die Mozilla verwenden

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

   10-1. Von cvs update verwendete Pra:fixe

   12-1. __FreeBSD_version-Werte

   Beispiele

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

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

   5-3. Ausfu:hrliches Beispiel von MASTER_SITES:n in
   MASTER_SITE_SUBDIR

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

   5-5. Ausfu:hrliches Beispiel von MASTER_SITES:n mit
   MASTER_SITE_SOURCEFORGE

   5-6. Vereinfachte Nutzung von MASTER_SITES:n mit PATCH_SITES.

   5-7. Nutzung von ALWAYS_KEEP_DISTFILES.

   5-8. Einfache Anwendung von OPTIONS

   5-9. Veraltete Anwendung von OPTIONS

   5-10. Falsche Behandlung einer Option

   5-11. Korrekte Behandlung einer Option

   6-1. Beispiel fu:r USE_XORG

   6-2. Benutzung von X11-bezogenen Variablen in einem Port

   6-3. Qt4-Komponenten auswa:hlen

   6-4. USE_KDE4-Beispiel

   6-5. Beispiel eines Makefiles fu:r eine PEAR Klasse

   6-6. Auswahl von wxWidgets-Komponenten

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

   6-8. Verwendung von wxWidgets-Variablen in Kommandos

   6-9. Auswahl der Lua-Version

   6-10. Auswahl von Lua-Komponenten

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

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

   6-13. Verwendung von Lua-Variablen in Kommandos

   12-1. Wie vermeidet man die Verwendung von .error

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

                         Kapitel 1. Einfu:hrung

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

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

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

                 Kapitel 2. Einen neuen Port erstellen

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

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

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

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

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

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

                 Kapitel 3. Einen neuen Port erstellen

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

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

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

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

3.1. Das Makefile schreiben

   Ein minimales Makefile sieht in etwa so aus:

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

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

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

 MAN1=          oneko.1
 MANCOMPRESSED= yes
 USE_IMAKE=     yes

 .include <bsd.port.mk>

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

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

3.2. Die Beschreibungsdateien erstellen

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

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

  3.2.1. pkg-descr

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

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

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

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

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

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

  3.2.2. pkg-plist

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

   Hier ist ein kleines Beispiel:

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

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

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

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

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

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

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

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

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

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

3.3. Die Checksummendatei erzeugen

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

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

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

3.4. Den Port testen

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

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

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

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

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

   Empfohlene Testreihenfolge

    1. make install

    2. make package

    3. make deinstall

    4. pkg_add Paket-Name

    5. make deinstall

    6. make reinstall

    7. make package

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

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

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

3.5. Ihren Port mit portlint u:berpru:fen

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

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

3.6. Den neuen Port einreichen

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

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

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

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

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

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

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

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

             Kapitel 4. Einen Port in aller Ruhe erstellen

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

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

4.1. Die Funktionsweise

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.2. Den originalen Quelltext besorgen

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

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

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

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

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

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

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

4.3. Den Port bearbeiten

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

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

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

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

4.4. Fehlerbehebung (Patches)

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

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

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

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

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

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

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

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

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

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

 USE_DOS2UNIX=    util.c util.h

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

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

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

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

4.5. Konfigurieren

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

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

4.6. Handhabung von Benutzereingaben

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

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

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

               Kapitel 5. Die Konfiguration des Makefile

   Das Konfigurieren des Makefile ist sehr einfach und wir schlagen
   vor, dass Sie zuna:chst einen Blick auf vorhandene Beispiele
   werfen. Zusa:tzlich gibt es ein Beispiel eines Makefile in diesem
   Handbuch. Schauen Sie es sich an und verfolgen Sie bitte die
   Abfolge der Variablen und Abschnitte in dieser Vorlage. Damit
   erleichtern Sie es anderen, Ihren Port zu lesen.

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

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

5.1. Der originale Quelltext

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

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

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

5.2. Bezeichnungen

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

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

  5.2.1. PORTNAME und PORTVERSION

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

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

  5.2.2. PORTREVISION und PORTEPOCH

    5.2.2.1. PORTREVISION

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

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

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

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

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

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

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

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

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

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

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

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

     * Build fixes, die ein Paket erst kompilierbar machen, welches
       ohne diese A:nderungen vorher nicht erzeugt werden konnte
       (solange die A:nderungen keine funktionale Differenz bringen
       auf Plattformen, auf denen dieses Paket schon vorher gebaut
       werden konnte). Da PORTREVISION den Inhalt des Pakets
       wiederspiegelt, ist es nicht notwendig PORTREVISION zu
       erho:hen, wenn das Paket vorher nicht erstellt werden konnte.

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

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

    5.2.2.2. PORTEPOCH

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

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

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

   Es wird erwartet, dass PORTEPOCH fu:r die weitaus u:berwiegende
   Zahl der Ports nicht verwendet wird und der verantwortungsvolle
   und vorausschauende Umgang mit PORTVERSION macht es meist
   u:berflu:ssig, falls ein spa:teres Release die Versionsstruktur
   a:ndern sollte. Vorsicht ist geboten, wenn ein Release einer
   Drittanbieter-Software ohne eine offizielle Versionsnummer
   vero:ffentlicht wird, wie z.B. bei ``Snapshot-Versionen''. Man ist
   versucht, das Release mit dem jeweiligen Datum zu bezeichnen, was
   unweigerlich zu den oben beschriebenen Problemen fu:hrt, wenn das
   na:chste ``offizielle'' Release erscheint.

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

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

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

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

 PORTNAME=       gtkmumble
 PORTVERSION=    0.10

   PKGNAME wird zu gtkmumble-0.10.

   Ein Sicherheitsloch wurde entdeckt, das einen lokalen Patch von
   FreeBSD erforderlich macht. PORTREVISION wird entsprechend
   erho:ht.

 PORTNAME=       gtkmumble
 PORTVERSION=    0.10
 PORTREVISION=   1

   PKGNAME wird zu gtkmumble-0.10_1

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

 PORTNAME=       gtkmumble
 PORTVERSION=    0.2
 PORTEPOCH=      1

   PKGNAME wird zu gtkmumble-0.2,1

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

 PORTNAME=       gtkmumble
 PORTVERSION=    0.3
 PORTEPOCH=      1

   PKGNAME wird zu gtkmumble-0.3,1

     Anmerkung: Falls PORTEPOCH mit diesem Upgrade auf 0
     zuru:ckgesetzt worden wa:re, dann wu:rde jemand, der das Paket
     gtkmumble-0.10_1 installiert ha:tte, das Paket gtkmumble-0.3
     nicht als neuer erkennen, da 3 immer noch numerisch kleiner ist
     als 10. Bedenken Sie, dass genau dies der springende Punkt an
     PORTEPOCH ist.

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

  5.2.3. PKGNAMEPREFIX und PKGNAMESUFFIX

   Zwei optionale Variablen, PKGNAMEPREFIX und PKGNAMESUFFIX, werden
   verknu:pft mit PORTNAME und PORTVERSION, um PKGNAME zu bilden als 
   ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION} .
   Stellen Sie bitte unbedingt sicher, dass diese Variablen den
   Richtlinien fu:r einen guten Paketnamen entsprechen. Insbesondere
   du:rfen Sie keinesfalls einen Bindestrich (-) in PORTVERSION
   verwenden. Falls das Paket den language- oder
   -compiled.specifics-Teil aufweist (siehe unten) benutzen Sie
   PKGNAMEPREFIX oder PKGNAMESUFFIX respektive. Machen Sie diese
   Variablen nicht zum Bestandteil von PORTNAME!

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

  5.2.4. LATEST_LINK

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

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

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

  5.2.5. Namensregeln fu:r Pakete

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

   Der Paketname soll aussehen wie
   [language[_region]]-name[[-]compiled.specifics]-version.numbers.

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

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

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

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

    2. Der erste Buchstabe des name-Teils muss kleingeschrieben
       werden (der Rest des Namens kann Grossbuchstaben enthalten.
       Daher seien Sie bitte umsichtig, wenn Sie den Namen einer
       Software konvertieren, welche Grossbuchstaben entha:lt). Es
       ist Tradition, Perl 5-Module durch ein vorstehendes p5- und
       durch Umwandlung des doppelten Doppelpunktes in Bindestriche
       zu bezeichnen. So wird z.B. aus dem Data::Dumper-Modul der
       p5-Data-Dumper-Port.

    3. Vergewissern Sie sich, dass der Name des Ports und seine
       Versionsnummer klar getrennt sind und in den Variablen
       PORTNAME und PORTVERSION stehen. Der einzige Grund, um in
       PORTNAME einen Versionsteil aufzunehmen ist der, dass die
       Software wirklich so bezeichnet wird, wie z.B. die Ports
       textproc/libxml2 oder japanese/kinput2-freewnn. Ansonsten
       sollte PORTNAME keine versionsspezifischen Bestandteile
       aufweisen. Es ist vollkommen normal, dass viele Ports den
       gleichen PORTNAME aufweisen wie z.B. die www/apache*-Ports. In
       diesem Falle werden unterschiedliche Versionen (und
       unterschiedliche Indexeintra:ge) unterschieden durch die Werte
       von PKGNAMEPREFIX, PKGNAMESUFFIX und LATEST_LINK.

    4. Falls der Port mit verschiedenen, fest kodierten Vorgaben
       (u:blicherweise Teil des Verzeichnisnamens in einer Familie
       von Ports) gebaut werden kann, dann soll der
       -compiled.specifics-Teil die einkompilierten Vorgaben anzeigen
       (der Bindestrich ist optional). Beispiele hierfu:r sind
       Papiergro:ssen und Font-Einheiten.

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

    5. Die Versionszeichenfolge sollte einen Bindestrich (-) am
       Schluss haben und eine von Punkten getrennte Liste von
       Integer-Zahlen und kleingeschriebenen Buchstaben sein. Es ist
       nicht zula:ssig, einen weiteren Bindestrich innerhalb des
       Versionsstrings zu verwenden! Die einzige Ausnahme hiervon ist
       die Zeichenfolge pl (bedeutet ``patchlevel''), welche nur dann
       gebraucht werden darf, wenn die Applikation u:ber keine
       Haupt- oder Unterversionsnummern verfu:gt. Wenn die
       Versionsbezeichnung der Software Zeichenketten wie ``alpha'',
       ``beta'', ``rc'' oder ``pre'' entha:lt, dann nehmen Sie bitte
       den ersten Buchstaben daraus und setzen ihn unmittelbar hinter
       einen Punkt. Falls die Versionszeichenfolge nach diesem Punkt
       fortgesetzt wird, sollen die Zahlen ohne einen Punkt zwischen
       den einzelnen Buchstaben folgen.

       Das Ziel ist es, die Ports anhand der Versionszeichenfolge zu
       sortieren. Stellen Sie bitte unbedingt sicher, dass die
       Bestandteile der Versionsnummer immer durch einen Punkt
       getrennt sind und falls Datumsangaben verwendet werden, dass
       diese im Format 0.0.yyyy.mm.dd und nicht dd.mm.yyyy oder gar
       dem nicht Y2K-kompatiblen Format   yy.mm.dd vorliegen. Es ist
       wichtig, dass die Versionsnummer mit 0.0. beginnt, da die
       Versionsnummer im Falle einer Vero:ffentlichung auf jeden Fall
       kleiner als yyyy sein wird.

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

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

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

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

5.3. Kategorisierung

  5.3.1. CATEGORIES

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

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

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

  5.3.2. Aktuelle Liste der Kategorien

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

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

  Kategorie           Beschreibung                   Anmerkung           
accessibility Ports fu:r behinderte                                      
              Menschen.                     
afterstep*    Ports fu:r den AfterStep                                   
              Window Manager.               
arabic        Arabische                                                  
              Sprachunterstu:tzung.         
archivers     Archivierungswerkzeuge.                                    
astro         Ports fu:r Astronomie.                                     
audio         Sound-Unterstu:tzung.                                      
benchmarks    Benchmarking-Werkzeuge.                                    
biology       Software fu:r Biologie.                                    
cad           CAD-Werkzeuge.                                             
chinese       Chinesische                                                
              Sprachunterstu:tzung.         
comms         Kommunikationsprogramme.      Hauptsa:chlich Software fu:r 
                                            serielle Schnittstellen.     
converters    Zeichensatz-Konverter.                                     
databases     Datenbanken.                                               
              Dinge, die vor der Erfindung                               
deskutils     des Computers auf dem          
              Schreibtisch waren.           
                                            Legen Sie keine Bibliotheken 
                                            hier ab, nur weil es         
devel         Entwicklungs-Werkzeuge.       Bibliotheken sind, es sei    
                                            denn, sie geho:ren wirklich  
                                            nirgendwo anders hin.        
dns           DNS-bezogene Software.                                     
docs*         Meta-Ports fu:r die                                        
              FreeBSD-Dokumentation.        
                                            Spezielle Editoren geho:ren  
                                            in Ihre jeweilige Kategorie, 
editors       allgemeine Editoren.          (z.B. geho:rt ein            
                                            mathematischer Formeleditor  
                                            in math).                    
elisp*        Emacs-lisp-Ports.                                          
                                            Terminal-Emulatoren geho:ren 
                                            nicht hierher; X-basierende  
              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(TM)-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, news, security oder www passt, da net in diesen
       Kategorien bereits implizit eingeschlossen ist.

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

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

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

     * misc sollte nicht zusammen mit irgendeiner anderen
       nicht-virtuellen Kategorie auftreten. Falls Sie misc mit einer
       anderen Kategorie in CATEGORIES haben bedeutet dies, dass Sie
       gefahrlos misc streichen und die andere Kategorie alleine
       verwenden ko:nnen!

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

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

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

  5.3.4. Eine neue Kategorie vorschlagen

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

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

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

   Hier ist das Prozedere:

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

    2. Nehmen Sie an der Diskussion teil.

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

          * Makefiles fu:r die neuen Ports nach dem Repocopy

          * Makefile fu:r die neue Kategorie

          * Makefile fu:r die alten Kategorien der betroffenen Ports

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

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

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

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

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

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

  5.3.5. Vorschlagen einer Neuorganisation aller Kategorien

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

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

5.4. Die Distributionsdateien

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

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

  5.4.1. DISTVERSION/DISTNAME

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

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

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

     Anmerkung: PKGNAMEPREFIX und PKGNAMESUFFIX beeinflussen DISTNAME
     nicht. Beachten Sie bitte auch, dass Sie DISTNAME unvera:ndert
     lassen sollten, falls WRKSRC denselben Wert hat wie
     work/${PORTNAME}-${PORTVERSION} und gleichzeitig dass Archiv des
     originalen Quelltextes anders benannt ist als
     ${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX}. Es ist einfacher
     DISTFILES zu definieren, als DISTNAME und WRKSRC (und
     mo:glicherweise EXTRACT_SUFX) zu setzen.

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

  5.4.2. MASTER_SITES

   Dokumentieren Sie das Verzeichnis der FTP/HTTP-URL, welche auf den
   originalen Tarball zeigt, in der Variable MASTER_SITES. Bitte
   vergessen Sie niemals den Schra:gstrich (/) am Ende!

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

   Es wird empfohlen, mehrere Webseiten in dieser Liste aufzufu:hren,
   vorzugsweise auf verschiedenen Kontinenten. Dies ist ein Schutz
   gegen Probleme bei gro:sseren Ausfa:llen im Internet. Wir planen
   sogar Unterstu:tzung einzubauen, die automatisch einen Server in
   der Na:he zum Herunterladen bestimmt. Die Verfu:gbarkeit von
   vielen Webseiten wird dieses Vorhaben betra:chtlich erleichtern.

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

 MASTER_SITES=         ${MASTER_SITE_GNU}
 MASTER_SITE_SUBDIR=   make

   Oder verwenden Sie ein kondensiertes Format:

 MASTER_SITES=   GNU/make

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

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

 MASTER_SITES=   SF

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

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

   Tabelle 5-1. Beliebte magic MASTER_SITES-Makros

    Makro                               Erwartetes Unterverzeichnis                           
APACHE_JAKARTA /dist/jakarta/${PORTNAME:S,-,,/,}/source                                       
BERLIOS        /${PORTNAME:L}                                                                 
CHEESESHOP     /packages/source/source/${DISTNAME:C/(.).*/\1/}/${DISTNAME:C/(.*)-[0-9].*/\1/} 
DEBIAN         /debian/pool/main/${PORTNAME:C/^((lib)?.).*$/\1/}/${PORTNAME}                  
GCC            /pub/gcc/releases/${DISTNAME}                                                  
GNOME          /pub/GNOME/sources/${PORTNAME}/${PORTVERSION:C/^([0-9]+\.[0-9]+).*/\1/}        
GNU            /gnu/${PORTNAME}                                                               
MOZDEV         /pub/mozdev/${PORTNAME:L}                                                      
PERL_CPAN      /pub/CPAN/modules/by-module/${PORTNAME:C/-.*//}                                
PYTHON         /ftp/python/${PYTHON_PORTVERSION:C/rc[0-9]//}                                  
RUBYFORGE      /${PORTNAME:L}                                                                 
SAVANNAH       /${PORTNAME:L}                                                                 
SF             /project/${PORTNAME:L}/${PORTNAME:L}/${PORTVERSION}                            

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

  5.4.3. EXTRACT_SUFX

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

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

 DISTNAME=      foo
 EXTRACT_SUFX=  .tgz

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

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

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

  5.4.4. DISTFILES

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

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

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

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

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

  5.4.5. EXTRACT_ONLY

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

 DISTFILES=     source.tar.gz manual.html
 EXTRACT_ONLY=  source.tar.gz

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

 EXTRACT_ONLY=

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

  5.4.6. PATCHFILES

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

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

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

   Falls der Patch zusammen mit anderen Dateien in einem gezippten
   Tarball verteilt wird (z.B. mit Dokumentation), dann ko:nnen Sie
   nicht PATCHFILES verwenden. In diesem Fall fu:gen Sie den Namen
   und den Ort dieses Tarballs zu DISTFILES und MASTER_SITES.
   Benutzen Sie dann die EXTRA_PATCHES-Variable, um auf diese Dateien
   zu zeigen und bsd.port.mk wird automatisch diese Dateien nutzen.
   Kopieren Sie niemals Patch-Dateien in das PATCHDIR-Verzeichnis,
   weil es mo:glicherweise nicht beschreibbar ist.

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

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

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

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

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

   Etwas Hintergrundinformation zu Beginn: OpenBSD verfu:gt u:ber
   eine sehr elegante Option innerhalb der Variablen DISTFILES und
   PATCHFILES. Sowohl Dateien als auch Patches ko:nnen mit
   angeha:ngten :n-Bezeichnern versehen werden wobei n in beiden
   Fa:llen [0-9] sein kann und eine Gruppenzugeho:rigkeit anzeigt.
   Ein Beispiel hierfu:r ist:

 DISTFILES=      alpha:0 beta:1

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

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

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

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

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

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

    5.4.7.1. Prinzipielle Information

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

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

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

   Stellen Sie sich bitte eine Applikation vor, deren Quelltext in
   zwei Teile aufgeteilt ist, source1.tar.gz und source2.tar.gz,
   welche von zwei verschiedenen Webseiten heruntergeladen werden
   mu:ssen. Das Makefile des Port wu:rde Zeilen enthalten wie in
   Beispiel 5-1.

   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 ohne Punkt enden. Hier ist ein Beispiel:

 COMMENT=       A cat chasing a mouse all over the screen

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

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

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

5.7. Abha:ngigkeiten (dependencies)

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

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

  5.7.1. LIB_DEPENDS

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

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

   auf eine jpeg-Bibliothek mit der Hauptversionsnummer 9 pru:fen, in
   das graphics/jpeg-Unterverzeichnis Ihrer Ports-Sammlung wechseln,
   es bauen und installieren, falls es nicht gefunden wird. Der
   target-Teil kann weggelassen werden, falls er identisch mit
   DEPENDS_TARGET ist (Vorgabe hierfu:r ist install).

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

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

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

  5.7.2. RUN_DEPENDS

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

   Zum Beispiel wird

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

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

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

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

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

   Die Abha:ngigkeit wird innerhalb des install-Target u:berpru:ft.
   Zudem wird der Name der Abha:ngigkeit in das Paket u:bernommen,
   damit pkg_add(1) es automatisch installieren wird, falls es auf
   dem System des Nutzers nicht vorhanden ist. Der target-Teil kann
   weggelassen werden, wenn er der gleiche ist wie in der Variable
   DEPENDS_TARGET.

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

 RUN_DEPENDS= ${BUILD_DEPENDS}

   Jedoch kann eine solche Zuweisung dazu fu:hren, dass die Liste der
   Laufzeitabha:ngigkeiten mit u:berflu:ssigen Eintra:gen belastet
   wird, die sich nicht in der urspru:nglichen Liste BUILD_DEPENDS
   des Ports befanden, da sich make(1) bei der Auswertung solcher
   Zuweisungen tra:ge verha:lt. Stellen Sie sich ein Makefile mit
   USE_*-Variablen vor, die von ports/Mk/bsd.*.mk verarbeitet werden,
   um initiale Bauabha:ngigkeiten zusammenzutragen. Zum Beispiel
   fu:gt USE_GMAKE=yes devel/gmake zu BUILD_DEPENDS hinzu. Um zu
   verhindern, dass solche zusa:tzlichen Abha:ngigkeiten RUN_DEPENDS
   belasten, achten Sie darauf, bei gleichzeitiger Auswertung
   zuzuweisen, d.h. der Ausdruck wird ausgewertet, bevor er als Wert
   der Variablen zugewiesen wird:

 RUN_DEPENDS:=  ${BUILD_DEPENDS}

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

  5.7.3. BUILD_DEPENDS

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

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

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

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

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

  5.7.4. FETCH_DEPENDS

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

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

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

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

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

  5.7.5. EXTRACT_DEPENDS

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

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

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

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

     Anmerkung: Nutzen Sie diese Variable nur, wenn die Extraktion
     nicht funktioniert (die Vorgabe nimmt gzip an) und nicht mit
     USE_ZIP oder USE_BZIP2 wie in Abschnitt 5.7.7 beschrieben zum
     Laufen gebracht werden kann.

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

  5.7.6. PATCH_DEPENDS

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

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

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

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

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

  5.7.7. USE_*

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

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

 USE_GCC=3.4

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

   Tabelle 5-2. Die USE_*-Varibalen

     Variable                         Bedeutung                       
   USE_BZIP2    Der Tarball dieses Ports wird mit bzip2 komprimiert.  
   USE_ZIP      Der Tarball des Ports wird mit zip komprimiert.       
   USE_BISON    Der Port benutzt bison fu:r die Erstellung.           
                Der Port erfordert cdrecord entweder von              
   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.4. Mit 3.4+ 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.10 KDE-bezogene
   Variablen. Abschnitt 6.11 dokumentiert Java-Variablen, wa:hrend
   Abschnitt 6.12Informationen zu Apache, PHP und PEAR-Modulen
   entha:lt. Python wird in Abschnitt 6.13 und Ruby in Abschnitt 6.16
   ero:rtert. Abschnitt 6.17 stellt Variablen fu:r SDL-Programme zur
   Verfu:gung und Abschnitt 6.20 entha:lt schliesslich Variablen fu:r
   Xfce.

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

  5.7.8. Minimale Version einer Abha:ngigkeit

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

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

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

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

  5.7.9. Anmerkungen zu Abha:ngigkeiten

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

   Falls Sie make clean schreiben, werden dessen Abha:ngigkeiten auch
   gesa:ubert. Falls Sie dies nicht wollen, definieren Sie die
   Variable NOCLEANDEPENDS in Ihrer Umgebung. Dies kann besonders
   erstrebenswert sein, wenn der Port etwas in seiner Liste von
   Abha:ngigkeiten hat, das sehr viel Zeit fu:r einen rebuild
   beno:tigt wie KDE, GNOME oder Mozilla.

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

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

   immer zum jpeg-Port wechseln und ihn extrahieren.

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

  5.7.10. Zirkula:re Abha:ngigkeiten sind fatal

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

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

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

5.8. MASTERDIR

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

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

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

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

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

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

 .include "${MASTERDIR}/Makefile"

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

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

5.9. Manualpages

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

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

   Falls die Manualpages wa:hrend der Installation komprimiert werden
   sollen, mu:ssen Sie die Variable MANCOMPRESSED setzen. Diese
   Variable kann drei Werte annehmen, yes, no und maybe. yes
   bedeutet, dass Manualpages bereits komprimiert installiert sind,
   bei no sind sie es nicht und maybe bedeutet, dass die Software
   bereits den Wert von NO_MANCOMPRESS beachtet, damit bsd.port.mk
   nichts Besonderes auszufu:hren hat.

   MANCOMPRESSED wird automatisch auf yes gesetzt, wenn USE_IMAKE
   vorgegeben ist und gleichzeitig NO_INSTALL_MANPAGES nicht. Im
   umgekehrten Falle ist MANCOMPRESSED auf no gesetzt. Sie mu:ssen es
   nicht explizit angeben, ausser die Standardvorgabe ist fu:r Ihren
   Port nicht passend.

   Wenn Ihr Port den man tree irgendwo anders als in der Variable
   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/gcc34 Info-Dateien nach PREFIX/INFO_PATH/gcc34,
   wobei INFO etwa so aussieht:

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

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

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

5.11. Makefile-Optionen

   Einige gro:ssere Applikationen ko:nnen mit einer Reihe von
   Konfigurationen, die zusa:tzliche Funktionalita:ten hinzufu:gen,
   erstellt werden, falls eine oder mehrere Bibliotheken oder
   Applikationen verfu:gbar sind. Dazu geho:ren die Auswahl von
   natu:rlichen Sprachen, GUI versus Kommandozeilen-Versionen oder
   die Auswahl aus mehreren Datenbank-Programmen. Da nicht alle
   Nutzer diese Bibliotheken oder Applikationen wollen, stellt das
   Ports-System hooks (Haken) zur Verfu:gung, damit der Autor des
   Ports bestimmen kann, welche Konfiguration erstellt werden soll.

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

  5.11.1. KNOBS (Einstellungen)

    5.11.1.1. WITH_* und WITHOUT_*

   Diese Variablen sind entworfen worden, um vom System-Administrator
   gesetzt zu werden. Es gibt viele, die in ports/KNOBS
   standardisiert sind.

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

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

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

   Tabelle 5-3. Ha:ufige WITH_* und   WITHOUT_*-Variablen

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

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

     Anmerkung: CONFLICTS setzt automatisch die Variable IGNORE, die
     ausfu:hrlicher in Abschnitt 12.14 beschrieben wird.

   Beim Entfernen eines von mehreren in Konflikt stehenden Ports ist
   es ratsam, die CONFLICTS-Eintra:ge in den anderen Ports fu:r
   einige Monate beizubehalten, um Nutzer zu unterstu:tzen, die ihre
   Ports nur sporadisch aktualisieren.

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

  5.13.1. CONFLICTS_INSTALL

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

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

  5.13.2. CONFLICTS_BUILD

   Wenn Ihr Port nicht gebaut werden kann, wenn ein bestimmter Port
   bereits installiert ist, geben Sie diesen in der Variable
   CONFLICTS_BUILD an. Sie ko:nnen hier Shell-Globs wie * und ?
   verwenden. Paketnamen sollten in der gleichen Weise aufgeza:hlt
   werden, wie sie in /var/db/pkg auftauchen. Die
   CONFLICTS_BUILD-Pru:fung erfolgt vor dem Bau des Ports.
   Baukonflikte werden im erzeugten Paket nicht verzeichnet.

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

  5.13.3. CONFLICTS

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

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

5.14. Installation von Dateien

  5.14.1. INSTALL_* macros

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

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

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

     * INSTALL_LIB ist ein Befehl zur Installation Shared-Libraries.

     * INSTALL_KLD ist ein Befehl, mit dem Kernelmodule installiert
       werden ko:nnen. Einige Architekturen haben Probleme mit
       stripped-Modulen. Daher sollten Sie diesen Befehl anstelle von
       INSTALL_PROGRAM verwenden.

     * INSTALL_DATA ist ein Befehl, um gemeinsam nutzbare Daten zu
       installieren.

     * INSTALL_MAN ist ein Befehl, um Manualpages oder andere
       Dokumentation zu installieren (es wird nichts komprimiert).

   Das sind grundsa:tzlich alle install-Befehle mit ihren passenden
   Flags.

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

  5.14.2. Zerlegen von Bina:rdateien und Shared-Libraries

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

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

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

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

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

  5.14.3. Installation eines ganzen Verzeichnisbaums inklusive Dateien

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

   Fu:r diesen Fall gibt es zwei Makros. Der Vorteil der Nutzung
   dieser Makros anstatt cp ist, dass sie korrekte Besitzer und
   Berechtigungen auf den Zieldateien garantieren. Das erste Makro,
   COPYTREE_BIN, wird alle installierten Dateien ausfu:hrbar
   markieren und damit passend fu:r die Installation in PREFIX/bin
   vorbereiten. Das zweite Makro, COPYTREE_SHARE, setzt keine
   Ausfu:hrungsberechtigungen auf Dateien und ist daher geeignet fu:r
   die Installation von Dateien im Target von PREFIX/share.

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

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

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

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

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

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

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

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

  5.14.4. Installation zusa:tzlicher Dokumentation

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

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

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

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

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

     * DATADIR wird expandiert zu PREFIX/share/PORTNAME.

     * DATADIR_REL wird expandiert zu share/PORTNAME.

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

     * DOCSDIR_REL wird expandiert zu share/doc/PORTNAME.

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

     * EXAMPLESDIR_REL wird expandiert zu share/examples/PORTNAME.

     Anmerkung: NOPORTDOCS behandelt nur zusa:tzliche Dokumentation,
     die in DOCSDIR installiert ist. Fu:r normale Manualpages und
     Info-Seiten wird die Variable benutzt. Dinge, welche in DATADIR
     und EXAMPLESDIR installiert werden, legen die Variablen
     NOPORTDATA und NOPORTEXAMPLES fest.

   Die Variablen werden nach PLIST_SUB exportiert. Ihre Werte
   erscheinen dort als Pfadnamen relativ zu PREFIX, falls mo:glich.
   Das bedeutet, dass share/doc/PORTNAME standardma:ssig ersetzt wird
   durch %%DOCSDIR%% in der Packliste usw. (mehr zur Ersetzung durch
   die pkg-plist finden Sie hier).

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

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

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

 PORTDOCS=       README.* ChangeLog docs/*

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

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

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

  5.14.5. Unterverzeichnisse mit PREFIX

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

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

                       Kapitel 6. Besonderheiten

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

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

6.1. Shared-Libraries

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

 USE_LDCONFIG= yes

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

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

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

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

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

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

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

6.2. Ports mit beschra:nkter Verbreitung

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

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

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

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

  6.2.1. NO_PACKAGE

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

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

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

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

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

  6.2.2. NO_CDROM

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

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

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

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

  6.2.3. NOFETCHFILES

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

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

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

  6.2.4. RESTRICTED

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

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

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

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

  6.2.5. RESTRICTED_FILES

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

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

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

6.3. Build-Mechanismen

  6.3.1. Paralleles Bauen von Ports

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

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

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

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

  6.3.2. make, gmake und imake

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

   Tabelle 6-1. Port-Variablen im Zusammenhang mit gmake

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

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

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

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

  6.3.3. configure Skript

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

   Tabelle 6-2. Variablen fu:r Ports, die configure benutzen

       Variable                         Bedeutung                     
   GNU_CONFIGURE    Der Port benutzt ein configure-Skript, um das     
                    Bauen vorzubereiten.                              
                    Wie GNU_CONFIGURE, nur dass kein                  
   HAS_CONFIGURE    Standard-Konfigurations-Target zu CONFIGURE_ARGS  
                    hinzugefu:gt wird.                                
   CONFIGURE_ARGS   Zusa:tzliche Argumente fu:r das configure-Skript. 
   CONFIGURE_ENV    Zusa:tzliche Umgebungsvariablen fu:r die          
                    Abarbeitung des configure-Skriptes.               
                    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,
   glew, gl und linux. Fu:r Abwa:rtskompatibilita:t gilt der Wert yes
   als glu.

   Beispiel 6-1. Beispiel fu:r USE_XORG

 USE_XORG=   xrender xft xkbfile xt xaw
 USE_GL=     glu

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

   Tabelle 6-5. Variablen fu:r Ports, die X benutzen

                Der Port benutzt die X-Bibliotheken. Soll nicht mehr  
   USE_XLIB     verwendet werden - benutzen Sie stattdessen eine      
                Liste von Komponenten in USE_XORG.                    
                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 Qt

  6.9.1. Ports, die Qt beno:tigen

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

                 Der Port benutzt das Qt-Toolkit. Mo:gliche Werte     
                 sind 3 und 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-8. Zusa:tzliche Variablen fu:r Ports, die Qt 4.xi
   benutzen

   QT_COMPONENTS Spezifiziert Tool- und Bibliothek-Abha:ngigkeiten    
                 fu:r Qt4. Siehe unten fu:r Details.                  
   UIC           Entha:lt den Pfad von uic (nur lesbare Variable).    
                 Voreingestellt entsprechend des USE_QT_VER-Wertes.   
   QMAKE         Entha:lt den Pfad von qmake (nur lesbare Variable).  
                 Voreingestellt entsprechend des USE_QT_VER-Wertes.   
                 Entha:lt den Pfad der Konfigurationsdatei fu:r qmake 
   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.2. Komponentenauswahl (nur bei Qt 4.x)

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

   Tabelle 6-9. Verfu:gbare Qt4-Bibliothekskomponenten

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

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

   Tabelle 6-10. Verfu:gbare Qt4-Tool-Komponenten

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

   Tabelle 6-11. Verfu:gbare Qt4-Plugin-Komponenten

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

   Beispiel 6-3. Qt4-Komponenten auswa:hlen

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

 USE_QT_VER=    4
 QT_COMPONENTS= gui moc_build qmake_build rcc_build uic_build

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

  6.9.3. Zusa:tzliche Besonderheiten

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

 HAS_CONFIGURE=    yes

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

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

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

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

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

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

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

6.10. Benutzung von KDE

  6.10.1. Variablen-Definitionen (KDE 3)

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

                   Der Port benutzt KDE-Bibliotheken. Die Variable    
                   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.10.2. Variablen-Definitionen (KDE 4)

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

   Tabelle 6-13. Verfu:gbare KDE 4-Komponenten

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

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

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

   Beispiel 6-4. USE_KDE4-Beispiel

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

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

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

6.11. Benutzung von Java

  6.11.1. Variablen-Definitionen

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

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

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

     Variable                         Bedeutung                       
   USE_JAVA     Sollte definiert sein, damit die u:brigen Variablen   
                irgendeinen Effekt haben.                             
                Durch Leerzeichen getrennte Liste von geeigneten      
   JAVA_VERSION Java-Versionen fu:r den Port. Ein optionales "+"      
                ermo:glicht die Angabe eines Bereiches von Versionen  
                (mo:gliche Werte: 1.5[+] 1.6[+] 1.7[+]).              
                Durch Leerzeichen getrennte Liste von geeigneten      
   JAVA_OS      JDK-Port-Betriebssystemen fu:r den Port. (erlaubte    
                Werte: native linux).                                 
                Durch Leerzeichen getrennte Liste von geeigneten      
   JAVA_VENDOR  JDK-Port-Anbietern fu:r den Port. (erlaubte Werte:    
                freebsd bsdjava sun openjdk).                         
                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.                             

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

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

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

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

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

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

    Konstante                           Wert                          
   JAVASHAREDIR Das Basis-Verzeichnis fu:r alles, was mit Java        
                zusammenha:ngt. Standardma:ssig ${PREFIX}/share/java. 
   JAVAJARDIR   Das Verzeichnis, wohin JAR-Dateien installiert werden 
                sollen. Standardma:ssig ${JAVASHAREDIR}/classes.      
                Das Verzeichnis, in dem JAR-Dateien, die von anderen  
   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.11.2. Kompilieren mit Ant

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

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

  6.11.3. Optimales Verfahren

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

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

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

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

   Der Vorgabewert fu:r DATADIR ist ${PREFIX}/share/${PORTNAME}. Es
   ist eine gute Idee, DATADIR fu:r Java-Ports stattdessen auf
   ${JAVASHAREDIR}/${PORTNAME} zu setzen. In der Tat wird DATADIR
   automatisch zu PLIST_SUB (dokumentiert in Abschnitt 7.1)
   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.12. Webanwendungen, Apache und PHP

  6.12.1. Apache

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

                    Der Port beno:tigt Apache. Mo:gliche Werte: yes   
   USE_APACHE       (beliebige Version), 1.3, 2.0, 2.2, 2.0+,         
                    etc. - Standard ist Version 1.3.                  
                    Der Port beno:tigt Apache 2.0. Ist diese Variable 
   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-18. Nu:tzliche Variablen fu:r Ports von Apache-Modulen

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

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

  6.12.2. Webanwendungen

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

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

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

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

  6.12.3. PHP

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

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

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

  6.12.4. PEAR Module

   Das Portieren von PEAR-Modulen ist sehr einfach.

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

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

   Beispiel 6-5. Beispiel eines Makefiles fu:r eine PEAR Klasse

 PORTNAME=       Date
 PORTVERSION=    1.4.3
 CATEGORIES=     devel www pear

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

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

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

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

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

6.13. Python benutzen

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

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

 PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX}

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

                           Der Port beno:tigt Python. Die minimal     
                           beno:tigte Version kann durch Werte wie    
                           2.3+ angegeben 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.14. Benutzung von Tcl/Tk

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

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

                         Der Port beno:tigt die Tcl-Bibliothek (nicht 
                         die Shell). Eine notwendige Mindestversion   
   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.15. Emacs benutzen

   Dieser Abschnitt muss noch geschrieben werden.

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

6.16. Ruby benutzen

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

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

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

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

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

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

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

6.17. SDL verwenden

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

   Die folgenden SDL-Bibliotheken sind derzeit bekannt:

     * sdl: devel/sdl12

     * gfx: graphics/sdl_gfx

     * gui: x11-toolkits/sdl_gui

     * image: graphics/sdl_image

     * ldbad: devel/sdl_ldbad

     * mixer: audio/sdl_mixer

     * mm: devel/sdlmm

     * net: net/sdl_net

     * sound: audio/sdl_sound

     * ttf: graphics/sdl_ttf

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

 USE_SDL=        net mixer

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

   Falls USE_SDL im Port verwendet wird, so wird automatisch:

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

     * die Variable SDL_CONFIG zu CONFIGURE_ENV hinzugefu:gt

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

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

 WANT_SDL=yes

 .include <bsd.port.pre.mk>

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

 .include <bsd.port.post.mk>

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

6.18. wxWidgets verwenden

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

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

  6.18.1. Einfu:hrung

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

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

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

  6.18.2. Auswahl der Version

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

   Tabelle 6-24. Variablen, um die wxWidgets-Version festzulegen

    Variable              Beschreibung                Standardwert    
   USE_WX     Liste der Versionen, die der Port     Alle verfu:gbaren 
              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-25. Verfu:gbare wxWidgets-Versionen

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

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

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

   Tabelle 6-26. Spezifikationen der wxWidgets-Versionen

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

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

   Tabelle 6-27. Variablen zur Festlegung der bevorzugten
   wxWidgets-Version

      Name     Bestimmt fu:r 
   WANT_WX_VER den Port      
   WITH_WX_VER den Benutzer  

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

  6.18.3. Komponentenauswahl

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

   Tabelle 6-28. Verfu:gbare wxWidgets-Komponenten

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

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

   Tabelle 6-29. Verfu:gbare Typen von wxWidgets-Abha:ngigkeiten

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

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

   Tabelle 6-30. Standardtypen der wxWidgets-Abha:ngigkeiten

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

   Beispiel 6-6. Auswahl von wxWidgets-Komponenten

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

 USE_WX=       2.4
 WX_COMPS=     wx contrib

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

  6.18.4. Unicode

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

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

      Variable                 Beschreibung             Bestimmt fu:r 
                   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.18.5. Feststellen der installierten Version

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

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

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

 WANT_WX=        yes

 .include <bsd.port.pre.mk>

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

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

 USE_WX=         2.6
 WX_COMPS=       wx
 WANT_WX=        2.6

 .include <bsd.port.pre.mk>

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

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

  6.18.6. Vordefinierte Variablen

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

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

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

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

  6.18.7. Verarbeitung in bsd.port.pre.mk

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

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

   Beispiel 6-8. Verwendung von wxWidgets-Variablen in Kommandos

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

 USE_WX=         2.4
 WX_PREMK=       yes

 .include <bsd.port.pre.mk>

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

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

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

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

  6.18.8. Weitere configure-Argumente

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

   Tabelle 6-33. Zula:ssige Werte fu:r WX_CONF_ARGS

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

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

6.19. Verwendung von Lua

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

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

  6.19.1. Einfu:hrung

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

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

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

  6.19.2. Auswahl der Version

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

   Tabelle 6-34. Variablen, um die Lua-Version festzulegen

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

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

   Tabelle 6-35. Verfu:gbare Lua-Versionen

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

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

   Tabelle 6-36. Spezifikationen der Lua-Versionen

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

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

   Tabelle 6-37. Variablen zur Festlegung der bevorzugten Lua-Version

       Name     Bestimmt fu:r 
   WANT_LUA_VER den Port      
   WITH_LUA_VER den Benutzer  

   Beispiel 6-9. Auswahl der Lua-Version

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

 USE_LUA=      5.0-5.1
 WANT_LUA_VER= 5.0

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

  6.19.3. Komponentenauswahl

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

   Tabelle 6-38. Verfu:gbare Lua-Komponenten

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

   Tabelle 6-39. Verfu:gbare Typen von Lua-Abha:ngigkeiten

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

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

   Tabelle 6-40. Standardtypen fu:r Lua-Abha:ngigkeiten

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

   Beispiel 6-10. Auswahl von Lua-Komponenten

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

 USE_LUA=      4.0
 LUA_COMPS=    lua ruby

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

  6.19.4. Feststellen der installierten Version

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

   Beispiel 6-11. Installierte Lua-Versionen und- Komponenten
   feststellen

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

 WANT_LUA=       yes

 .include <bsd.port.pre.mk>

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

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

 USE_LUA=        4.0
 LUA_COMPS=      lua
 WANT_LUA=       4.0

 .include <bsd.port.pre.mk>

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

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

  6.19.5. Vordefinierte Variablen

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

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

         Name                          Beschreibung                   
   LUA_VER           Die Lua-Version, die verwendet wird (z.B. 5.1)   
   LUA_VER_SH        Die Hauptversion fu:r shared-Lua-Bibliotheken    
                     (z.B. 1)                                         
   LUA_VER_STR       Die Lua-Version ohne die Punkte (z.B. 51)        
   LUA_PREFIX        Der Pra:fix, unter dem Lua (und Komponenten)     
                     installiert ist                                  
                     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-12. Einem Port mitteilen, in welchem Verzeichnis Lua
   liegt

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

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

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

  6.19.6. Verarbeitung in bsd.port.pre.mk

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

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

   Beispiel 6-13. Verwendung von Lua-Variablen in Kommandos

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

 USE_LUA=        5.0
 LUA_PREMK=      yes

 .include <bsd.port.pre.mk>

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

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

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

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

6.20. Xfce verwenden

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

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

     * libexo: x11/libexo

     * libgui: x11-toolkits/libxfce4gui

     * libutil: x11/libxfce4util

     * libmcs: x11/libxfce4mcs

     * mcsmanager: sysutils/xfce4-mcs-manager

     * panel: x11-wm/xfce4-panel

     * thunar: x11-fm/thunar

     * wm: x11-wm/xfce4-wm

     * xfdev: dev/xfce4-dev-tools

   Die folgenden zusa:tzlichen Parameter werden unterstu:tzt:

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

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

       wird CPPFLAGS hinzugefu:gt und ergibt CONFIGURE_ENV.

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

 USE_XFCE=        mcsmanager configenv

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

6.21. Mozilla verwenden

   Tabelle 6-42. Variablen fu:r Ports, die Mozilla verwenden

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

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

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

6.22. Benutzung von Datenbanken

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

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

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

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

6.23. Starten und Anhalten von Diensten (rc Skripten)

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

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

 USE_RC_SUBR=    doormand

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

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

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

   Beispiel eines einfachen rc.d-Skripts:

 #!/bin/sh

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

 . /etc/rc.subr

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

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

 load_rc_config $name

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

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

 run_rc_command "$1"

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

 REQUIRE: LOGIN

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

 KEYWORD: shutdown

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

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

 doormand_flags=""

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

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

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

  6.23.1. Anhalten und Deinstallieren von Diensten

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

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

 @stopdaemon doormand

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

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

6.24. Hinzufu:gen von Benutzern und Gruppen

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

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

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

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

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

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

6.25. Von Kernelquellen abha:ngige Ports

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

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

 IGNORE=         requires kernel sources to be installed
 .endif

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

             Kapitel 7. Fortgeschrittene pkg-plist-Methoden

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

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

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

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

 OCTAVE_VERSION= 2.0.13
 PLIST_SUB=      OCTAVE_VERSION=${OCTAVE_VERSION}

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

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

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

   und in der pkg-plist:

 %%X11%%bin/foo-gui

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

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

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

7.2. Leere Verzeichnisse

  7.2.1. Aufra:umen leerer Verzeichnisse

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

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

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

 @dirrmtry share/doc/gimp

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

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

  7.2.2. Erstellen leerer Verzeichnisse

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

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

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

7.3. Konfigurationsdateien

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

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

   Beispiel aus einem Makefile:

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

   Beispiel aus einer pkg-plist:

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

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

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

7.4. Dynamische oder statische Paketliste

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

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

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

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

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

7.5. Automatisiertes Erstellen von Paketlisten

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

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

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

   Speichern Sie die Verzeichnisstruktur in einer neuen Datei.

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

   Erstellen Sie eine leere pkg-plist-Datei:

 # :>pkg-plist

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

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

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

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

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

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

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

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

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

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

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

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

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

                      Kapitel 8. Die pkg-* Dateien

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

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

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

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

9.2. Portlint

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

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

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

9.3. Port Tools

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

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

 # port test /usr/ports/net/csup

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

9.4. PREFIX und DESTDIR

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

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

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

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

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

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

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

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

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

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

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

   anstatt -DPAGER=\"/usr/local/bin/less\". Somit ist die
   Wahrscheinlichkeit ho:her, dass es auch funktioniert, wenn der
   Administrator den ganzen /usr/local-Baum an eine andere Stelle
   verschoben hat.

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

9.5. Die Tinderbox

   Wenn Sie ein begeisterter Ports-Entwickler sind mo:chten Sie
   vielleicht einen Blick auf die Tinderbox werfen. Es ist ein
   leistungsstarkes System zur Erstellung und zum Testen von Ports,
   welches auf Skripten basiert, die auf Pointyhat verwendet werden.
   Sie ko:nnen Tinderbox installieren, indem Sie den Port
   ports-mgmt/tinderbox benutzen. Bitte lesen Sie die mitgelieferte
   Dokumentation gru:ndlich, da die Konfiguration nicht einfach ist.

   Um Na:heres daru:ber zu erfahren, besuchen Sie bitte die Tinderbox
   Homepage.

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

           Kapitel 10. Einen existierenden Port aktualisieren

   Wenn Sie feststellen, dass ein Port verglichen mit der neuesten
   Version des Originalautors nicht mehr auf dem aktuellen Stand ist,
   sollten Sie als Erstes sicherstellen, dass Sie die aktuellste
   Version des Ports haben. Diese finden Sie im Verzeichnis
   ports/ports-current der FreeBSD FTP-Spiegelseiten. Wenn Sie
   allerdings mit mehr als ein paar Ports arbeiten, werden Sie es
   wahrscheinlich einfacher finden CVSup zu benutzen, um Ihre gesamte
   Ports-Sammlung aktuell zu halten, wie es im Handbuch beschrieben
   wird. Das hat zusa:tzlich den Vorteil, dass Sie so auch alle
   Abha:ngigkeiten des Ports aktuell halten.

   Der na:chste Schritt besteht darin festzustellen, ob bereits eine
   Aktualisierung des Ports darauf wartet committet zu werden. Um das
   sicherzustellen haben Sie folgende Mo:glichkeiten. Es gibt eine
   durchsuchbare Schnittstelle zur FreeBSD Problembericht Datenbank
   (PR - Problem Report) (auch bekannt als GNATS). Wa:hlen Sie dazu
   Ports im Drop-Down-Menu: und geben Sie den Namen des Ports ein.

   Allerdings wird manchmal vergessen den Namen des Ports eindeutig
   im Feld fu:r die Zusammenfassung anzugeben. In diesem Fall ko:nnen
   Sie das FreeBSD Ports Monitoring System (auch bekannt als
   portsmon) nutzen. Dieses versucht PRs von Ports nach Portname zu
   sortieren. Um PRs nach einem bestimmten Port zu durchsuchen
   ko:nnen Sie die U:bersicht eines Ports verwenden.

   Wenn es keine wartenden PRs gibt, ist der na:chste Schritt eine
   E-Mail an den Maintainer des Ports zu schicken, wie von make
   maintainer gezeigt wird. Diese Person arbeitet vielleicht schon an
   einer Aktualisierung, oder hat einen guten Grund den Port im
   Moment nicht zu aktualisieren (z.B. wegen Stabilita:tsproblemen
   der neuen Version). Sie wollen sicher nicht die Arbeit des
   Maintainers doppelt machen. Beachten Sie bitte, dass fu:r Ports
   ohne Maintainer ports@FreeBSD.org eingetragen ist. Das ist nur die
   allgemeine FreeBSD ports-Mailingliste, deshalb wird es in diesem
   Fall wahrscheinlich nicht helfen eine E-Mail dorthin zu schicken.

   Wenn Sie der Maintainer bittet die Aktualisierung zu erledigen,
   oder falls es keinen Maintainer gibt, haben Sie Gelegenheit,
   FreeBSD zu helfen, indem Sie die Aktualisierung selbst
   bereitstellen. Dazu verwenden Sie diff(1), das bereits im
   Basissystem enthalten ist.

   Um einen brauchbaren diff fu:r einen einzelne Datei zu erstellen,
   kopieren Sie die zu patchende Datei nach dateiname.orig und
   speichern Ihre A:nderungen in die Datei dateiname. Danach erzeugen
   Sie den Patch:

 % /usr/bin/diff dateiname.orig dateiname > dateiname.diff

   Soll mehr als eine Datei gepatcht werden, ko:nnen Sie entweder cvs
   diff verwenden (siehe dazu Abschnitt 10.1) oder Sie kopieren den
   kompletten Port in ein neues Verzeichnis und speichern die Ausgabe
   des rekursiven diff(1) auf das neue und alte Portverzeichniss
   (wenn Ihr vera:ndertes Portverzeichnis z.B. superedit und das
   Original superedit.bak heisst, dann speichern Sie bitte die
   Ergebnisse von diff -ruN superedit.bak superedit). Sowohl
   vereinheitlichendes als auch kontextabha:ngiges diff (Auflistung
   der Unterschiede zweier Dateien) sind akzeptabel, aber im
   Allgemeinen bevorzugen Port-Committer vereinheitlichende diffs.
   Bitte beachten Sie die Verwendung der -N-Option. Dies ist der
   gebra:uchliche Weg diff dazu zu bewegen korrekt damit umzugehen,
   neue Dateien anzulegen und alte zu lo:schen. Bevor Sie das diff
   einsenden u:berpru:fen Sie bitte die Ausgabe, um sicherzugehen,
   dass die A:nderungen sinnvoll sind. Stellen Sie insbesondere
   sicher, dass Sie das Arbeitsverzeichnis mit make clean aufgera:t
   haben).

   Um ga:ngige Operationen mit Korrekturdateien zu vereinfachen,
   ko:nnen Sie /usr/ports/Tools/scripts/patchtool.py benutzen. Aber
   lesen Sie bitte vorher /usr/ports/Tools/scripts/README.patchtool.

   Falls der Port keinen Maintainer hat und Sie ihn selbst aktiv
   benutzen, ziehen Sie bitte in Erwa:gung sich als Maintainer zu
   melden. FreeBSD hat mehr als 4000 Ports ohne Maintainer und in
   diesem Bereich werden immer zusa:tzliche Freiwillige beno:tigt
   (Fu:r eine ausfu:hrliche Beschreibung der Verantwortlichkeiten
   eines Maintainers lesen Sie bitte im   Developer's Handbook nach).

   Der beste Weg uns das diff zu schicken ist mittels send-pr(1)
   (Kategorie Ports). Wenn Sie der Maintainer des Ports sind, fu:gen
   Sie bitte [maintainer update] an den Anfang Ihrer Zusammenfassung
   und setzen Sie die ``Klasse'' des PR auf maintainer-update.
   Ansonsten sollte die ``Klasse'' des PR change-request sein. Bitte
   erwa:hnen Sie alle hinzugefu:gten oder gelo:schten Dateien in der
   Nachricht, da diese beim Commit ausdru:cklich an cvs(1) u:bergeben
   werden mu:ssen. Wenn das diff gro:sser ist als 20 Kilobyte
   komprimieren und uuencoden Sie es bitte. Ansonsten ko:nnen Sie es
   in den PR einfu:gen wie es ist.

   Bevor Sie den PR mit send-pr(1) abschicken, sollten Sie den
   Abschnitt Den Problembericht schreiben im Artikel u:ber
   Problemberichte lesen. Dieser entha:lt sehr viel mehr
   Informationen daru:ber, wie man nu:tzliche Problemberichte
   verfasst.

     Wichtig: Wenn Sie Ihre Aktualisierung aufgrund von
     Sicherheitsbedenken oder eines schwerwiegenden Fehlers
     bereitstellen wollen, informieren Sie bitte das Ports Management
     Team <portmgr@FreeBSD.org>, um einen sofortigen Rebuild und eine
     Neuverteilung des Pakets Ihres Ports durchzufu:hren. Sonst
     werden ahnungslose Nutzer von pkg_add(1) u:ber mehrere Wochen
     die alte Version durch pkg_add -r installieren.

     Anmerkung: Noch einmal: Bitte verwenden Sie diff(1) und nicht
     shar(1), um Aktualisierungen existierender Ports zu senden. Sie
     erleichtern es damit den Ports-Committern, Ihre A:nderungen
     nachzuvollziehen.

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

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

10.1. Patches mit CVS erstellen

   Wenn mo:glich, sollten Sie stets eine cvs(1)-Differenz einreichen.
   Diese sind leichter zu bearbeiten als Differenzen zwischen ``neuen
   und alten'' Verzeichnissen. Ausserdem ko:nenn Sie so einfacher
   feststellen, welche A:nderungen Sie vorgenommen haben oder Ihren
   Patch modifizieren, falls dies durch A:nderungen in einem anderen
   Bereich der Ports-Sammlung notwendig wird oder Sie vom Committer
   um eine Korrektur Ihres Patches gebeten werden.

 % cd ~/my_wrkdir (1)
 % cvs -d R_CVSROOT co pdnsd (2) (3)
 % cd ~/my_wrkdir/pdnsd

   (1)
           Das Verzeichnis, in dem Sie den Port bauen wollen. Dieses
           Arbeitsverzeichnis kann sich auch ausserhalb von
           /usr/ports/ befinden.
   (2)
           R_CVSROOT steht fu:r einen o:ffentlichen CVS-Server. Eine
           Liste aller verfu:gbaren Server finden Sie im FreeBSD
           Handbuch.
   (3)
           Ersetzen Sie ``pdnsd'' durch den Modulnamen des Ports.
           Dieser entspricht in der Regel dem Namen des Ports.
           Allerdings gibt es einige Ausnahmen von dieser Regel,
           insbesondere bei sprachspezifischen Ports (beispielsweise
           lautet der Modulname fu:r den Port german/selfhtml
           de-selfhtml). Um den Namen des Moduls herauszufinden,
           ko:nnen Sie entweder die cvsweb-Schnittstelle verwenden
           oder den kompletten Pfad des Ports angeben (in unserem
           Beispiel wa:re der komplette Pfad also ports/dns/pdnsd).

   Danach modifizieren Sie den Port in gewohnter Weise. Falls Sie
   Dateien hinzufu:gen oder entfernen, sollten Sie dies mit cvs
   protokollieren:

 % cvs add new_file
 % cvs remove deleted_file

   U:berpru:fen Sie die Funktion Ihres Ports anhand der Checklisten
   in Abschnitt 3.4 und Abschnitt 3.5.

 % cvs status
 % cvs update (1)

   (1)
           Dadurch wird versucht, die Differenz zwischen Ihrer
           gea:nderten Version und dem aktuellen Stand im CVS zu
           kombinieren. Achten Sie dabei unbedingt auf die Ausgabe
           dieses Befehls. Vor jeder Datei wird ein Buchstabe
           angezeigt, der Ihnen mitteilt, was mit dieser Datei
           passiert ist. Eine vollsta:ndige Liste dieser Pra:fixe
           finden Sie in Tabelle 10-1.

   Tabelle 10-1. Von cvs update verwendete Pra:fixe

   U Die Datei wurde aktualisiert. Es traten dabei keine Probleme     
     auf.                                                             
     Die Datei wurde ohne Probleme aktualisiert (dieses Pra:fix wird  
   P nur verwendet, wenn Sie mit einem entfernten Repository          
     arbeiten).                                                       
   M Die Datei wurde modifiziert. Es traten keine Konflikte auf.      
     Die Datei wurde modifiziert, allerdings kam es dabei zu          
   C Konflikten zwischen Ihrer gea:nderten Version und der aktuellen  
     Version im CVS.                                                  

   Wird das Pra:fix C nach einem cvs update angezeigt, bedeutet dies,
   dass im CVS etwas gea:ndert wurde und cvs(1) daher nicht in der
   Lage war, Ihre A:nderungen und die A:nderungen im CVS zu
   kombinieren. Es ist immer sinnvoll, sich die A:nderungen
   anzusehen, da cvs keine Informationen daru:ber hat, wie ein Port
   aufgebaut sein soll. Es kann (und wird wahrscheinlich) daher
   vorkommen, dass sich manchmal A:nderungen ergeben, die keinen Sinn
   machen.

   Im letzten Schritt erzeugen Sie einen ``unified diff(1)'' gegen
   die derzeit im CVS vorhandenen Dateien:

 % cvs diff -uN > ../`basename ${PWD}`.diff

     Anmerkung: Verwenden Sie unbedingt die Option -N, um
     sicherzustellen, dass von hinzugefu:gte oder gelo:schte Dateien
     im Patch erfasst sind. Der Patch entha:t auch von Ihnen
     gelo:schte Dateien (allerdings ohne Inhalt). Dies ist wichtig,
     da nur so der Committer wissen kann, welche Dateien er entfernen
     muss.

   Zuletzt reichen Sie Ihren Patch ein, indem Sie der Anleitung in
   Kapitel 10 folgen.

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

10.2. Die Dateien UPDATING und MOVED

   Wenn die Aktualisierung des Ports spezielle Schritte wie die
   Anpassung von Konfigurationsdateien oder die Ausfu:hrung eines
   speziellen Programms erfordert, sollten Sie diesen Umstand in der
   Datei /usr/ports/UPDATING dokumentieren. Eintra:ge in dieser Datei
   haben das folgende Format:

 YYYYMMDD:
   AFFECTS: users of portcategory/portname
   AUTHOR: Your name <Your email address>

   Special instructions

   Wenn Sie exakte Portmaster oder Portupgrade-Meldungen einfu:gen
   wollen, stellen Sie bitte sicher, dass alle Sonderzeichen korrekt
   dargestellt werden.

   Wurde der Port gelo:scht oder umbenannt, sollten Sie dies in der
   Datei /usr/ports/MOVED vermerken. Eintra:ge in dieser Datei haben
   das folgende Format:

 old name|new name (blank for deleted)|date of move|reason

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

                    Kapitel 11. Sicherheit der Ports

11.1. Warum Sicherheit so wichtig ist

   Es finden sich immer wieder Fehler in Software. Die
   gefa:hrlichsten davon sind wohl jene, die Sicherheitslu:cken
   o:ffnen. Technisch gesehen mu:ssen diese Lu:cken geschlossen
   werden, indem die Fehler, die Sie verursacht haben, beseitigt
   werden. Aber die Vorgehensweisen, wie mit blossen Fehlern und
   Sicherheitslu:cken umgegangen wird, sind sehr unterschiedlich.

   Ein typischer kleiner Fehler betrifft nur Nutzer, die eine
   bestimmte Kombination von Optionen aktiviert haben, die den Fehler
   auslo:st. Der Entwickler wird letztendlich einen Patch
   herausgeben, gefolgt von einer neuen Version des Programms, die
   den Fehler nicht mehr entha:lt - jedoch wird die Mehrheit der
   Nutzer nicht sofort aktualisieren, da sie von diesem Fehler nicht
   betroffen sind. Ein kritischer Fehler, der zu Datenverlust fu:hren
   kann, stellt ein schwerwiegendes Problem dar. Dennoch sind sich
   umsichtige Nutzer bewusst, dass Datenverlust verschiedene
   Ursachen - neben Softwarefehlern - haben kann, und machen deshalb
   Sicherungskopien wichtiger Daten. Zumal ein kritischer Fehler sehr
   schnell entdeckt wird.

   Bei einer Sicherheitslu:cke ist dies ganz anders. Erstens wird sie
   vielleicht jahrelang nicht entdeckt, da dies oftmals keine
   Fehlfunktion im Programm verursacht. Zweitens kann eine
   bo:swillige Person unerlaubten Zugriff auf ein unsicheres System
   erlangen, um empfindliche Daten zu vera:ndern oder zu zersto:ren;
   im schlimmsten Fall findet der Nutzer nicht einmal die Ursache des
   Schadens. Drittens hilft der Zugriff auf ein unsicheres System dem
   Angreifer oft in ein anderes System einzudringen, welches
   ansonsten nicht gefa:hrdet wa:re. Deshalb reicht es nicht aus eine
   Sicherheitslu:cke nur zu schliessen: Die Zielgruppe sollte
   mo:glichst genau und umfassend daru:ber informiert werden, damit
   sie die Gefahr einscha:tzen und passende Massnahmen ergreifen
   ko:nnen.

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

11.2. Sicherheitslu:cken schliessen

   Bei Ports und Paketen kann eine Sicherheitslu:cke im
   urspru:nglichen Programm oder in den Port-Dateien verursacht
   werden. Im ersten Fall wird der urspru:ngliche Entwickler den
   Fehler wahrscheinlich umgehend korrigieren oder eine neue Version
   herausgeben und Sie mu:ssen den Port nur aktualisieren und die
   Korrekturen des Autors beachten. Falls sich die Korrektur aus
   irgendeinem Grund verzo:gert, sollten Sie den Port als FORBIDDEN
   markieren oder selbst den Fehler fu:r den Port korrigieren. Falls
   die Sicherheitslu:cke im Port verursacht wird, sollten Sie ihn
   sobald wie mo:glich berichtigen. In jedem Fall sollte die
   Standardvorgehensweise zum Einreichen von A:nderungen beachtet
   werden - es sei denn, Sie haben das Recht diese direkt in den
   Ports-Baum zu committen.

     Wichtig: Ports-Committer zu sein ist nicht genug, um A:nderungen
     an einem beliebigen Port zu committen. Bitte denken Sie daran,
     dass Ports u:blicherweise Maintainer haben, die Sie respektieren
     sollten.

   Bitte stellen Sie sicher, dass die Revision des Ports erho:ht
   wird, sobald die Sicherheitslu:cke geschlossen wurde. Dadurch
   sehen die Nutzer, die installierte Pakete regelma:ssig
   aktualisieren, dass es an der Zeit ist eine Aktualisierung
   durchzufu:hren. Ausserdem wird ein neues Paket gebaut, u:ber
   FTP- und WWW-Spiegel verteilt und die unsichere Version damit
   verdra:ngt. PORTREVISION sollte erho:ht werden - es sei denn,
   PORTREVISION hat sich im Laufe der Korrektur des Fehlers
   gea:ndert. Das heisst, Sie sollten PORTREVISION erho:hen, wenn Sie
   eine Korrektur hinzugefu:gt haben. Sie sollten diese aber nicht
   erho:hen, wenn Sie den Port auf die neueste Version des Programms
   gebracht haben und PORTREVISION somit schon vera:ndert wurde.
   Bitte beachten Sie den betreffenden Abschnitt fu:r weitere
   Informationen.

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

11.3. Die Community informiert halten

  11.3.1. Die VuXML-Datenbank

   Ein sehr wichtiger und dringender Schritt, den man unternehmen
   muss, sobald eine Sicherheitslu:cke entdeckt wurde, ist die
   Gemeinschaft der Anwender des Ports u:ber die Gefahr zu
   informieren. Diese Benachrichtigung hat zwei Gru:nde. Erstens wird
   es sinnvoll sein, wenn die Gefahr wirklich so gross ist, sofort
   Abhilfe zu schaffen, indem man z.B. den betreffenden
   Netzwerkdienst beendet oder den Port komplett deinstalliert, bis
   die Lu:cke geschlossen wurde. Und Zweitens pflegen viele Nutzer
   installierte Pakete nur gelegentlich zu aktualisieren. Sie werden
   aus der Mitteilung erfahren, dass Sie das Paket, sobald eine
   Korrektur verfu:gbar ist, sofort aktualisieren mu:ssen.

   Angesichts der riesigen Zahl an Ports kann nicht fu:r jeden
   Vorfall ein Sicherheitshinweis erstellt werden, ohne durch die
   Flut an Nachrichten die Aufmerksamkeit der Empfa:nger zu
   verlieren, im Laufe der Zeit kommt es so zu ernsten Problemen.
   Deshalb werden Sicherheitslu:cken von Ports in der FreeBSD
   VuXML-Datenbank aufgezeichnet. Das Team der
   Sicherheitsverantwortlichen beobachtet diese wegen
   Angelegenheiten, die Ihr Eingreifen erfordern.

   Wenn Sie Committerrechte haben, ko:nnen Sie die VuXML-Datenbank
   selbst aktualisieren. Auf diese Weise helfen Sie den
   Sicherheitsverantwortlichen und liefern die kritischen
   Informationen fru:hzeitig an die Community. Aber auch wenn Sie
   kein Committer sind und glauben, Sie haben eine aussergewo:hnlich
   schwerwiegende Lu:cke gefunden - egal welche - zo:gern Sie bitte
   nicht die Sicherheitsverantwortlichen zu kontaktieren, wie es in
   den FreeBSD Sicherheitsinformationen beschrieben wird.

   Wie vielleicht aus dem Titel hervorgeht, handelt es sich bei der
   VuXMl-Datenbank um ein XML-Dokument. Die Quelldatei vuln.xml
   ko:nnen Sie im Port security/vuxml finden. Deshalb wird der
   komplette Pfadname   PORTSDIR/security/vuxml/vuln.xml lauten.
   Jedes Mal, wenn Sie eine Sicherheitslu:cke in einem Port
   entdecken, fu:gen Sie bitte einen Eintrag dafu:r in diese Datei
   ein. Solange Sie nicht mit VuXML vertraut sind, ist es das Beste,
   was Sie machen ko:nnen, einen vorhandenen Eintrag, der zu Ihrem
   Fall passt, zu kopieren und als Vorlage zu verwenden.

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

  11.3.2. Eine kurze Einfu:hrung in VuXML

   Das komplette XML ist komplex und wu:rde den Rahmen dieses Buches
   sprengen. Allerdings beno:tigen Sie fu:r einen grundlegenden
   Einblick in die Struktur eines VuXML-Eintrags nur eine Vorstellung
   der Tags. XML-Tags bestehen aus Namen, die in spitzen Klammern
   eingeschlossen sind. Zu jedem o:ffnenden <Tag> muss ein passendes
   </Tag> existieren. Tags ko:nnen geschachtelt werden. Wenn sie
   geschachtelt werden mu:ssen die inneren Tags vor den A:usseren
   geschlossen werden. Es gibt eine Hierarchie von Tags - das heisst
   komplexere Regeln zur Schachtelung. Klingt so a:hnlich wie HTML,
   oder? Der gro:sste Unterschied ist: XML ist erweiterbar
   (eXtensible) - das heisst es basiert darauf massgeschneiderte Tags
   zu definieren. Aufgrund seiner wesentlichen Struktur bringt XML
   ansonsten formlose Daten in eine bestimmte Form. VuXML ist
   speziell darauf zugeschnitten Beschreibungen von
   Sicherheitslu:cken zu verwalten.

   Lassen Sie uns nun einen realistischen VuXML-Eintrag betrachten:

 <vuln vid="f4bc80f4-da62-11d8-90ea-0004ac98a7b9"> (1)
   <topic>Several vulnerabilities found in Foo</topic> (2)
   <affects>
     <package>
       <name>foo</name> (3)
       <name>foo-devel</name>
       <name>ja-foo</name>
       <range><ge>1.6</ge><lt>1.9</lt></range> (4)
       <range><ge>2.*</ge><lt>2.4_1</lt></range>
       <range><eq>3.0b1</eq></range>
     </package>
     <package>
       <name>openfoo</name> (5)
       <range><lt>1.10_7</lt></range> (6)
       <range><ge>1.2,1</ge><lt>1.3_1,1</lt></range>
     </package>
   </affects>
   <description>
     <body xmlns="http://www.w3.org/1999/xhtml">
       <p>J. Random Hacker reports:</p> (7)
       <blockquote
         cite="http://j.r.hacker.com/advisories/1">
         <p>Several issues in the Foo software may be exploited
           via carefully crafted QUUX requests.  These requests will
           permit the injection of Bar code, mumble theft, and the
           readability of the Foo administrator account.</p>
       </blockquote>
     </body>
   </description>
   <references> (8)
     <freebsdsa>SA-10:75.foo</freebsdsa> (9)
     <freebsdpr>ports/987654</freebsdpr> (10)
     <cvename>CAN-2010-0201</cvename> (11)
     <cvename>CAN-2010-0466</cvename>
     <bid>96298</bid> (12)
     <certsa>CA-2010-99</certsa> (13)
     <certvu>740169</certvu> (14)
     <uscertsa>SA10-99A</uscertsa> (15)
     <uscertta>SA10-99A</uscertta> (16)
     <mlist msgid="201075606@hacker.com">http://marc.theaimsgroup.com/?l=bugtraq&amp;m=203886607825605</mlist> (17)
     <url>http://j.r.hacker.com/advisories/1</url> (18)
   </references>
   <dates>
     <discovery>2010-05-25</discovery> (19)
     <entry>2010-07-13</entry> (20)
     <modified>2010-09-17</modified> (21)
   </dates>
 </vuln>

   Die Namen der Tags sollten selbsterkla:rend sein  - also werfen
   wir einen genaueren Blick auf die Felder, die Sie selbst
   ausfu:llen mu:ssen:

   (1)
           Dies ist die ho:chste Tag-Ebene eines VuXML-Eintrags. Es
           ist ein vorgeschriebenes Attribut vid, welches eine
           allgemein einzigartige Kennung (universally unique
           identifier, UUID) in Anfu:hrungszeichen fu:r diesen
           Eintrag festlegt. Sie sollten eine UUID fu:r jeden neuen
           VuXML-Eintrag erzeugen (und vergessen Sie nicht die UUID
           der Vorlage zu ersetzen, es sei denn, Sie schreiben den
           Eintrag von Grund auf selbst). Sie ko:nnen uuidgen(1)
           verwenden, um eine VuXML UUID zu erzeugen.
   (2)
           Dies ist eine einzeilige Beschreibung des gefundenen
           Fehlers.
   (3)
           Hier werden die Namen betroffener Pakete aufgefu:hrt. Es
           ko:nnen mehrere Namen angegeben werden, da mehrere Pakete
           von einem einzigen Master-Port oder Software-Produkt
           abha:ngen ko:nnen. Das schliesst Stable- und
           Developement-Zweige, lokalisierte Versionen und
           Slave-Ports ein, die verschiedene Auswahlmo:glichkeiten
           wichtiger Kompilierungszeit-Optionen bieten.

             Wichtig: Es liegt in Ihrer Verantwortung all diese
             betroffenen Pakete zu finden, wenn Sie den VuXML-Eintrag
             schreiben.Behalten Sie im Hinterkopf, dass make search
             name=foo Ihr Freund ist. Die wichtigsten Punkte, auf die
             Sie achten sollten, sind die folgenden:

                * die foo-devel Variante eines foo Ports;

                * andere Varianten mit einem Suffix wie -a4 (fu:r
                  Druck-betreffende Pakete), -without-gui (fu:r
                  Pakete mit deaktivierter X-Unterstu:tzung) oder
                  a:hnliche

                * jp-, ru-, zh- und andere, eventuell lokalisierte,
                  Varianten in den entsprechenden La:nderkategorien
                  der Ports-Sammlung

   (4)
           Betroffene Versionen der Pakete werden hier als ein
           Bereich oder mehrere durch eine Kombination aus <lt>, <le>
           , <eq>,   <ge>, und <gt>-Elementen ausgegeben. Die
           angegebenen Bereiche sollten sich nicht u:berschneiden.

           In einer Bereichsangabe steht * (Asterisk) fu:r die
           kleinste Versionsnummer. Insbesondere ist 2.* kleiner als
           2.a. Deshalb kann ein Stern benutzt werden, um auf alle
           mo:glichen Alpha -, Beta- und RC -Versionen zuzutreffen.
           Zum Beispiel passt <ge>2.*</ge><lt>3.* </lt> auf alle
           Versionen der Form 2.x, wa:hrend <ge> 2.0</ge><lt>3.0</lt>
           das nicht erfu:llt, da es nicht auf 2.r3 passt, auf 3.b
           aber schon.

           Das obige Beispiel legt fest, dass Versionen von 1.6 bis
           1.9 betroffen sind - ausserdem Versionen 2.x vor 2.4_1 und
           Version 3.0b1.

   (5)
           Mehrere zusammenha:ngende Gruppen von Paketen (im
           wesentlichen Ports) ko:nnen im Abschnitt <affected>
           aufgefu:hrt werden. Das kann man benutzen, wenn sich
           Programme (sagen wir FooBar, FreeBar und OpenBar)
           denselben Quelltext als Grundlage haben und sich noch
           dessen Fehler und Sicherheitslu:cken teilen. Beachten Sie
           den Unterschied zum Anfu:hren mehrerer Namen innerhalb
           eines <package> Abschnittes.
   (6)
           Die Versionsbereiche sollten, wenn mo:glich, sowohl
           PORTEPOCH als auch   PORTREVISION erlauben. Bitte denken
           Sie daran, dass gema:ss der Vergleichsregeln eine Version
           mit einer PORTEPOCH, die nicht Null ist, gro:sser ist als
           jede Version ohne PORTEPOCH. Das heisst, 3.0,1 ist
           gro:sser als 3.1 oder sogar 8.9.
   (7)
           Das ist die Zusammenfassung des Problems. In diesem Feld
           wird XHTML verwendet. Zumindest umschliessende <p> und
           </p> sollten auftauchen. Komplexere Tags sind zwar
           mo:glich, aber sollten nur um der Genauigkeit und Klarheit
           willen verwendet werden: Bitte verwenden Sie hier kein
           Eye-Candy.
   (8)
           Dieser Abschnitt entha:lt Verweise auf relevante
           Dokumente. Es wird empfohlen so viele Referenzen wie
           no:tig aufzufu:hren.
   (9)
           Das ist ein FreeBSD Sicherheitshinweis.
   (10)
           Das ist ein   FreeBSD Problembericht.
   (11)
           Das ist eine Mitre CVE Kennung.
   (12)
           Das ist eine SecurityFocus Fehler-Kennung.
   (13)
           Das ist ein Sicherheitshinweis von US-CERT.
   (14)
           Das ist eine Mitteilung u:ber eine Schwachstelle von
           US-CERT.
   (15)
           Das ist ein Cyber-Sicherheitsalarm von US-CERT.
   (16)
           Das ist ein technischer Cyber-Sicherheitsalarm von
           US-CERT.
   (17)
           Das ist eine URL zu einem archivierten Posting auf einer
           Mailingliste. Das Attribut msgid ist optional und gibt die
           Nachrichtenkennung des Postings an.
   (18)
           Das ist eine gewo:hnliche URL. Sie sollte nur verwendet
           werden, wenn keine der anderen Referenzkategorien
           verfu:gbar ist.
   (19)
           Das ist das Datum, an dem die Sicherheitslu:cke bekannt
           wurde (JJJJ-MM-TT).
   (20)
           Das ist das Datum, an dem der Eintrag hinzugefu:gt wurde
           (JJJJ-MM-TT).
   (21)
           Das ist das Datum, an dem zuletzt irgendeine Information
           des Eintrags vera:ndert wurde (JJJJ-MM-TT). Neue Eintra:ge
           du:rfen dieses Feld nicht enthalten. Es sollte beim
           Editieren eines existierenden Eintrags eingefu:gt werden.

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

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

   Nehmen wir an, Sie haben gerade einen Eintrag fu:r eine
   Sicherheitslu:cke in dem Paket clamav geschrieben oder
   ausgefu:llt, die in der Version 0.65_7 korrigiert wurde.

   Als Voraussetzung mu:ssen Sie die aktuellen Versionen der Ports
   ports-mgmt/portaudit, ports-mgmt/portaudit-db sowie security/vuxml
   installieren.

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

     Durch Setzen der Umgebungsvariable DATABASEDIR ko:nnen Sie hier
     auch ein anderes Verzeichnis angeben.

     Arbeiten Sie nicht aus dem Verzeichnis
     ${PORTSDIR}/security/vuxml heraus, mu:ssen Sie zusa:tzlich die
     Umgebungsvariable VUXMLDIR setzen, um anzugeben, in welchem
     Verzeichnis sich die Datei vuln.xml befindet.

   Zuerst u:berpru:fen Sie bitte, ob bereits ein Eintrag fu:r diese
   Schwachstelle existiert. Wenn es einen solchen Eintrag gibt,
   sollte er auf die vorige Version 0.65_6 zutreffen:

 % packaudit
 % portaudit clamav-0.65_6

   Wenn keine vorhandenen Eintra:ge gefunden werden haben Sie gru:nes
   Licht, einen neuen Eintrag fu:r diese Sicherheitslu:cke anzulegen.
   Sie ko:nnen nun eine neue UUID erzeugen (wir nehmen an, diese
   lautet 74a9541d-5d6c-11d8-80e3-0020ed76ef5a) und einen neuen
   Eintrag in der VuXML-Datenbank anlegen. Bitte u:berpru:fen Sie
   danach die Syntax mit folgendem Befehl:

 % cd ${PORTSDIR}/security/vuxml && make validate

     Anmerkung: Sie werden zumindest eines der folgenden Pakete
     beno:tigen: textproc/libxml2, textproc/jade.

   Jetzt bauen Sie bitte die portaudit-Datenbank aus der VuXML-Datei
   neu:

 % packaudit

   Um sicherzustellen, dass der Abschnitt <affected> Ihres Eintrags
   die richtigen Pakete betrifft, verwenden Sie bitte den folgenden
   Befehl:

 % portaudit -f /usr/ports/INDEX -r 74a9541d-5d6c-11d8-80e3-0020ed76ef5a

     Anmerkung: Bitte lesen Sie in portaudit(1) nach, um ein besseres
     Versta:ndnis der Befehlssyntax zu entwickeln.

   Bitte stellen Sie sicher, dass Ihr Eintrag keine falschen Treffer
   in der Ausgabe erzeugt.

   Jetzt u:berpru:fen Sie bitte, dass Ihr Eintrag die richtigen
   Versionen des Pakets angibt:

 % portaudit clamav-0.65_6 clamav-0.65_7
 Affected package: clamav-0.65_6 (matched by clamav<0.65_7)
 Type of problem: clamav remote denial-of-service.
 Reference: <http://www.freebsd.org/ports/portaudit/74a9541d-5d6c-11d8-80e3-0020ed76ef5a.html>

 1 problem(s) found.

   Offensichtlich sollte die erste Version ausgegeben werden - die
   zweite jedoch nicht.

   Abschliessend u:berpru:fen Sie bitte, ob die Webseite, die aus der
   VuXML-Datenbank erzeugt wird, wie erwartet aussieht:

 % mkdir -p ~/public_html/portaudit
 % packaudit
 % lynx ~/public_html/portaudit/74a9541d-5d6c-11d8-80e3-0020ed76ef5a.html

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

         Kapitel 12. Was man machen respektive vermeiden sollte

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                       
400004     5. April 1999      __deregister_frame_info Fehlerbehebung     
                              fu:r den dynamischen Linker (auch          
                              4.0-CURRENT nach EGCS 1.1.2 Integration).  
400005     27. April 1999     4.0-CURRENT nach suser(9) API A:nderung    
                              (auch 4.0-CURRENT nach newbus).            
400006     31. Mai 1999       4.0-CURRENT nach A:nderung der             
                              cdevsw-Registrierung.                      
                              4.0-CURRENT nach Hinzufu:gen von so_cred   
400007     17. Juni 1999      fu:r Zugangsberechtigungen auf             
                              Socket-Ebene.                              
400008     20. Juni 1999      4.0-CURRENT nach Hinzufu:gen eines poll    
                              Syscall-Wrappers zur libc_r.               
400009     20. Juli 1999      4.0-CURRENT nach der A:nderung des Kernel  
                              dev_t-Typs zum struct specinfo-Zeiger.     
400010     25. September 1999 4.0-CURRENT nach dem Beseitigen eines      
                              Fehlers in jail(2).                        
400011     29. September 1999 4.0-CURRENT nach der sigset_t Datentyp     
                              A:nderung.                                 
400012     15. November 1999  4.0-CURRENT nach dem Wechsel zum GCC       
                              2.95.2-Compiler.                           
400013     4. Dezember 1999   4.0-CURRENT nach Hinzufu:gen der           
                              erweiterbaren Linux Mode ioctl-Routinen.   
400014     18. Januar 2000    4.0-CURRENT nach dem OpenSSL-Import.       
                              4.0-CURRENT nach der C++ ABI A:nderung in  
400015     27. Januar 2000    GCC 2.95.2 von -fvtable-thunks zu          
                              -fno-vtable-thunks als Standard.           
400016     27. Februar 2000   4.0-CURRENT nach OpenSSH-Import.           
400017     13. Ma:rz 2000     4.0-RELEASE                                
400018     17. Ma:rz 2000     4.0-STABLE nach 4.0-RELEASE                
400019     5. Mai 2000        4.0-STABLE nach der Einfu:hrung von        
                              verzo:gerten Pru:fsummen.                  
400020     4. Juni 2000       4.0-STABLE nach dem Einpflegen des         
                              libxpg4-Quelltextes in die libc.           
                              4.0-STABLE nach der Aktualisierung von     
400021     8. Juli 2000       Binutils auf 2.10.0, A:nderungen der       
                              bina:ren ELF-Markierungen, Aufnahme von    
                              tcsh ins Basissystem.                      
410000     14. Juli 2000      4.1-RELEASE                                
410001     29. Juli 2000      4.1-STABLE nach 4.1-RELEASE                
410002     16. September 2000 4.1-STABLE nachdem setproctitle(3) von der 
                              libutil in die libc verschoben wurde.      
411000     25. September 2000 4.1.1-RELEASE                              
411001                        4.1.1-STABLE nach 4.1.1-RELEASE            
420000     31. Oktober 2000   4.2-RELEASE                                
                              4.2-STABLE nach Kombinaion von libgcc.a    
420001     10. Januar 2001    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 sendmail_enable     
450004     16. April 2002     rc.conf(5) Variable gea:ndert worden ist,  
                              um den Wert NONE zu akzeptieren.           
450005     27. April 2002     4.5-STABLE nachdem XFree86 4 als Standard  
                              zum Bauen der Pakete benutzt wird.         
                              4.5-STABLE nach dem Reparieren des         
450006     1. Mai 2002        Empfangsfilters, welcher anfa:llig fu:r    
                              einfache DoS-Attacken war.                 
460000     21. Juni 2002      4.6-RELEASE                                
                              4.6-STABLE sendfile(2) repariert, um mit   
                              der Dokumentation u:bereinzustimmen, und   
460001     21. Juni 2002      nicht mehr die Anzahl der gesendeten       
                              Header mit der Anzahl der Daten, welche    
                              aus der Datei geschickt werden,            
                              gegenzurechnen.                            
460002     19. Juli 2002      4.6.2-RELEASE                              
460100     26. Juni 2002      4.6-STABLE                                 
460101     26. Juni 2002      4.6-STABLE nach dem Einfliessen von `sed   
                              -i' aus CURRENT.                           
                              4.6-STABLE nach dem Einfliessen von vielen 
460102     1. September 2002  neuen pkg_install-Funktionen aus HEAD      
                              (HEAD = die aktuellste und letzte Version  
                              des Quellverzeichnisbaumes).               
470000     8. Oktober 2002    4.7-RELEASE                                
470100     9. Oktober 2002    4.7-STABLE                                 
                              Beginn von generierten __std{in,out,err}p  
                              Referenzen statt __sF. Dies a:ndert        
470101     10. November 2002  std{in,out,err} von einem Ausdruck         
                              wa:hrend des Kompilierens zu einem         
                              Laufzeitausdruck.                          
                              4.7-STABLE nach dem Einfliessen von        
470102     23. Januar 2003    mbuf-A:nderungen, um m_aux mbufs mit denen 
                              von m_tag zu ersetzen                      
470103     14. Februar 2003   4.7-STABLE erha:lt OpenSSL 0.9.7           
480000     30. Ma:rz 2003     4.8-RELEASE                                
480100     5. April 2003      4.8-STABLE                                 
480101     22. Mai 2003       4.8-STABLE nachdem realpath(3)             
                              Thread-sicher gemacht wurde.               
480102     10. August 2003    4.8-STABLE A:nderung der 3ware-API in twe. 
490000     27. Oktober 2003   4.9-RELEASE                                
490100     27. Oktober 2003   4.9-STABLE                                 
490101     8. Januar 2004     4.9-STABLE nachdem e_sid zu der Struktur   
                              kinfo_eproc hinzugefu:gt wurde.            
490102     4. Februar 2004    4.9-STABLE nach dem Einfliessen der        
                              libmap-Funktionalita:t fu:r rtld.          
491000     25. Mai 2004       4.10-RELEASE                               
491100     1. Juni 2004       4.10-STABLE                                
                              4.10-STABLE nach dem Einfliessen von       
491101     11. August 2004    Revision 20040629 der Paket-Werkzeuge aus  
                              CURRENT.                                   
                              4.10-STABLE nach der Fehlerbehebung in der 
491102     16. November 2004  VM, um das Freigeben von fiktiven          
                              Speicherseiten korrekt zu handhaben.       
492000     17. Dezember 2004  4.11-RELEASE                               
492100     17. Dezember 2004  4.11-STABLE                                
                              4.11-STABLE nach dem Hinzufu:gen von       
492101     18. April 2006     libdata/ldconfig Verzeichnissen zu den     
                              mtree-Dateien.                             
500000     13. Ma:rz 2000     5.0-CURRENT                                
                              5.0-CURRENT nach Hinzufu:gen von           
500001     18. April 2000     zusa:tzlichen Feldern in den ELF-Headern   
                              und A:ndern der Methode zur ELF-Markierung 
                              von Bina:rdateien.                         
500002     2. Mai 2000        5.0-CURRENT nach kld-Metadaten             
                              A:nderungen.                               
500003     18. Mai 2000       5.0-CURRENT nach buf/bio A:nderungen.      
500004     26. Mai 2000       5.0-CURRENT nach binutils Aktualisierung.  
                              5.0-CURRENT nach dem Einfliessen des       
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.                    
500008     7. Juli 2000       5.0-CURRENT nach der Aktualisierung des    
                              KAME-Quelltextes zu den 2000/07-Quellen.   
500009     14. Juli 2000      5.0-CURRENT nach ether_ifattach() und      
                              ether_ifdetach() A:nderungen.              
                              5.0-CURRENT nachdem die mtree-Standards    
500010     16. Juli 2000      zuru:ck zur urspru:nglichen Variante       
                              gea:ndert wurden; -L hinzugefu:gt, um      
                              Symlinks zu folgen.                        
500011     18. Juli 2000      5.0-CURRENT nachdem die kqueue-API         
                              gea:ndert worden ist.                      
500012     2. September 2000  5.0-CURRENT nachdem setproctitle(3) von    
                              libutil nach libc verschoben worden ist.   
500013     10. September 2000 5.0-CURRENT nach dem ersten SMPng-Commit.  
500014     4. Januar 2001     5.0-CURRENT nachdem <sys/select.h> nach    
                              <sys/selinfo.h> verschoben worden ist.     
                              5.0-CURRENT nach dem Kombinieren von       
500015     10. Januar 2001    libgcc.a und libgcc_r.a und damit          
                              verbundene A:nderungen an GCC-Bindungen.   
                              5.0-CURRENT nach der A:nderung das         
500016     24. Januar 2001    Zusammenbinden von libc und libc_r zu      
                              erlauben, womit die -pthread Option        
                              veraltet ist.                              
                              5.0-CURRENT nach dem Umschalten von struct 
500017     18. Februar 2001   ucred zu struct xucred, um die vom Kernel  
                              exportierte API fu:r mount u.a.zu          
                              stabilisieren.                             
                              5.0-CURRENT nach dem Hinzufu:gen der       
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.        
500024     1. Oktober 2001    5.0-CURRENT nach d_thread_t, und nachdem   
                              UUCP in die Ports verschoben worden ist.   
                              5.0-CURRENT nach A:nderungen in der ABI    
500025     4. Oktober 2001    bei der Weitergabe von Deskriptoren und    
                              Berechtigungen auf 64 Bit Plattformen.     
                              5.0-CURRENT nachdem XFree86 4 als Standard 
500026     9. Oktober 2001    zum Erstellen der Pakete benutzt wird und  
                              die neue libc strnstr()-Funktion           
                              hinzugefu:gt wurde.                        
500027     10. Oktober 2001   5.0-CURRENT nachdem die neue libc          
                              strcasestr()-Funktion hinzugefu:gt wurde.  
                              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 im      
500029     29. Januar 2002    Ru:ckgabewert von sendfile(2) gemacht      
                              wurde.                                     
                              5.0-CURRENT nach der Einfu:hrung des Types 
500030     15. Februar 2002   fflags_t, welches die passende Gro:sse     
                              fu:r Dateiflags hat.                       
500031     24. Februar 2002   5.0-CURRENT nach der Umbenennung der USB   
                              elements-Struktur.                         
500032     16. Ma:rz 2002     5.0-CURRENT nach der Einfu:hrung von Perl  
                              5.6.1.                                     
                              5.0-CURRENT nachdem die sendmail_enable    
500033     3. April 2002      rc.conf(5) Variable gea:ndert worden ist,  
                              um den Wert NONE zu akzeptieren.           
500034     30. April 2002     5.0-CURRENT nachdem mtx_init() einen       
                              dritten Parameter entgegen nimmt.          
500035     13. Mai 2002       5.0-CURRENT mit GCC 3.1.                   
500036     17. Mai 2002       5.0-CURRENT ohne Perl in /usr/src          
500037     29. Mai 2002       5.0-CURRENT nach dem Hinzufu:gen von       
                              dlfunc(3)                                  
                              5.0-CURRENT nachdem die Typen von einigen  
500038     24. Juli 2002      Elementen der sockbuf-Struktur gea:ndert   
                              wurden und nachdem die Struktur neu        
                              geordnet wurde.                            
                              5.0-CURRENT nach dem GCC 3.2.1 Import. Und 
                              auch nachdem die Header nicht mehr         
                              _BSD_FOO_T_ sondern _FOO_T_DECLARED        
500039     1. September 2002  benutzen. Dieser Wert kann auch als        
                              konservative Scha:tzung fu:r den Beginn    
                              der Unterstu:tzung des bzip2(1) Pakets     
                              verwendet werden.                          
                              5.0-CURRENT nachdem verschiedene           
500040     20. September 2002 A:nderungen an Plattenfunktionen gemacht   
                              wurden, um die Anha:ngigkeit von Interna   
                              der disklabel-Struktur zu entfernen.       
500041     1. Oktober 2002    5.0-CURRENT nach dem Hinzufu:gen von       
                              getopt_long(3) zur libc.                   
                              5.0-CURRENT nach der Aktualisierung von    
500042     15. Oktober 2002   Binutils auf 2.13, bei denen die           
                              FreeBSD-Emulation, vec und das             
                              Ausgabeformat gea:ndert wurden.            
                              5.0-CURRENT nach dem Hinzufu:gen schwacher 
500043     1. November 2002   pthread_XXX Stubs zur libc, womit          
                              libXThrStub.so veraltet ist. 5.0-RELEASE.  
500100     17. Januar 2003    5.0-CURRENT nach dem Erstellen des         
                              RELENG_5_0-Zweiges                         
500101     19. Februar 2003   <sys/dkstat.h> ist leer und sollte nicht   
                              inkludiert werden.                         
500102     25. Februar 2003   5.0-CURRENT nach der A:nderung in der      
                              d_mmap_t-Schnittstelle.                    
                              5.0-CURRENT nachdem taskqueue_swi gea:dert 
500103     26. Februar 2003   wurde, um ohne Giant zu arbeiten, und      
                              taskqueue_swi_giant hinzugefu:gt wurde, um 
                              Giant zu verwenden.                        
                              cdevsw_add() und cdevsw_remove() gibt es   
500104     27. Februar 2003   nicht la:nger. Auftauchen der              
                              MAJOR_AUTO-Allokationsmo:glichkeit.        
500105     4. Ma:rz 2003      5.0-CURRENT nach der neuen                 
                              cdevsw-Initialisierungsmethode.            
500106     8. Ma:rz 2003      devstat_add_entry() wurde durch            
                              devstat_new_entry() ersetzt.               
500107     15. Ma:rz 2003     Devstat Schnittstellena:nderung; siehe     
                              sys/sys/param.h 1.149.                     
500108     15. Ma:rz 2003     Token-Ring Schnittstellena:nderungen.      
500109     25. Ma:rz 2003     Hinzufu:gen von vm_paddr_t.                
500110     28. Ma:rz 2003     5.0-CURRENT nachdem realpath(3)            
                              Thread-sicher gemacht wurde.               
500111     9. April 2003      5.0-CURRENT nachdem usbhid(3) mit NetBSD   
                              synchronisiert wurde.                      
                              5.0-CURRENT nach der neuen NSS             
500112     17. April 2003     Implementierung und Hinzufu:gen der        
                              POSIX.1 getpw*_r, getgr*_r Funktionen.     
500113     2. Mai 2003        5.0-CURRENT nach Entfernen des alten       
                              rc-Systems.                                
501000     4. Juni 2003       5.1-RELEASE.                               
501100     2. Juni 2003       5.1-CURRENT nach dem Erstellen des         
                              RELENG_5_1 Zweiges.                        
                              5.1-CURRENT nachdem die Semantik von       
501101     29. Juni 2003      sigtimedwait(2) and sigwaitinfo(2)         
                              korrigiert wurden.                         
                              5.1-CURRENT nach dem Hinzufu:gen der       
501102     3. Juli 2003       lockfunc und lockfuncarg-Felder zu         
                              bus_dma_tag_create(9).                     
501103     31. Juli 2003      5.1-CURRENT nach der Integration des GCC   
                              3.3.1-pre 20030711 Snapshots.              
501104     5. August 2003     5.1-CURRENT 3ware-API A:nderungen in twe.  
                              5.1-CURRENT Unterstu:tzung von dynamisch   
501105     17. August 2003    gebundenen /bin und /sbin und Verschieben  
                              von Bibliotheken nach /lib.                
                              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>     
501107     17. September 2003 nach <dev/ic/ns16550.h> verschoben wurden. 
                              Und nachdem die libmap Funktionalita:t     
                              vorbehaltlos vom rtld unterstu:tzt wurde.  
501108     23. September 2003 5.1-CURRENT nach Aktualisierung der        
                              PFIL_HOOKS API.                            
501109     27. September 2003 5.1-CURRENT nachdem kiconv(3) hinzugefu:gt 
                              wurde.                                     
                              5.1-CURRENT nachdem der standardma:ssige   
501110     28. September 2003 Ablauf von open und close in cdevsw        
                              gea:ndert wurde.                           
501111     16. Oktober 2003   5.1-CURRENT nachdem das Layout von cdevsw  
                              gea:ndert wurde.                           
501112     16. Oktober 2003   5.1-CURRENT nach dem Hinzufu:gen von       
                              Mehrfachvererbung in kobj.                 
501113     31. Oktober 2003   5.1-CURRENT nach der if_xname A:nderung in 
                              der Struktur ifnet                         
                              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 Standard-Thread    
502102     30. Januar 2004    Bibliothek von libc_r zu libpthread        
                              gea:ndert wurde.                           
502103     21. Februar 2004   5.2-CURRENT nach dem Gera:tetreiber API    
                              Megapatch.                                 
502104     25. Februar 2004   5.2-CURRENT nachdem getopt_long_only()     
                              hinzugefu:gt wurde.                        
                              5.2-CURRENT nachdem NULL fu:r C in ((void  
502105     5. Ma:rz 2004      *)0) gea:ndert wurde, was mehr Warnungen   
                              erzeugt.                                   
502106     8. Ma:rz 2004      5.2-CURRENT nachdem pf beim Bauen und      
                              Installieren mit eingebunden wird.         
                              5.2-CURRENT nachdem time_t auf der         
502107     10. Ma:rz 2004     sparc64-Plattform in einen 64-bit Wert     
                              gea:ndert wurde.                           
                              5.2-CURRENT nachdem sich die               
                              Unterstu:tzung 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() zwingend    
502113     4. Juni 2004       erforderlich fu:r serielle Treiber gemacht 
                              wurde.                                     
502114     13. Juni 2004      5.2-CURRENT nach dem Import des            
                              ALTQ-Frameworks.                           
                              5.2-CURRENT nachdem sema_timedwait(9)      
502115     14. Juni 2004      gea:ndert wurde, 0 bei Erfolg und einen    
                              von 0 verschiedenen Fehlercode im Falle    
                              eines Fehlers zuru:ckzuliefern.            
                              5.2-CURRENT nach dem A:ndern der Kernel    
502116     16. Juni 2004      Struktur dev_t, in ein Zeiger auf die      
                              Struktur cdev *                            
502117     17. Juni 2004      5.2-CURRENT nach dem A:ndern der           
                              Kernelstruktur udev_t in dev_t.            
                              5.2-CURRENT nachdem Unterstu:tzung fu:r    
502118     17. Juni 2004      CLOCK_VIRTUAL und CLOCK_PROF zu            
                              clock_gettime(2) und clock_getres(2)       
                              hinzugefu:gt wurde.                        
                              5.2-CURRENT nachdem die U:berpru:fung des  
502119     22. Juni 2004      Klonens von Netzwerk-Schnittstellen        
                              gea:ndert wurde.                           
502120     2. Juli 2004       5.2-CURRENT nach dem Einfliessen von       
                              Revision 20040629 der Paket-Werkzeuge.     
502121     9. Juli 2004       5.2-CURRENT nachdem Bluetooth-Quelltext    
                              als nicht i386-spezifisch markiert wurde.  
                              5.2-CURRENT nach der Einfu:hrung des KDB   
502122     11. Juli 2004      Debugger Frameworks, der Umwandlung des    
                              DDB in ein Backend und der Einfu:hrung des 
                              GDB-Backends.                              
                              5.2-CURRENT nachdem VFS_ROOT gea:ndert     
                              wurde, eine Struktur thread als Argument   
                              zu aktzeptieren, wie vflush. Die Struktur  
502123     12. Juli 2004      kinfo_proc entha:lt nun einen Zeiger auf   
                              Benutzer Daten. Der Umstieg auf xorg als   
                              standardma:ssige X Implementierung wurde   
                              auch zu dieser Zeit durchgefu:hrt.         
                              5.2-CURRENT nachdem die Art und Weise, wie 
502124     24. Juli 2004      rc.d-Skripte von Ports und Altlasten       
                              gestartet werden, getrennt wurde.          
502125     28. Juli 2004      5.2-CURRENT nachdem die vorherige          
                              A:nderung ru:ckga:ngig gemacht wurde.      
                              5.2-CURRENT nach dem Entfernen von         
502126     31. Juli 2004      kmem_alloc_pageable() und dem Import von   
                              GCC 3.4.2.                                 
                              5.2-CURRENT nachdem die UMA Kernel API     
502127     2. August 2004     gea:ndert wurde, um Konstruktoren und      
                              Initialisierungsmethoden zu erlauben       
                              fehlzuschlagen.                            
                              5.2-CURRENT nach der A:nderung in der      
502128     8. August 2004     vfs_mount Signatur sowie allgemeines       
                              Ersetzen von PRISON_ROOT durch             
                              SUSER_ALLOWJAIL in der suser(9) API.       
503000     23. August 2004    5.3-BETA/RC vor der A:nderung der          
                              pfil-API.                                  
503001     22. September 2004 5.3-RELEASE                                
503100     16. Oktober 2004   5.3-STABLE nach dem Erstellen des          
                              RELENG_5_3-Zweiges.                        
                              5.3-STABLE nach dem Hinzufu:gen von        
503101     3. Dezember 2004   Fu:lloptionen im Stile der libc zu         
                              strftime(3).                               
503102     13. Februar 2005   5.3-STABLE nachdem OpenBSD's nc(1) von     
                              CURRENT importiert wurde.                  
                              5.4-PRERELEASE nach dem Einfliessen der    
                              Reparaturen aus CURRENT, in                
503103     27. Februar 2005   <src/include/stdbool.h> und                
                              <src/sys/i386/include/_types.h>, um die    
                              GCC-Kompatibilita:t des Intel              
                              C/C++-Compilers zu benutzen.               
                              5.4-PRERELEASE nach dem Einfliessen der    
503104     28. Februar 2005   A:nderung aus CURRENT in ifi_epoch statt   
                              der lokalen Zeit die Betriebszeit des      
                              Systems zu benutzen.                       
                              5.4-PRERELEASE nach dem Einfliessen der    
503105     2. Ma:rz 2005      Reparaturen von EOVERFLOW in vswprintf(3)  
                              aus CURRENT.                               
504000     3. April 2005      5.4-RELEASE.                               
504100     3. April 2005      5.4-STABLE nach dem Erstellen des          
                              RELENG_5_4-Zweiges.                        
                              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                                
600001     27. August 2004    6.0-CURRENT nach der festen Aktivierung    
                              von PFIL_HOOKS im Kernel.                  
                              6.0-CURRENT nach der anfa:nglichen         
                              Einfu:hrung von ifi_epoch zur Struktur     
600002     30. August 2004    if_data. Wurde nach ein paar Tagen wieder  
                              ru:ckga:ngig gemacht. Benutzen Sie diesen  
                              Wert bitte nicht.                          
                              6.0-CURRENT nach dem erneuten Hinzufu:gen  
600003     8. September 2004  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               
600008     25. Januar 2005    VOP_*VOBJECT() Funktionen und Einfu:hrung  
                              des MNTK_MPSAFE Schalters fu:r             
                              Dateisysteme, welche ohne Giant arbeiten.  
600009     4. Februar 2005    6.0-CURRENT nach dem Hinzufu:gen von       
                              cpufreq Framework und Treibern.            
600010     6. Februar 2005    6.0-CURRENT nachdem OpenBSD's nc(1)        
                              importiert wurde.                          
                              6.0-CURRENT nachdem der Anschein von       
600011     12. Februar 2005   matherr() Unterstu:tzung in SVID2 entfernt 
                              wurde.                                     
                              6.0-CURRENT nach dem Vergro:ssern der      
600012     15. Februar 2005   standardma:ssigen Stackgro:sse fu:r        
                              Threads.                                   
                              6.0-CURRENT nach dem Einfliessen der       
                              Reparaturen in <src/include/stdbool.h> und 
600013     19. Februar 2005   <src/sys/i386/include/_types.h>, um die    
                              GCC-Kompatibilita:t des Intel              
                              C/C++-Compilers zu benutzen.               
                              6.0-CURRENT nachdem die U:berpru:fungen    
600014     21. Februar 2005   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, LOCAL_CONNWAIT   
600023     13. April 2005     fu:r Sockets wurde zu unix(4)              
                              hinzugefu:gt.                              
600024     19. April 2005     hwpmc(4) und zugeho:rige Werkzeuge wurden  
                              zu 6.0-CURRENT hinzugefu:gt.               
600025     26. April 2005     Die Struktur icmphdr wurden zu 6.0-CURRENT 
                              hinzugefu:gt.                              
600026     3. Mai 2005        pf Aktualisierung auf 3.7.                 
600027     6. Mai 2005        Kernel libalias und ng_nat wurden          
                              eingefu:hrt.                               
600028     13. Mai 2005       POSIX ttyname_r(3) wurde u:ber unistd.h    
                              und libc zur Verfu:gung gestellt.          
600029     29. Mai 2005       6.0-CURRENT nachdem libpcap zu Version     
                              v0.9.1 alpha 096 aktualisiert wurde.       
600030     5. Juni 2005       6.0-CURRENT nach dem Import von NetBSDs    
                              if_bridge(4).                              
600031     10. Juni 2005      6.0-CURRENT nachdem die Struktur ifnet aus 
                              dem Treiber softcs herausgelo:st wurde.    
600032     11. Juli 2005      6.0-CURRENT nach dem Import von libpcap    
                              v0.9.1.                                    
                              6.0-STABLE nachdem die Versionen aller     
600033     25. Juli 2005      gemeinsam genutzten Bibliotheken, welche   
                              seit RELENG_5 nicht gea:ndert wurden,      
                              erho:ht wurden.                            
                              6.0-STABLE nachdem das Argument credential 
600034     13. August 2005    zu der dev_clone-Ereignisbehandlung        
                              hinzugefu:gt wurde. 6.0-RELEASE.           
600100     1. November 2005   6.0-STABLE nach dem Erstellen des          
                              6.0-RELEASE-Zweiges.                       
                              6.0-STABLE nach dem Aufnehmen von Skripten 
600101     21. Dezember 2005  aus den local_startup-Verzeichnissen in    
                              rcorder(8) des Basissystems.               
600102     30. Dezember 2005  6.0-STABLE nach dem Aktualisieren der      
                              ELF-Typen und Konstanten.                  
600103     15. Januar 2006    6.0-STABLE nach dem Einfliessen der        
                              pidfile(3)-API aus CURRENT.                
                              6.0-STABLE nach dem Einfliessen der        
600104     17. Januar 2006    A:nderung von ldconfig_local_dirs aus      
                              CURRENT.                                   
600105     26. Februar 2006   6.0-STABLE nach der                        
                              NLS-Katalogunterstu:tzung von csh(1).      
601000     6. Mai 2006        6.1-RELEASE                                
601100     6. Mai 2006        6.1-STABLE nach 6.1-RELEASE.               
601101     22. Juni 2006      6.1-STABLE nach dem Import von csup.       
601102     11. Juli 2006      6.1-STABLE nach der iwi(4)-Aktualisierung. 
                              6.1-STABLE nach der Aktualisierung der     
601103     17. Juli 2006      Namensauflo:sung zu BIND9 und Aufnahme der 
                              ablaufinvarianten Versionen der            
                              netdb-Funktionen.                          
                              6.1-STABLE nachdem Unterstu:tzung fu:r DSO 
601104     8. August 2006     (dynamic shared objects - gemeinsam        
                              genutzte, dynamische Objekte) in OpenSSL   
                              aktiviert wurde.                           
                              6.1-STABLE nachdem 802.11 Reparaturen die  
601105     2. September 2006  API der IEEE80211_IOC_STA_INFO ioctl       
                              gea:ndert haben.                           
602000     15. November 2006  6.2-RELEASE                                
602100     15. September 2006 6.2-STABLE nach 6.2-RELEASE.               
602101     12. Dezember 2006  6.2-STABLE nach dem Hinzufu:gen der Wi-Spy 
                              Eigenart.                                  
602102     28. Dezember 2006  6.2-STABLE nachdem pci_find_extcap()       
                              hinzugefu:gt wurde.                        
                              6.2-STABLE nach dem Einpflegen der dlsym   
                              A:nderung aus CURRENT, ein angefordertes   
602103     16. Januar 2007    Symbol sowohl in der spezifizierten dso,   
                              als auch in den impliziten Abha:ngigkeiten 
                              nachzuschlagen.                            
                              6.2-STABLE nach dem Einpflegen von         
                              ng_deflate(4) und ng_pred1(4) netgraph     
602104     28. Januar 2007    Knoten und neuen Kompressions- und         
                              -Verschlu:sselungmodi fu:r den ng_ppp(4)   
                              Knoten aus CURRENT.                        
                              6.2-STABLE nach dem Einpflegen der BSD     
602105     20. Februar 2007   lizensierten Version von gzip(1), welche   
                              von NetBSD portiert wurde aus CURRENT.     
602106     31. Ma:rz 2007     6.2-STABLE nach dem Einpflegen der PCI MSI 
                              und MSI-X Unterstu:tzung aus CURRENT.      
                              6.2-STABLE nach dem Einpflegen von ncurses 
602107     6. April 2007      5.6 und Unterstu:tzung fu:r                
                              Multibyte-Zeichen aus CURRENT.             
                              6.2-STABLE nach dem Einpflegen des 'SG'    
602108     11. April 2007     Peripheriegera:tes aus CURRENT in CAM,     
                              welches einen Teil der SCSI SG passthrough 
                              Gera:te API von Linux entha:lt.            
602109     17. April 2007     6.2-STABLE nach dem Einpflegen von         
                              readline 5.2 Patchset 002 aus CURRENT.     
                              6.2-STABLE nach dem Einpflegen von         
                              pmap_invalidate_cache(),                   
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        
602113     25. Oktober 2007   Bina:rdateien, die ctype.h referenzieren,  
                              erfordern mo:glicherweise ein neues        
                              Symbol, __mb_sb_limit, das auf a:lteren    
                              Systemen nicht verfu:gbar ist.             
                              6.2-STABLE, nachdem die ctype              
602114     30. Oktober 2007   ABI-Aufwa:rtskompatibilita:t               
                              wiederhergestellt wurde.                   
                              FreeBSD 6.2-STABLE nach der                
602115     21. November 2007  Entfernung/Eliminierung der wide und       
                              single Byte ctype-Trennung                 
603000     25. November 2007  6.3-RELEASE                                
603100     25. November 2007  6.3-STABLE nach 6.3-RELEASE.               
                              6.3-STABLE, nachdem der Support fu:r den   
603101     7. Dezember 2007   Multibyte-Datentyp im Bit-Makro gefixt     
                              wurde.                                     
603102     24. April 2008     6.3-STABLE nach Hinzufu:gen von l_sysid zu 
                              struct flock.                              
603103     27. Mai 2008       6.3-STABLE nach Einfliessen der            
                              memrchr-Funktion.                          
                              6.3-STABLE nach U:bernahme der             
603104     15. Juni 2008      Unterstu:tzung von :u als Variablenwandler 
                              in make(1).                                
604000     4. Oktober 2008    6.4-RELEASE                                
604100     4. Oktober 2008    6.4-STABLE nach 6.4-RELEASE.               
700000     11. Juli 2005      7.0-CURRENT.                               
                              7.0-CURRENT nachdem die Versionen aller    
700001     23. Juli 2005      gemeinsam genutzten Bibliotheken, welche   
                              seit RELENG_5 nicht gea:ndert wurden,      
                              erho:ht wurden.                            
                              7.0-CURRENT nachdem ein                    
700002     13. August 2005    Berechtigungs-Argument zur                 
                              dev_clone-Ereignisroutine hinzugefu:gt     
                              wurde.                                     
700003     25. August 2005    7.0-CURRENT nachdem memmem(3) zur libc     
                              hinzugefu:gt wurde.                        
                              7.0-CURRENT nachdem die Argumente der      
                              Kernelfunktion solisten(9) modifiziert     
700004     30. Oktober 2005   wurden, um einen Backlog-Parameter (Anzahl 
                              der maximalen wartenden Verbindungen) zu   
                              akzeptieren.                               
                              7.0-CURRENT nachdem IFP2ENADDR() gea:ndert 
700005     11. November 2005  wurde, einen Zeiger auf IF_LLADDR()        
                              zuru:ckzugeben.                            
                              7.0-CURRENT nach dem Hinzufu:gen des       
700006     11. November 2005  if_addr-Elements zur Struktur ifnet und    
                              dem Entfernen von IFP2ENADDR().            
                              7.0-CURRENT nach dem Aufnehmen von         
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.                    
700009     19. Dezember 2005  7.0-CURRENT nach ELF-64 Typen A:nderungen  
                              und Symbol Versionierung.                  
                              7.0-CURRENT nach Hinzufu:gen der hostb und 
                              vgapci Treiber, Hinzufu:gen von            
700010     20. Dezember 2005  pci_find_extcap() und A:nderung der AGP    
                              Treiber die Apertur nicht la:nger          
                              abzubilden.                                
                              7.0-CURRENT nachdem auf allen Plattformen  
700011     31. Dezember 2005  ausser Alpha tv_sec in time_t umgewandelt  
                              wurde.                                     
700012     8. Januar 2006     7.0-CURRENT nach A:nderung von             
                              ldconfig_local_dirs.                       
                              7.0-CURRENT nach A:nderung in              
                              /etc/rc.d/abi 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  
700022     9. September 2006  angefordertes Symbol sowohl in der         
                              spezifizierten dso, als auch in den        
                              impliziten Abha:ngigkeiten nachzuschlagen. 
700023     23. September 2006 7.0-CURRENT nach dem Hinzufu:gen neuer     
                              Sound-IOCTLs fu:r die OSSv4-Mixer-API.     
700024     28. September 2006 7.0-CURRENT nach dem Import von OpenSSL    
                              0.9.8d.                                    
700025     11. November 2006  7.0-CURRENT nach dem Hinzufu:gen der       
                              libelf.                                    
700026     26. November 2006  7.0-CURRENT nach gro:sseren A:nderungen an 
                              den Sound sysctls.                         
700027     30. November 2006  7.0-CURRENT nach dem Hinzufu:gen der       
                              Wi-Spy-Eigenart.                           
700028     15. Dezember 2006  7.0-CURRENT nach dem Hinzufu:gen von       
                              sctp-Aufrufen zur libc.                    
                              7.0-CURRENT nach dem Ersetzen von GNU      
700029     26. Januar 2007    gzip(1) durch eine von NetBSD portierte    
                              Version, die unter BSD-Lizenz steht.       
                              7.0-CURRENT nach dem Entfernen der IPIP    
700030     7. Februar 2007    Tunnelkapselung (VIFF_TUNNEL) aus dem IPv4 
                              Multicast-Forwarding-Quelltext.            
700031     23. Februar 2007   7.0-CURRENT nach den Modifizierungen an    
                              bus_setup_intr() (newbus).                 
700032     2. Ma:rz 2007      7.0-CURRENT nach der Aufnahme der Firmware 
                              fu:r ipw(4) und iwi(4).                    
700033     9. Ma:rz 2007      7.0-CURRENT nach Unterstu:tzung fu:r       
                              Multibyte-Zeichen.                         
                              7.0-CURRENT nach A:nderungen, wie          
700034     19. Ma:rz 2007     insmntque(), getnewvnode() und             
                              vfs_hash_insert() arbeiten.                
                              7.0-CURRENT nach Hinzufu:gen eines         
700035     26. Ma:rz 2007     Benachrichtigungsmechanismus fu:r CPU      
                              Frequenza:nderungen.                       
700036     6. April 2007      7.0-CURRENT nach dem Import des ZFS        
                              Dateisystemes.                             
                              7.0-CURRENT nach dem Einpflegen des 'SG'   
700037     8. April 2007      Peripheriegera:tes in CAM, welches einen   
                              Teil der SCSI SG passthrough Gera:te API   
                              von Linux entha:lt.                        
                              7.0-CURRENT nachdem getenv(3), putenv(3),  
700038     30. April 2007     setenv(3) und unsetenv(3) gea:ndert        
                              wurden, um POSIX konform zu sein.          
700039     1. Mai 2007        7.0-CURRENT nachdem die A:nderungen von    
                              700038 ru:ckga:ngig gemacht wurden.        
700040     10. Mai 2007       7.0-CURRENT nach dem Hinzufu:gen von       
                              flopen(3) zur libutil.                     
                              7.0-CURRENT nachdem Symbol Versionierung   
700041     13. Mai 2007       aktiviert und die standardma:ssige         
                              Thread-Bibliothek zu libthr gea:ndert      
                              wurde.                                     
700042     19. Mai 2007       7.0-CURRENT nach dem Import von GCC 4.2.0. 
                              7.0-CURRENT nachdem die Versionen aller    
700043     21. Mai 2007       Shared-Libraries, welche seit RELENG_6     
                              nicht gea:ndert wurden, erho:ht worden     
                              sind.                                      
                              7.0-CURRENT nachdem das Argument fu:r      
700044     7. Juni 2007       vn_open()/VOP_OPEN() vom                   
                              Dateideskriptorindex zur Struktur file *   
                              gea:dert wurde.                            
                              7.0-CURRENT nachdem pam_nologin(8)         
                              gea:dert 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             
700048     12. Juni 2007      RFC 1724-Verhalten des IP_MULTICAST_IF     
                              ioctl wurde entfernt; 0.0.0.0/8 darf nicht 
                              la:nger als Schnittstellen-Index benutzt   
                              werden. Stattdessen sollte die Struktur    
                              ipmreqn verwendet werden.                  
700049     3. Juli 2007       7.0-CURRENT, nachdem pf von OpenBSD 4.1    
                              importiert wurde                           
                              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.                                    
700051     4. Juli 2007       7.0-CURRENT, nachdem neue Systemaufrufe    
                              (mmap/lseek/usw.) implementiert wurden.    
700052     6. Juli 2007       7.0-CURRENT, nachdem die I4B-Header nach   
                              include/i4b verschoben wurden.             
700053     30. September 2007 7.0-CURRENT, nachdem die Unterstu:tzung    
                              fu:r PCI Doma:nen hinzugefu:gt wurde.      
700054     25. Oktober 2007   7.0-CURRENT, nach der Trennung in "wide    
                              und single byte ctype".                    
                              7.0-RELEASE sowie 7.0-CURRENT, nachdem die 
                              ABI-Abwa:rtskompatibilita:t fu:r die       
                              FreeBSD 4/5/6-Versionen der PCIOCGETCONF-, 
700055     28. Oktober 2007   PCIOCREAD- sowie PCIOCWRITE IOCTLs         
                              hinzugefu:gt wurde. Damit verbunden war,   
                              dass die ABI der PCIOCGETCONF IOCTL erneut 
                              deaktiviert werden musste.                 
700100     22. Dezember 2007  7.0-STABLE nach 7.0-RELEASE.               
700101     8. Februar 2008    7.0-STABLE nach Einfu:hrung von            
                              m_collapse().                              
700102     30. Ma:rz 2008     7.0-STABLE nach Einfliessen von            
                              kdb_enter_why().                           
700103     10. April 2008     7.0-STABLE nach Hinzufu:gen von l_sysid zu 
                              struct flock.                              
700104     11. April 2008     7.0-STABLE nach U:bernahme von             
                              procstat(1).                               
700105     11. April 2008     7.0-STABLE nach Einfu:hrung von            
                              umtx-Features.                             
700106     15. April 2008     7.0-STABLE nach Hinzufu:gen der            
                              Unterstu:tzung von write(2) zu psm(4).     
700107     20. April 2008     7.0-STABLE nach Hinzufu:gen des Befehls    
                              F_DUP2FD zu fcntl(2).                      
                              7.0-STABLE nach einigen A:nderungen an     
700108     5. Mai 2008        lockmgr(9), welche die Einbindung von      
                              sys/lock.h zur Verwendung von lockmgr(9)   
                              voraussetzen.                              
700109     27. Mai 2008       7.0-STABLE nach Einfliessen der            
                              memrchr-Funktion.                          
700110     5. August 2008     7.0-STABLE nach Einfu:hrung eines Clients  
                              fu:r den Kernel NFS lockd.                 
                              7.0-STABLE nach Hinzufu:gen einer          
700111     20. August 2008    Unterstu:tzung von physisch fortlaufender  
                              Jumbo Frames.                              
700112     27. August 2008    7.0-STABLE nach Einfliessen einer          
                              Kernelunterstu:tzung fu:r DTrace.          
701000     25. November 2008  7.1-RELEASE                                
701100     25. November 2008  7.1-STABLE nach 7.1-RELEASE.               
701101     10. Januar 2009    7.1-STABLE nach U:bernahme von strndup.    
701102     17. Januar 2009    7.1-STABLE nach Hinzufu:gen einer          
                              Unterstu:tzung von cpuctl(4).              
                              7.1-STABLE nach Einfliessen der            
701103     7. Februar 2009    Unterstu:tzung von Jails mit keinen oder   
                              mehreren IPv4-/IPv6-Adressen.              
                              7.1-STABLE, nachdem der Besitzer des       
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 kern.ipc.shmsegs, um   
701105     12. Ma:rz 2009     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.                        
702103     06. Juni 2009      7.2-STABLE nach dem Einfliessen von        
                              PmcTools.                                  
702104     14. Juli 2009      7.2-STABLE nach dem Einfliessen des        
                              Systemaufrufs closefrom.                   
702105     31. Juli 2009      7.2-STABLE nach dem Einfliessen der        
                              A:nderung an der SYSVIPC-ABI.              
                              7.2-STABLE nach dem Einfliessen der        
                              PAT-Verbesserungen fu:r x86-Prozessoren    
702106     14. September 2009 sowie dem Hinzufu:gen von d_mmap_single()  
                              und des VM-Objekttyps fu:r                 
                              scatter/gather-Listen.                     
703000     9. Februar 2010    7.3-RELEASE                                
703100     9. Februar 2010    7.3-STABLE nach 7.3-RELEASE.               
704000     22. Dezember 2010  7.4-RELEASE                                
704100     22. Dezember 2010  7.4-STABLE, nachdem 7.4-RELEASE erzeugt    
                              wurde.                                     
800000     11. Oktober 2007   8.0-CURRENT. Nach der Trennung in "wide    
                              und single byte ctype".                    
800001     16. Oktober 2007   8.0-CURRENT, nachdem libpcap 0.9.8 und     
                              tcpdump 3.9.8 importiert wurden.           
                              8.0-CURRENT, nachdem kthread_create() und  
800002     21. Oktober 2007   Konsorten in kproc_create() usw. umbenannt 
                              wurden.                                    
                              8.0-CURRENT, nachdem die                   
                              ABI-Abwa:rtskompatibilita:t fu:r die       
                              FreeBSD 4/5/6-Versionen der PCIOCGETCONF-, 
800003     24. Oktober 2007   PCIOCREAD- sowie PCIOCWRITE IOCTLs         
                              hinzugefu:gt wurde. Damit verbunden war,   
                              dass die ABI der PCIOCGETCONF IOCTL erneut 
                              deaktiviert werden musste.                 
                              8.0-CURRENT, nachdem der agp(4) Treiber    
800004     12. November 2007  verschoben wurde von src/sys/pci nach      
                              src/sys/dev/agp.                           
800005     4. Dezember 2007   8.0-CURRENT nach A:nderungen am            
                              Jumbo Frame Allocator.                     
                              8.0-CURRENT, nach dem Hinzufu:gen der      
800006     7. Dezember 2007   callgraph capture Funktionalita:t zu       
                              hwpmc(4).                                  
800007     25. Dezember 2007  8.0-CURRENT nach dem Hinzufu:gen von "why" 
                              als Argument in kdb_enter().               
800008     28. Dezember 2007  8.0-CURRENT nach Entfernen der Option      
                              LK_EXCLUPGRADE.                            
800009     9. Januar 2008     8.0-CURRENT nach Einfu:hrung von           
                              lockmgr_disown(9)                          
800010     10. Januar 2008    8.0-CURRENT nach A:nderungen am            
                              vn_lock(9)-Prototyp.                       
                              8.0-CURRENT nach A:nderungen an den        
800011     13. Januar 2008    Prototypen von VOP_LOCK(9) und             
                              VOP_UNLOCK(9).                             
                              8.0-CURRENT nach Einfu:hrung von           
800012     19. Januar 2008    lockmgr_recursed(9), BUF_RECURSED(9) und   
                              BUF_ISLOCKED(9) sowie Entfernung von       
                              BUF_REFCNT().                              
800013     23. Januar 2008    8.0-CURRENT nach Einfu:hrung der           
                              ``ASCII''-Kodierung.                       
                              8.0-CURRENT nach A:nderungen am            
800014     24. Januar 2008    lockmgr(9)-Prototyp und Entfernung von     
                              lockcount() sowie LOCKMGR_ASSERT().        
800015     26. Januar 2008    8.0-CURRENT nach Erweiterung der           
                              Datentypen der fts(3)-Strukturen.          
800016     1. Februar 2008    8.0-CURRENT nach Hinzufu:gen eines neuen   
                              Parameters zu MEXTADD(9).                  
                              8.0-CURRENT nach Einfu:hrung der Optionen  
800017     6. Februar 2008    LK_NODUP und LK_NOWITNESS in die           
                              lockmgr(9)-Umgebung.                       
800018     8. Februar 2008    8.0-CURRENT nach Hinzufu:gen von           
                              m_collapse.                                
                              8.0-CURRENT nach Hinzufu:gen einer         
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 Parameters  
800026     12. Ma:rz 2008     fu:r die Priorita:t an cv_broadcastpri,    
                              sodass 0 fu:r keine Priorita:t steht.      
                              8.0-CURRENT nach A:nderung der             
800027     24. Ma:rz 2008     Monitoring ABI von BPF, als                
                              Zero-Copy Puffer hinzugefu:gt wurden.      
800028     26. Ma:rz 2008     8.0-CURRENT nach Hinzufu:gen von l_sysid   
                              zu struct flock.                           
                              8.0-CURRENT nach Wiedereingliederung der   
800029     28. Ma:rz 2008     Funktion BUF_LOCKWAITERS und Hinzufu:gen   
                              von lockmgr_waiters(9).                    
                              8.0-CURRENT nach Einfu:hrung der           
800030     1. April 2008      Funktionen rw_try_rlock(9) und             
                              rw_try_wlock(9).                           
800031     6. April 2008      8.0-CURRENT nach Einfu:hrung der           
                              Funktionen lockmgr_rw und lockmgr_args_rw. 
                              8.0-CURRENT nach Implementierung des       
                              Systemaufrufs openat und seiner            
800032     8. April 2008      Verwandten, Einfu:hrung der Option O_EXEC  
                              in open(2) und Bereitstellung der          
                              entsprechenden Systemaufrufe innerhalb der 
                              Linux(R)-Kompatibilita:tsumgebung.         
                              8.0-CURRENT nach Hinzufu:gen der           
                              Unterstu:tzung von write(2) in der nativen 
800033     8. April 2008      Operationsebene von psm(4). Es ko:nnen nun 
                              beliebig Kommandos nach /dev/psm%d         
                              geschrieben und der Status dann von dort   
                              gelesen werden.                            
800034     10. April 2008     8.0-CURRENT nach Einfu:hrung der Funktion  
                              memrchr.                                   
800035     16. April 2008     8.0-CURRENT nach Einfu:hrung der Funktion  
                              fdopendir.                                 
                              8.0-CURRENT nach Umstellung des Standards  
800036     20. April 2008     802.11 auf Unterstu:tzung von Multi-BSS    
                              (auch vaps).                               
                              8.0-CURRENT nach Hinzufu:gen einer         
800037     9. Mai 2008        Unterstu:tzung fu:r Multi Routing-Tabellen 
                              (siehe setfib(1), setfib(2)).              
                              8.0-CURRENT nach Entfernen von netatm und  
800038     26. Mai 2008       ISDN4BSD sowie dem Hinzufu:gen der Compact 
                              C Type (CTF)-Tools.                        
800039     14. Juni 2008      8.0-CURRENT nach Entfernen von sgtty.      
800040     26. Juni 2008      8.0-CURRENT nach Einfu:hrung eines Clients 
                              fu:r den Kernel NFS lockd.                 
                              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 bpf(4) zur  
800043     13. August 2008    Verwendung einer einzelnen Gera:tedatei    
                              anstatt von Klonierung.                    
                              8.0-CURRENT nach U:bernahme des ersten     
                              Teils aus dem vimage-Projekt durch         
                              Erweitern globaler Variablen um den        
800044     17. August 2008    Pra:fix V_. Zuku:nftig werden die          
                              virtualisierten Variablen dann mit Hilfe   
                              von Makros in ihre globalen Namen          
                              aufgelo:st.                                
                              8.0-CURRENT nach Eingliederung des         
800045     20. August 2008    MPSAFE TTY-Layers, einschliesslich         
                              A:nderungen an diversen Treibern und       
                              Werkzeugen, die mit ihm kommunizieren.     
800046     8. September 2008  8.0-CURRENT nach Abschottung der GDT pro   
                              CPU auf der AMD64-Architektur.             
800047     10. September 2008 8.0-CURRENT nach Entfernen von VSVTX,      
                              VSGID und VSUID.                           
                              8.0-CURRENT nach Anpassung des Codes fu:r  
                              Kernel NFS mount, sodass einzelne          
800048     16. September 2008 Mountoptionen im Parameter struct iovec an 
                              nmount() akzeptiert werden und nicht nur   
                              ein grosses struct nfs_args.               
800049     17. September 2008 8.0-CURRENT nach Entfernen von suser(9)    
                              und suser_cred(9).                         
800050     20. Oktober 2008   8.0-CURRENT nach API-A:nderungen im Umgang 
                              mit dem Buffer Cache.                      
800051     23. Oktober 2008   8.0-CURRENT nach Entfernen der Makros      
                              MALLOC(9) und FREE(9).                     
                              8.0-CURRENT nach Einfu:hrung von accmode_t 
800052     28. Oktober 2008   und Umbennung des Parameters a_mode an     
                              VOP_ACCESS nach a_accmode.                 
                              8.0-CURRENT nach A:nderung des Prototyps   
800053     2. November 2008   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      
800054     22. November 2008  Karten zu ermo:glichen, die dies           
                              unterstu:tzen, sowie einer                 
                              Ring Buffer-Implementierung ohne Lock, um  
                              Treibern zu ermo:glichen, Paketschlangen   
                              effizienter zu verwalten.                  
                              8.0-CURRENT nach Hinzufu:gen einer         
800055     27. November 2008  Unterstu:tzung fu:r Intel(R) Core, Core2   
                              und Atom zu hwpmc(4).                      
                              8.0-CURRENT nach Einfu:hrung von Jails mit 
800056     29. November 2008  mehreren oder gar keinen                   
                              IPv4-/IPv6-Adressen.                       
800057     1. Dezember 2008   8.0-CURRENT nach Wechsel zum               
                              ath_hal Quellcode.                         
800058     12. Dezember 2008  8.0-CURRENT nach Einfu:hrung der Funktion  
                              VOP_VPTOCNP.                               
800059     15. Dezember 2008  8.0-CURRENT gliedert das neue ARPv2 ein.   
800060     19. Dezember 2008  8.0-CURRENT nach Hinzufu:gen von makefs.   
800061     15. Januar 2009    8.0-CURRENT nach Umsetzung von             
                              TCP Appropriate Byte Counting.             
800062     28. Januar 2009    8.0-CURRENT nach Entfernen von minor(),    
                              minor2unit(), unit2minor() usw.            
                              8.0-CURRENT nach A:nderung der             
800063     18. Februar 2009   GENERIC-Konfiguration zur Verwendung des   
                              USB2-Stack und Hinzufu:gen von             
                              fdevname(3).                               
                              8.0-CURRENT, nachdem der USB2-Stack nach   
800064     23. Februar 2009   dev/usb verschoben wurde, um es zu         
                              ersetzen.                                  
800065     26. Februar 2009   8.0-CURRENT nach Umbenennen aller          
                              Funktionen in libmp(3).                    
800066     27. Februar 2009   8.0-CURRENT nach Anpassung des             
                              devfs-Verhaltens im Zusammenhang mit USB.  
                              8.0-CURRENT nach Hinzufu:gen von           
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 gcc zur 
800071     14. Ma:rz 2009     Verwendung der C99-Inline-Semantik in den  
                              Modi c99 und gnu99.                        
                              8.0-CURRENT, nachdem die Option            
800072     15. Ma:rz 2009     IFF_NEEDSGIANT entfernt wurde;             
                              Netzwerktreiber, die nicht MPSAFE sind,    
                              werden nicht mehr unterstu:tzt.            
                              8.0-CURRENT, nachdem die dynamische        
800073     18. Ma:rz 2009     Ersetzung von Zeichenkettenku:rzeln fu:r   
                              rpath und beno:tigte Pfade implementiert   
                              wurde.                                     
800074     24. Ma:rz 2009     8.0-CURRENT nach dem Einfliessen von       
                              tcpdump 4.0.0 und libpcap 1.0.0.           
                              8.0-CURRENT, nachdem die Deklarationen von 
800075     6. April 2009      struct vnet_net, struct vnet_inet und      
                              struct vnet_ipfw gea:ndert wurden.         
800076     9. April 2009      8.0-CURRENT nach dem Hinzufu:gen von       
                              Laufzeitprofilen in dummynet.              
800077     14. April 2009     8.0-CURRENT nach dem Entfernen von         
                              VOP_LEASE() und vop_vector.vop_lease.      
                              8.0-CURRENT, nachdem die Felder aus        
                              struct rt_weight zu struct rt_metrics und  
                              struct rt_metrics_lite hinzugefu:gt        
800078     15. April 2009     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 
800082     21. April 2009     von struct ifnet und Hinzufu:gen von       
                              if_ref() und if_rele() zur Verwaltung von  
                              Referenzen auf ifnet.                      
800083     22. April 2009     8.0-CURRENT nach der Implementierung einer 
                              systemnahen Bluetooth-HCI-API.             
800084     29. April 2009     8.0-CURRENT nach A:nderungen an IPv6-SSM   
                              und MLDv2.                                 
                              8.0-CURRENT, nachdem der Bau von           
800085     30. April 2009     VIMAGE-Kernel mit einem aktiven Image      
                              unterstu:tzt wird.                         
                              8.0-CURRENT nach Hinzufu:gen der           
800086     8. Mai 2009        Unterstu:tzung fu:r Eingabezeilen mit      
                              beliebiger La:nge durch patch(1).          
                              8.0-CURRENT nach einigen A:nderungen im    
                              Zusammenhang mit dem VFS-KPI. Der          
                              Thread-Parameter wurde von den FSD-Teilen  
800087     11. Mai 2009       des VFS entfernt. VFS_*-Funktionen         
                              beno:tigen den Kontext nicht mehr, da er   
                              sich immer auf curthread bezieht. In       
                              wenigen Sonderfa:llen ist das bisherige    
                              Verhalten nicht gea:ndert worden.          
800088     20. Mai 2009       8.0-CURRENT nach A:nderungen am            
                              net80211-Monitormodus.                     
800089     23. Mai 2009       8.0-CURRENT nach dem Hinzufu:gen der       
                              Unterstu:tzung von UDP-Kontrollblocks.     
800090     23. Mai 2009       8.0-CURRENT nach der Virtualisierung der   
                              Schnittstellenklonierung.                  
                              8.0-CURRENT nach dem Hinzufu:gen von       
800091     27. Mai 2009       hierarchischen Jails und dem Entfernen des 
                              globalen securelevel.                      
                              8.0-CURRENT nach der A:nderung des         
                              sx_init_flags()-KPI. SX_ADAPTIVESPIN wurde 
800092     29. Mai 2009       zuru:ckgezogen und eine neue Option        
                              SX_NOADAPTIVE wurde eingefu:hrt, um die    
                              umgekehrte Logik zu behandeln.             
800093     29. Mai 2009       8.0-CURRENT nach dem Hinzufu:gen von       
                              mnt_xflag zu struct mount.                 
800094     30. Mai 2009       8.0-CURRENT nach dem Hinzufu:gen von       
                              VOP_ACCESSX(9).                            
                              8.0-CURRENT nach der A:nderung des         
                              Polling-KPI. Die Polling-Handler liefern   
                              nun die Zahl der verarbeiteten Pakete      
                              zuru:ck. Die neue Option                   
800095     30. Mai 2009       IFCAP_POLLING_NOCOUNT wurde weiter         
                              eingefu:hrt, um anzugeben, dass der        
                              Ru:ckgabewert nicht von Bedeutung ist und  
                              das Za:hlen der Pakete ausgelassen werden  
                              soll.                                      
                              8.0-CURRENT nach der Aktualisierung der    
800096     1. Juni 2009       netisr-Implementierung und nachdem die     
                              Weise, wie FIBs gespeichert werden und wie 
                              auf sie zugegriffen wird, gea:ndert wurde. 
                              8.0-CURRENT nach Einfu:hrung der           
800097     8. Juni 2009       Destruktor-Infrastruktur fu:r vnet         
                              einschliesslich Hooks.                     
                              8.0-CURRENT nach Einfu:hrung eines         
                              Erkennungssystems fu:r ausgehende Pakete,  
800097     11. Juni 2009      die direkt wieder in netgraph gelangen und 
                              deswegen eingereiht werden. Dabei wurde    
                              auch die Definition von struct thread      
                              gea:ndert.                                 
800098     14. Juni 2009      8.0-CURRENT nach dem Einfliessen von       
                              OpenSSL 0.9.8k.                            
                              8.0-CURRENT nach der Aktualisierung von    
800099     22. Juni 2009      NGROUPS und dem Verschieben der            
                              Routing-Virtualisierung in ein eigenes     
                              VImage-Modul.                              
800100     24. Juni 2009      8.0-CURRENT nach A:nderung der             
                              SYSVIPC-ABI.                               
                              8.0-CURRENT nach dem Entfernen der         
800101     29. Juni 2009      zeichenorientierten Gera:te aus /dev/net,  
                              von denen fu:r jede Schnittstelle eines    
                              existiert.                                 
                              8.0-CURRENT, nachdem struct sackhint,      
800102     12. Juli 2009      struct tcpcb und struct tcpstat mit        
                              Padding-Bytes aufgefu:llt wurden.          
                              8.0-CURRENT, nachdem struct tcpopt durch   
800103     13. Juli 2009      struct toeopt in der Schnittstelle         
                              zwischen dem TOE-Treiber und dem           
                              TCP-SYN-Cache ersetzt wurde.               
                              8.0-CURRENT nach dem Hinzufu:gen einer     
800104     19. Juli 2009      vnet-spezifischen Speicherzuweisung, die   
                              auf dem Linker-Set-Verfahren basiert.      
                              8.0-CURRENT nach der Inkrementierung der   
800105     19. Juli 2009      Versionsnummer aller Shared-Libraries, die 
                              Symbol-Versioning nicht aktiviert haben.   
800106     24. Juli 2009      8.0-CURRENT nach Einfu:hrung des           
                              VM-Objekttyps OBJT_SG.                     
                              8.0-CURRENT nach Befreiung des             
800107     2. August 2009     Newbus-Subsystems von Giant durch          
                              Hinzufu:gen von sxlock und 8.0-RELEASE.    
800108     21. November 2009  8.0-CURRENT nach Implementierung des       
                              kevent-Filters EVFILT_USER.                
                              8.0-STABLE nach Erho:hung von              
800500     7. Januar 2010     __FreeBSD_version, damit pkg_add -r        
                              packages-8-stable verwendet.               
                              8.0-STABLE, nachdem die Prototypen von     
800501     24. Januar 2010    scandir(3) und alphasort(3) gea:ndert      
                              wurden, um der SUSv4 zu entsprechen.       
800502     31. Januar 2010    8.0-STABLE nach Hinzufu:gen von            
                              sigpause(3).                               
                              8.0-STABLE nach dem Hinzufu:gen der ioctls 
                              SIOCGIFDESCR und SIOCSIFDESCR fu:r         
                              Netzwerk-Schnittstellen. Diese ioctls      
800503     25. Februar 2010   ko:nnen, nach dem Vorbild von OpenBSD,     
                              dazu verwendet werden,                     
                              Schnittstellenbeschreibungen zu bearbeiten 
                              und auszulesen.                            
                              8.0-STABLE, nachdem x86emu, ein            
800504     1. Ma:rz 2010      Software-Emulator von OpenBSD fu:r         
                              x86-Prozessoren im Real-Mode, von CURRENT  
                              u:bernommen wurde.                         
800505     18. Mai 2010       8.0-STABLE nach dem Einfliessen von        
                              liblzma, xz, xzdec und lzmainfo.           
801000     14. Juni 2010      8.1-RELEASE                                
801500     14. Juni 2010      8.1-STABLE nach 8.1-RELEASE.               
                              8.1-STABLE nach der KBI-A:nderung in       
801501     November 3, 2010   struct sysentve und der Implementierung    
                              von PL_FLAG_SCE/SCX/EXEC/SI und pl_siginfo 
                              fu:r ptrace(PT_LWPINFO) .                  
802000     22. Dezember 2010  8.2-RELEASE                                
802500     22. Dezember 2010  8.2-STABLE, nachdem 8.2-RELEASE erzeugt    
                              wurde.                                     
                              8.2-STABLE, nachdem DTrace aktualisiert    
802501     28. Februar 2011   wurde (so wird nun auch Userland-Tracing   
                              unterstu:tzt).                             
802502     6. Ma:rz 2011      8.2-STABLE, nachdem log2 und log2f in libm 
                              aufgenommen wurden.                        
                              8.2-STABLE, nachdem gcc auf die letzte     
802503     1. Mai 2011        unter der GPLv2 stehenden Version (aus dem 
                              FSF gcc-4_2-Zweig) aktualisiert wurde.     
                              8.2-STABLE, nachdem KPI sowie die          
802504     28. Mai 2011       Infrastruktur zur Unterstu:tzung von       
                              ``modular congestion control''             
                              implementiert wurden.                      
802505     28. Mai 2011       8.2-STABLE, nachdem die KPIs Hhook und     
                              Khelp implementiert wurden.                
802506     M28. Mai 2011      8.2-STABLE, nachdem OSD in die Struktur    
                              tcpcb eingebaut wurde.                     
802507     6. Juni 2011       8.2-STABLE nach dem Import von ZFS v28.    
802508     8. Juni 2011       8.2-STABLE, nach dem Entfernen der Methode 
                              sv_schedtail struct sysvec.                
802509     14. Juli 2011      8.2-STABLE, nachdem die binutils um die    
                              SSSE3-Unterstu:tzung erweitert wurden.     
802510     19. Juli 2011      8.2-STABLE, nach dem Hinzufu:gen des Flags 
                              RFTSIGZMB zu rfork(2).                     
900000     22. August 2009    9.0-CURRENT.                               
                              9.0-CURRENT nach dem Import von x86emu,    
900001     8. September 2009  einem Software-Emulator von OpenBSD fu:r   
                              x86-Prozessoren im Real-Mode.              
900002     23. September 2009 9.0-CURRENT nach Implementierung des       
                              kevent-Filters EVFILT_USER.                
                              9.0-CURRENT nach Hinzufu:gen von           
900003     2. Dezember 2009   sigpause(3) und der PIE-Unterstu:tzung zu  
                              csu.                                       
                              9.0-CURRENT nach Hinzufu:gen von libulog   
900004     6. Dezember 2009   und dessen                                 
                              libutempter-Kompatibilita:tsschnittstelle. 
                              9.0-CURRENT nach Hinzufu:gen von           
                              sleepq_sleepcnt(), das dazu verwendet      
900005     12. Dezember 2009  werden kann, die Anzahl der in einer       
                              bestimmten Warteschlange eingereihten      
                              Threads abzufragen.                        
                              9.0-CURRENT, nachdem die Prototypen von    
900006     4. Januar 2010     scandir(3) und alphasort(3) gea:ndert      
                              wurden, um der SUSv4 zu entsprechen.       
                              9.0-CURRENT nach dem Entfernen von utmp(5) 
900007     13. Januar 2010    und dem Hinzufu:gen von utmpx (siehe       
                              getutxent(3)) zur besseren Erfassung von   
                              Benutzeranmeldungen und Systemereignissen. 
900008     20. Januar 2010    9.0-CURRENT nach der Einfu:hrung von BSDL  
                              bc/dc zur Ersetzung von GNU bc/dc.         
                              9.0-CURRENT nach dem Hinzufu:gen der       
                              ioctls SIOCGIFDESCR und SIOCSIFDESCR fu:r  
                              Netzwerk-Schnittstellen. Diese ioctls      
900009     26. Januar 2010    ko:nnen, nach dem Vorbild von OpenBSD,     
                              dazu verwendet werden,                     
                              Schnittstellenbeschreibungen zu bearbeiten 
                              und auszulesen.                            
900010     22. Ma:rz 2010     9.0-CURRENT nach dem Import von zlib       
                              1.2.4.                                     
900011     24. April 2010     9.0-CURRENT nach Hinzufu:gen von Soft      
                              Updates Journaling.                        
900012     10. Mai 2010       9.0-CURRENT nach Hinzufu:gen von liblzma,  
                              xz, xzdec und lzmainfo.                    
900013     24. Mai 2010       9.0-CURRENT nach Einbringen von            
                              USB-Fehlerbehebungen in linux(4).          
900014     10. Juni 2010      9.0-CURRENT nach Hinzufu:gen von Clang.    
900015     22. Juli 2010      9.0-CURRENT nach dem Import von BSD grep.  
900016     28. Juli 2010      9.0-CURRENT, nachdem mti_zone zu struct    
                              malloc_type_internal hinzugefu:gt wurde.   
                              9.0-CURRENT nach dem Zuru:ckkehren zu GNU  
900017     23. August 2010    grep als Standard und Hinzufu:gen der      
                              Option WITH_BSD_GREP.                      
                              9.0-CURRENT, nachdem das von               
900018     24. August 2010    pthread_kill(3) generierte Signal in       
                              si_code als SI_LWP bezeichnet wird. Zuvor  
                              war si_code SI_USER.                       
900019     28. August 2010    9.0-CURRENT nach Hinzufu:gen des Schalters 
                              MAP_PREFAULT_READ zu mmap(2).              
                              9.0-CURRENT, nachdem                       
900020     9. September 2010  ``drain''-Funktionalita:t in sbufs         
                              integriert wurde (wodurch sich auch das    
                              Layout von struct sbuf gea:ndert hat).     
900021     13. September 2010 9.0-CURRENT, nachdem ``Userland tracing''  
                              in DTrace eingefu:hrt wurde.               
                              9.0-CURRENT nach Hinzufu:gen der BSDL      
900022     2. Oktober 2010    man-Utilities (und gleichzeitigem          
                              Entfernen der GNU/GPL man-Utilities).      
900023     11. Oktober 2010   9.0-CURRENT nach der Aktualisierung von xz 
                              auf den git-Snapshot 20101010.             
900024     11. November 2010  9.0-CURRENT, nachdem libgcc.a durch        
                              libcompiler_rt.a.                          
900025     12. November 2010  9.0-CURRENT nach der Einfu:hrung von       
                              ``modularised congestion control''.        
                              9.0-CURRENT nach der Einfu:hrung von       
900026     30. November 2010  ``Serial Management Protocol (SMP)         
                              passthrough'' sowie den XPT_SMP_IO und     
                              XPT_GDEV_ADVINFO CAM CCBs.                 
900027     5. Dezember 2010   9.0-CURRENT, nachdem log2 zu libm          
                              hinzugefu:gt wurde.                        
                              9.0-CURRENT, nach dem HInzufu:gen von      
900028     21. Dezember 2010  Hhook (Helper Hook), Khelp (Kernel         
                              Helpers) und Object Specific Data (OSD)    
                              KPIs.                                      
                              9.0-CURRENT, nach der TCP-Stack            
                              modifiziert wurde, um es den Khelp-Modulen 
900029     28. Dezember 2010  zu erlauben, mit ihm u:ber Helper Hook     
                              Points zu kommunizieren und                
                              Verbindungsdaten im TCP-Kontrollblock zu   
                              speichern.                                 
900030     12. Januar 2011    9.0-CURRENT, nachdem libdialog auf die     
                              Version 20100428 aktualisiert wurde.       
900031     7. Februar 2011    9.0-CURRENT, nach dem Hinzufu:gen von      
                              pthread_getthreadid_np(3).                 
900032     8. Februar 2011    9.0-CURRENT, nachdem Prototyp und Symbol   
                              fu:r uio_yield entfernt wurden.            
900033     18. Februar 2011   9.0-CURRENT, nachdem die binutils auf      
                              Version 2.17.50 aktualisiert wurden.       
900034     8. Ma:rz 2011      9.0-CURRENT, nachdem die Struktur sysvec   
                              (sv_schedtail) modifiziert wurde.          
                              9.0-CURRENT, nach dem Update des im        
900035     29. Ma:rz 20111    Basissystem enthaltenen gcc sowie von      
                              libstdc++ auf die letzten unter GPLv2      
                              lizenzierten Versionen.                    
                              9.0-CURRENT, nachdem libobjc und die       
900036     18. April 2011     Unterstu:tzung fu:r Objective-C aus dem    
                              Basissystem entfernt wurden.               
                              9.0-CURRENT, nach dem Import der           
900037     13. Mai 2011       libprocstat(3)-Bibliothek sowie von        
                              fuser(1) in das Basissystem.               
900038     22. Mai 2011       9.0-CURRENT, nachdem ein Lock-Flag zu      
                              VFS_FHTOVP(9) hinzugefu:gt wurde.          
900039     28. Juni 2011      9.0-CURRENT, nachdem pf von OpenBSD 4.5    
                              importiert wurde.                          
                              9.0-CURRENT, nachdem                       
900041     13. August 2011    Capsicum-Funktionalita:ten implementiert   
                              wurden. Zusa:tzlich wurde fget(9) um ein   
                              Rechte-Argument erweitert.                 

     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. Aufgaben vernu:nftig lo:sen

   Das Makefile sollte die no:tigen Schritte einfach und vernu:nftig
   durchfu:hren. Wenn Sie ein einige Zeilen einsparen oder die
   Lesbarkeit verbessern ko:nnen, dann machen Sie dies bitte.
   Beispiele sind: Ein make-Konstrukt .if anstatt eines
   Shellkonstrukt if zu verwenden, anstatt do-extract neu zu
   definieren, dies mit EXTRACT* machen, oder GNU_CONFIGURE anstelle
   von CONFIGURE_ARGS += --prefix=${PREFIX} zu verwenden.

   Falls Sie sich in einer Situation wiederfinden, in der Sie viel
   Code neu schreiben mu:ssen, um etwas zu testen, sollten Sie zuerst
   bsd.port.mk erneut konsultieren und nachpru:fen ob es nicht
   bereits eine Lo:sung fu:r Ihr Problem entha:lt. Es ist zwar schwer
   zu lesen, beinhaltet jedoch eine Menge kurzer Lo:sungen fu:r viele
   scheinbar schwierige Probleme.

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

12.9. Beru:cksichtigen Sie sowohl CC als auch CXX

   Der Port sollte sowohl die CC- wie auch die CXX-Variable
   beru:cksichtigen. Damit ist gemeint, dass der Port diese Variablen
   nicht ohne Ru:cksicht auf eventuell schon gesetzte Werte einfach
   u:berschreiben sollte; stattdessen sollten neue Werte an schon
   existierende angeha:ngt werden. Dadurch ko:nnen Build-Optionen,
   die alle Ports betreffen, global definiert werden.

   Falls der Port diese Variablen nicht beru:cksichtigt, sollte
   NO_PACKAGE=ignores either cc or cxx ins Makefile eingefu:gt
   werden.

   Im Folgenden wird ein Beispiel eines Makefiles gezeigt, welches
   die beiden Variablen CC und CXX beru:cksichtigt. Beachten Sie das
   ?=:

 CC?= gcc

 CXX?= g++

   Nachfolgend ein Beispiel, welches weder CC noch CXX
   beru:cksichtigt:

 CC= gcc

 CXX= g++

   Die Variablen CC und CXX ko:nnen auf FreeBSD-Systemen in
   /etc/make.conf definiert werden. Im ersten Beispiel wird ein Wert
   nur dann gesetzt, falls dieser vorher noch nicht gesetzt war, um
   so systemweite Definitionen zu beru:cksichtigen. Im zweiten
   Beispiel werden die Variablen ohne Ru:cksicht u:berschrieben.

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

12.10. Beru:cksichtigen Sie CFLAGS

   Der Port sollte die Variable CFLAGS beru:cksichtigen. Damit ist
   gemeint, dass der Port den Wert dieser Variablen nicht absolut
   setzen und damit existierende Werte u:berschreiben sollte;
   stattdessen sollte er weitere Werte der Variablen durch Anha:ngen
   hinzufu:gen. Dadurch ko:nnen Build-Optionen, die alle Ports
   betreffen, global definiert werden.

   Falls der Port diese Variablen nicht beru:cksichtigt, sollte
   NO_PACKAGE=ignores cflags ins Makefile eingefu:gt werden.

   Im Folgenden wird ein Beispiel eines Makefiles gezeigt, welches
   die Variable CFLAGS beru:cksichtigt. Beachten Sie das +=:

 CFLAGS+= -Wall -Werror

   Nachfolgend finden Sie ein Beispiel, welches die CFLAGS-Variable
   nicht beru:cksichtigt:

 CFLAGS= -Wall -Werror

   Die Variable CFLAGS wird auf FreeBSD-Systemen in /etc/make.conf
   definiert. Im ersten Beispiel werden weitere Flags an die Variable
   CFLAGS angeha:ngt und somit der bestehende Wert nicht gelo:scht.
   Im zweiten Beispiel wird die Variable ohne Ru:cksicht
   u:berschrieben.

   Sie sollten Optimierungsflags aus Makefiles Dritter entfernen. Die
   CFLAGS des Systems beinhalten systemweite Optimierungsflags. Ein
   Beispiel eines unvera:nderten Makefiles:

 CFLAGS= -O3 -funroll-loops -DHAVE_SOUND

   Werden nun systemweite Optimierungsflags verwendet so wu:rde das
   Makefile in etwa folgendermassen aussehen:

 CFLAGS+= -DHAVE_SOUND

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

12.11. Threading-Bibliotheken

   Die Threading-Bibliothek muss mit Hilfe eines speziellen
   Linker-Flags -pthread in die Bina:rdateien unter FreeBSD gebunden
   werden. Falls ein Port auf ein direktes Verlinken gegen -lpthread
   oder -lc_r besteht, passen Sie den Port bitte so an, dass er die
   durch das Port-Framework bereitgestellte Variable PTHREAD_LIBS
   verwendet. Diese Variable hat u:blicherweise den Wert -pthread,
   kann aber auf einigen Architekturen und FreeBSD-Versionen
   abweichende Werte haben und daher sollte nie -pthread direkt in
   Patches geschrieben werden, sondern immer PTHREAD_LIBS.

     Anmerkung: Falls durch das Setzen von PTHREAD_LIBS der Bau des
     Ports mit der Fehlermeldung unrecognized option '-pthread'
     abbricht, kann die Verwendung des gcc als Linker durch setzen
     von CONFIGURE_ENV auf LD=${CC} helfen. Die Option -pthread wird
     nicht direkt von ld unterstu:tzt.

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

12.12. Ru:ckmeldungen

   Brauchbare A:nderungen/Patches sollten an den urspru:nglichen
   Autor/Maintainer der Software geschickt werden, damit diese in der
   na:chsten Version der Software mit aufgenommen werden ko:nnen.
   Dadurch wird Ihre Aufgabe fu:r die na:chste Version der Software
   deutlich einfacher.

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

12.13. README.html

   Nehmen Sie bitte keine README.html in den Port auf. Diese Datei
   ist kein Bestandteil der CVS-Sammlung sondern wird durch make
   readme erzeugt.

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

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

   In manchen Fa:llen sollten Benutzer davon abgehalten werden einen
   Port zu installieren. Um einem Benutzer mitzuteilen, dass ein Port
   nicht installiert werden sollte, gibt es mehrere Variablen fu:r
   make, die im Makefile des Ports genutzt werden ko:nnen. Der Wert
   der folgenden make-Variablen wird dem Benutzer als Grund fu:r die
   Ablehnung der Installation des Ports zuru:ckgegeben. Bitte
   benutzen Sie die richtige make-Variable, denn jede entha:lt eine
   vo:llig andere Bedeutung fu:r den Benutzer und das automatische
   System, das von dem Makefile abha:ngt, wie der Ports-Build-Custer,
   FreshPorts und portsmon.

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

  12.14.1. Variablen

     * BROKEN ist reserviert fu:r Ports, welche momentan nicht
       korrekt kompiliert, installiert oder deinstalliert werden. Es
       sollte fu:r Ports benutzt werden, von denen man annimmt, dass
       dies ein tempora:res Problem ist.

       Falls angegeben, wird der Build-Cluster dennoch versuchen den
       Port zu bauen, um zu sehen, ob das zugrunde liegende Problem
       behoben wurde (das ist jedoch im Allgemeinen nicht der Fall).

       Benutzen Sie BROKEN zum Beispiel, wenn ein Port:

          * nicht kompiliert

          * beim Konfiguration- oder Installation-Prozess scheitert

          * Dateien ausserhalb von ${LOCALBASE} installiert

          * beim Deinstallieren nicht alle seine Dateien sauber
            entfernt (jedoch kann es akzeptable und wu:nschenswert
            sein, Dateien, die vom Nutzer vera:ndert wurden, nicht zu
            entfernen)

     * FORBIDDEN wird fu:r Ports verwendet, die Sicherheitslu:cken
       enthalten oder die ernste Sicherheitsbedenken fu:r das
       FreeBSD-System aufwerfen, wenn sie installiert sind (z.B. ein
       als unsicher bekanntes Programm, oder ein Programm, das einen
       Dienst zur Verfu:gung stellt, der leicht kompromittiert werden
       kann). Ports sollten als FORBIDDEN gekennzeichnet werden,
       sobald ein Programm eine Schwachstelle hat und kein Update
       vero:ffentlicht wurde. Idealerweise sollten Ports so bald wie
       mo:glich aktualisiert werden wenn eine Sicherheitslu:cke
       entdeckt wurde, um die Zahl verwundbarer FreeBSD-Hosts zu
       verringern (wir scha:tzen es fu:r unsere Sicherheit bekannt zu
       sein), obwohl es manchmal einen beachtlichen Zeitabstand
       zwischen der Bekanntmachung einer Schwachstelle und dem
       entsprechenden Update gibt. Bitte kennzeichnen Sie einen Port
       nicht aus irgendeinem Grund ausser Sicherheit als FORBIDDEN.

     * IGNORE ist fu:r Ports reserviert, die aus anderen Gru:nden
       nicht gebaut werden sollten. Es sollte fu:r Ports verwendet
       werden, in denen ein strukturelles Problem vermutet wird. Der
       Build-Cluster wird unter keinen Umsta:nden Ports, die mit
       IGNORE markiert sind, erstellen. Verwenden Sie IGNORE zum
       Beispiel, wenn ein Port:

          * kompiliert, aber nicht richtig la:uft

          * nicht auf der installierten Version von FreeBSD la:uft

          * FreeBSD Kernelquelltext zum Bauen beno:tigt, aber der
            Benutzer diese nicht installiert hat

          * ein Distfile beno:tigt, welches aufgrund von
            Lizenzbeschra:nkungen nicht automatisch abgerufen werden
            kann

          * nicht korrekt mit einem momentan installiertem Port
            arbeitet (der Port ha:ngt zum Beispiel von www/apache21
            ab, aber www/apache13 ist installiert)

         Anmerkung: Wenn ein Port mit einem momentan installiertem
         Port kollidiert (zum Beispiel, wenn beide eine Datei an die
         selbe Stelle installieren, diese aber eine andere Funktion
         hat), benutzen Sie stattdessen CONFLICTS. CONFLICTS setzt
         IGNORE dann selbststa:ndig.

     * Um einen Port nur auf bestimmte Systemarchitekturen mit IGNORE
       zu markieren, gibt es zwei Variablen, die automatisch IGNORE
       fu:r Sie setzen: ONLY_FOR_ARCHS und NOT_FOR_ARCHS. Beispiele:

 ONLY_FOR_ARCHS= i386 amd64

 NOT_FOR_ARCHS= alpha ia64 sparc64

       Eine eigene IGNORE-Ausgabe kann mit ONLY_FOR_ARCHS_REASON und
       NOT_FOR_ARCHS_REASON festgelegt werden. Fu:r eine bestimmte
       Architektur sind Angaben durch ONLY_FOR_ARCHS_REASON_ARCH und
       NOT_FOR_ARCHS_REASON_ARCH mo:glich.

     * Wenn ein Port i386-Bina:rdateien herunterla:dt und
       installiert, sollte IA32_BINARY_PORT gesetzt werden. Wenn die
       Variable gesetzt ist, wird u:berpru:ft, ob das Verzeichnis
       /usr/lib32 fu:r IA32-Versionen der Bibliotheken vorhanden ist,
       und ob der Kernel mit IA32-Kompatibilita:t gebaut wurde. Wenn
       eine dieser zwei Voraussetzungen nicht erfu:llt ist, wird
       IGNORE automatisch gesetzt.

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

  12.14.2. Anmerkungen zur Implementierung

   Zeichenketten sollten nicht in Anfu:hrungszeichen gesetzt werden.
   Auch die Wortwahl der Zeichenketten sollte die Art und Weise
   beachten, wie die Informationen dem Nutzer angezeigt werden.
   Beispiele:

 BROKEN= this port is unsupported on FreeBSD 5.x

 IGNORE= is unsupported on FreeBSD 5.x

   resultieren in den folgenden Ausgaben von make describe:

 ===>  foobar-0.1 is marked as broken: this port is unsupported on FreeBSD 5.x.

 ===>  foobar-0.1 is unsupported on FreeBSD 5.x.

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

12.15. Kennzeichnen eines Ports zur Entfernung durch DEPRECATED oder
EXPIRATION_DATE

   Denken Sie bitte daran, dass BROKEN und FORBIDDEN nur als
   tempora:rer Ausweg verwendet werden sollten, wenn ein Port nicht
   funktioniert. Dauerhaft defekte Ports sollten komplett aus der
   Ports-Sammlung entfernt werden.

   Wenn es sinnvoll ist, ko:nnen Benutzer vor der anstehenden
   Entfernung eines Ports mit DEPRECATED und EXPIRATION_DATE gewarnt
   werden. Ersteres ist einfach eine Zeichenkette, die angibt, warum
   der Port entfernt werden soll. Letzteres ist eine Zeichenkette im
   ISO 8601-Format (JJJJ-MM-TT). Beides wird dem Benutzer gezeigt.

   Es ist mo:glich DEPRECATED ohne EXPIRATION_DATE zu setzen (zum
   Beispiel, um eine neuere Version des Ports zu empfehlen), aber das
   Gegenteil ist sinnlos.

   Es gibt keine Vorschrift wie lange die Vorwarnzeit sein muss.
   Gegenwa:rtig ist es u:blich einen Monat fu:r sicherheitsrelevante
   Probleme und zwei Monate fu:r Build-Probleme anzusetzen. Dies gibt
   allen interessierten Committern ein wenig Zeit die Probleme zu
   beheben.

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

12.16. Vermeiden Sie den Gebrauch des .error-Konstruktes

   Der korrekte Weg eines Makefile anzuzeigen, dass der Port aufgrund
   eines externen Grundes nicht installiert werden kann (zum
   Beispiel, weil der Benutzer eine ungu:ltige Kombination von
   Build-Optionen angegeben hat), ist IGNORE auf einen nicht leeren
   Wert zu setzen. Dieser wird dann formatiert und dem Benutzer von
   make install ausgegeben.

   Es ist ein verbreiteter Fehler .error fu:r diesem Zweck zu
   verwenden. Das Problem dabei ist, dass viele automatisierte
   Werkzeuge, die mit dem Ports-Baum arbeiten, in dieser Situation
   fehlschlagen. Am Ha:ufigsten tritt das Problem beim Versuch
   /usr/ports/INDEX zu bauen auf (siehe Abschnitt 9.1). Jedoch
   schlagen auch trivialere Befehle wie make maintainer in diesem
   Fall fehl. Dies ist nicht akzeptabel!

   Beispiel 12-1. Wie vermeidet man die Verwendung von .error

   Nehmen Sie an, dass die Zeile

 USE_POINTYHAT=yes

   in make.conf enthalten ist. Der erste der folgenden zwei
   Makefile-Schnipsel la:sst make index fehlschlagen, wa:hrend der
   zweite dies nicht tut.

 .if USE_POINTYHAT
 .error "POINTYHAT is not supported"
 .endif

 .if USE_POINTYHAT
 IGNORE=POINTYHAT is not supported
 .endif

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

12.17. Verwendung von sysctl

   Vom Gebrauch von sysctl wird, ausser in Targets, abgeraten. Das
   liegt daran, dass die Auswertung aller makevars, wie sie wa:hrend
   make index verwendet werden, dann den Befehl ausfu:hren muss,
   welches den Prozess weiter verlangsamt.

   Die Verwendung von sysctl(8) sollte immer durch die Variable
   SYSCTL erfolgen, da diese den vollsta:ndigen Pfad entha:lt und
   u:berschrieben werden kann, so dies als notwendig erachtet wird.

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

12.18. Erneutes Ausliefern von Distfiles

   Manchmal a:ndern die Autoren der Software den Inhalt
   vero:ffentlichter Distfiles, ohne den Dateinamen zu a:ndern. Sie
   mu:ssen u:berpru:fen, ob die A:nderungen offizell sind und vom
   Autor durchgefu:hrt wurden. Es ist in der Vergangenheit
   vorgekommen, dass Distfiles still und heimlich auf dem
   Download-Server gea:ndert wurden, um Schaden zu verursachen oder
   die Sicherheit der Nutzer zu kompromittieren.

   Verschieben Sie das alte Distfile und laden Sie das neue herunter.
   Entpacken Sie es und vergleichen Sie den Inhalt mittels diff(1).
   Wenn Sie nichts Verda:chtiges sehen ko:nnen Sie distinfo
   aktualisieren. Stellen Sie sicher, dass die A:nderungen in Ihrem
   PR oder Commit-Protokoll zusammengefasst sind, um zu
   Gewa:hrleisten, dass nichts Negatives passiert ist.

   Sie ko:nnen auch mit den Autoren der Software in Verbindung treten
   und sich die A:nderungen besta:tigen lassen.

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

12.19. Verschiedenes

   Die Dateien pkg-descr und pkg-plist sollten beide doppelt
   kontrolliert werden. Wenn Sie einen Port nachpru:fen und glauben,
   dass man es besser machen kann, dann verbessern Sie ihn bitte.

   Bitte kopieren Sie nicht noch mehr Exemplare der GNU General
   Public License in unser System.

   Bitte u:berpru:fen Sie alle gesetzlichen Punkte gru:ndlich! Lassen
   Sie uns bitte keine illegale Software verbreiten!

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

                  Kapitel 13. Beispiel eines Makefile

   Hier ein Beispiel fu:r ein Makefile, welches als Vorlage fu:r
   einen neuen Port dienen kann. Alle zusa:tzlichen Kommentare in
   eckigen Klammern mu:ssen entfernt werden!

   Es wird empfohlen, die hier gezeigte Formatierung zu u:bernehmen
   (Reihenfolge der Variablen, Leerzeichen zwischen einzelnen
   Abschnitten, usw.). Dadurch werden die wichtigen Informationen
   sofort ersichtlich. Zur U:berpru:fung Ihres Makefiles sollten Sie
   portlint verwenden.

 [the header...just to make it easier for us to identify the ports.]
 # New ports collection makefile for:   xdvi
 [the "version required" line is only needed when the PORTVERSION
  variable is not specific enough to describe the port.]
 # Date created:                26 May 1995
 [this is the person who did the original port to FreeBSD, in particular, the
 person who wrote the first version of this Makefile.  Remember, this should
 not be changed when upgrading the port later.]
 # Whom:                        Satoshi Asami <asami@FreeBSD.org>
 #
 # $FreeBSD$
 [ ^^^^^^^^^ This will be automatically replaced with RCS ID string by CVS
 when it is committed to our repository.  If upgrading a port, do not alter
 this line back to "$FreeBSD$".  CVS deals with it automatically.]
 #

 [section to describe the port itself and the master site - PORTNAME
  and PORTVERSION are always first, followed by CATEGORIES,
  and then MASTER_SITES, which can be followed by MASTER_SITE_SUBDIR.
  PKGNAMEPREFIX and PKGNAMESUFFIX, if needed, will be after that.
  Then comes DISTNAME, EXTRACT_SUFX and/or DISTFILES, and then
  EXTRACT_ONLY, as necessary.]
 PORTNAME=      xdvi
 PORTVERSION=   18.2
 CATEGORIES=    print
 [do not forget the trailing slash ("/")!
  if you are not using MASTER_SITE_* macros]
 MASTER_SITES=  ${MASTER_SITE_XCONTRIB}
 MASTER_SITE_SUBDIR= applications
 PKGNAMEPREFIX= ja-
 DISTNAME=      xdvi-pl18
 [set this if the source is not in the standard ".tar.gz" form]
 EXTRACT_SUFX=  .tar.Z

 [section for distributed patches -- can be empty]
 PATCH_SITES=   ftp://ftp.sra.co.jp/pub/X11/japanese/
 PATCHFILES=    xdvi-18.patch1.gz xdvi-18.patch2.gz

 [maintainer; *mandatory*!  This is the person who is volunteering to
  handle port updates, build breakages, and to whom a users can direct
  questions and bug reports.  To keep the quality of the Ports Collection
  as high as possible, we no longer accept new ports that are assigned to
  "ports@FreeBSD.org".]
 MAINTAINER=    asami@FreeBSD.org
 COMMENT=       A DVI Previewer for the X Window System

 [dependencies -- can be empty]
 RUN_DEPENDS=   gs:${PORTSDIR}/print/ghostscript
 LIB_DEPENDS=   Xpm.5:${PORTSDIR}/graphics/xpm

 [this section is for other standard bsd.port.mk variables that do not
  belong to any of the above]
 [If it asks questions during configure, build, install...]
 IS_INTERACTIVE=        yes
 [If it extracts to a directory other than ${DISTNAME}...]
 WRKSRC=                ${WRKDIR}/xdvi-new
 [If the distributed patches were not made relative to ${WRKSRC}, you
  may need to tweak this]
 PATCH_DIST_STRIP=      -p1
 [If it requires a "configure" script generated by GNU autoconf to be run]
 GNU_CONFIGURE= yes
 [If it requires GNU make, not /usr/bin/make, to build...]
 USE_GMAKE=     yes
 [If it is an X application and requires "xmkmf -a" to be run...]
 USE_IMAKE=     yes
 [et cetera.]

 [non-standard variables to be used in the rules below]
 MY_FAVORITE_RESPONSE=  "yeah, right"

 [then the special rules, in the order they are called]
 pre-fetch:
     i go fetch something, yeah

 post-patch:
     i need to do something after patch, great

 pre-install:
     and then some more stuff before installing, wow

 [and then the epilogue]
 .include <bsd.port.mk>

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

                 Kapitel 14. Auf dem Laufenden bleiben

   Die FreeBSD Ports-Sammlung vera:ndert sich sta:ndig. Hier finden
   Sie einige Informationen, wie Sie auf dem Laufenden bleiben.

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

14.1. FreshPorts

   Einer der einfachsten Wege, um sich u:ber Aktualisierungen, die
   bereits durchgefu:hrt wurden, zu informieren, ist sich bei
   FreshPorts anzumelden. Sie ko:nnen dort beliebige Ports
   auswa:hlen, die Sie beobachten mo:chten. Maintainern wird
   ausdru:cklich empfohlen sich anzumelden, da Sie nicht nur u:ber
   Ihre eigenen A:nderungen informiert werden, sondern auch u:ber die
   aller anderen Committer (Diese sind oft no:tig, um u:ber
   A:nderungen des zugrunde liegenden Frameworks informiert zu
   bleiben. Obwohl es ho:flich wa:re, vorher u:ber solche A:nderungen
   benachrichtigt zu werden, wird es manchmal vergessen oder ist
   einfach nicht mo:glich. Ausserdem sind die A:nderungen manchmal
   nur sehr klein. Wir erwarten von jedem in solchen Fa:llen nach
   bestem Gewissen zu urteilen).

   Wenn Sie Fresh-Ports benutzen mo:chten, beno:tigen Sie nur einen
   Account. Falls Sie sich mit einer @FreeBSD.org E-Mailadresse
   registriert haben, werden Sie den Anmeldelink am rechten Rand der
   Seite finden. Diejenigen, die bereits einen FeshPorts-Account
   haben, aber nicht Ihre @FreeBSD.org E-Mailadresse benutzen,
   ko:nnen einfach Ihre E-Mailadresse auf @FreeBSD.org a:ndern, sich
   anmelden, und dann die A:nderung ru:ckga:ngig machen.

   FreshPorts bietet auch eine U:berpru:fungsfunktion, die
   automatisch alle Committs zum FreeBSD Ports-Baum testet. Wenn Sie
   sich fu:r diesen Dienst anmelden, werden Sie u:ber alle Fehler,
   die bei der U:berpru:fung Ihres Committs auftreten, informiert.

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

14.2. Die Webschnittstelle zum Quelltext-Repository

   Es ist mo:glich die Dateien des Quellen-Repositories mit Hilfe
   einer Webschnittstelle durchzusehen. A:nderungen, die das gesamte
   Ports-System betreffen, werden jetzt in der Datei CHANGES
   dokumentiert. Solche, die nur bestimmte Ports betreffen, in der
   Datei UPDATING. Aber die massgebliche Antwort auf alle Fragen
   liegt zweifellos darin, den Quelltext von bsd.port.mk und
   dazugeho:rige Dateien zu lesen.

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

14.3. Die FreeBSD Ports-Mailingliste

   Wenn Sie Maintainer sind, sollten Sie in Erwa:gung ziehen die
   FreeBSD ports-Mailingliste zu verfolgen. Wichtige A:nderungen an
   der grundlegenden Funktionsweise von Ports werden dort
   angeku:ndigt und dann in CHANGES committet.

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

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

   Eine der weniger bekannten Sta:rken von FreeBSD ist es, dass ein
   ganzer Cluster von Maschinen nur dafu:r reserviert ist, andauernd
   die Ports-Sammlung zu bauen, und zwar fu:r jedes grosse FreeBSD
   Release und jede Tier-1-Architektur. Die Ergebnisse ko:nnen Sie
   unter package building logs and errors finden.

   Alle Ports ausser denjenigen, die als IGNORE markiert sind, werden
   gebaut. Ports, die als BROKEN markiert sind, werden dennoch
   ausprobiert, um zu sehen, ob das zugrunde liegende Problem gelo:st
   wurde (Dies wird erreicht, indem TRYBROKEN an das Makefile des
   Ports u:bergeben wird).

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

14.5. Der FreeBSD Ports-Distfile-Scanner

   Der Build-Cluster ist dazu bestimmt, das neueste Release jedes
   Ports aus bereits heruntergeladenden Distfiles zu bauen. Da sich
   das Internet aber sta:ndig vera:ndert, ko:nnen Distfiles schnell
   verloren gehen. Der FreeBSD Ports-Distfile-Scanner versucht jeden
   Download-Standort fu:r jeden Port anzufragen, um herauszufinden,
   ob jedes Distfile noch verfu:gbar ist. Maintainer werden gebeten
   diesen Bericht regelma:ssig durchzusehen, nicht nur, um den
   Build-Prozess fu:r die Nutzer zu beschleunigen, sondern auch um zu
   vermeiden, dass auf den Maschinen, die freiwillig zur Verfu:gung
   gestellt werden, um all diese Dateien anzubieten, Ressourcen
   verschwendet werden.

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

14.6. Das FreeBSD Ports-Monitoring-System

   Eine weitere praktische Ressource ist das FreeBSD
   Ports-Monitoring-System (auch bekannt als portsmon). Dieses System
   besteht aus einer Datenbank, die Informationen von mehreren
   Quellen bezieht und es erlaubt diese u:ber ein Webinterface
   abzufragen. Momentan werden die Ports-Problemberichte (PRs), die
   Fehlerprotokolle des Build-Clusters und die einzelnen Dateien der
   Ports-Sammlung verwendet. In Zukunft soll das auf die
   Distfile-Pru:fung und weitere Informationsquellen ausgedehnt
   werden.

   Als Ausgangspunkt ko:nnen Sie alle Informationen eines Ports mit
   Hilfe der U:bersicht eines Ports betrachten.

   Zum Zeitpunkt des Schreibens ist dies die einzige Quelle, die
   GNATS PR-Eintra:ge auf Portnamen abbildet (PR-Einreicher geben den
   Portnamen nicht immer in der Zusammenfassung an, obwohl wir uns
   das wu:nschen wu:rden). Also ist portsmon ein guter Anlaufpunkt,
   wenn Sie herausfinden wollen, ob zu einem existierenden Port PRs
   oder Buildfehler eingetragen sind. Oder um herauszufinden, ob ein
   neuer Port, den Sie erstellen wollen, bereits eingereicht wurde.

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

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