Index: head/de_DE.ISO8859-1/books/porters-handbook/book.xml =================================================================== --- head/de_DE.ISO8859-1/books/porters-handbook/book.xml (revision 52709) +++ head/de_DE.ISO8859-1/books/porters-handbook/book.xml (revision 52710) @@ -1,16632 +1,16633 @@ Das FreeBSD Porter-Handbuch The FreeBSD German Documentation Project April 2000 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 The FreeBSD German Documentation Project &trademarks; &legalnotice; $FreeBSD$ Einfhrung Die Ports-Sammlung von FreeBSD ist der gebruchlichste Weg, um Anwendungen ("Ports") unter FreeBSD zu installieren. Wie alles andere in FreeBSD auch, ist sie hauptschlich 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 erklren, einen bereits vorhandenen Port zu pflegen, sofern der Port derzeit keinen Maintainer hat – dazu sind keine besonderen Rechte ntig. Einen neuen Port erstellen Sie sind also daran interessiert, einen neuen Port zu erstellen oder einen vorhandenen zu aktualisieren? Groartig! Die folgenden Kapitel beinhalten einige Richtlinien, um einen neuen Port fr FreeBSD zu erstellen. Wenn Sie einen vorhandenen Port auf den neuesten Stand bringen wollen, sollten Sie mit 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 tglich mit Makefiles arbeiten, sollten Sie gut damit zurecht kommen, da die Datei gut dokumentiert ist und Sie eine Menge Wissen daraus erlangen knnen. Zustzlich knnen Sie speziellere Fragen an die &a.ports;-Mailingliste stellen. Nur ein Bruchteil der Variablen (VAR), die von Ihnen gesetzt werden knnen, finden hier Erwhnung. Die meisten von ihnen (wenn nicht sogar alle) sind am Anfang von /usr/ports/Mk/bsd.port.mk erlutert. Beachten Sie bitte, dass diese Datei eine nicht standardkonforme Tabulator-Einstellung verwendet. Emacs und Vim sollten diese Einstellung jedoch automatisch beim ffnen der Datei setzen. Sowohl &man.vi.1; als auch &man.ex.1; knnen mit dem Befehl :set tabstop=4 dazu gebracht werden, die Datei richtig anzuzeigen, wenn sie geffnet wird. Sind Sie auf der Suche nach einer neuen Aufgabe? Dann sehen Sie sich bitte die Ports-Wunschliste an und prfen Sie, ob Sie an einem dieser Ports arbeiten knnen. Einen neuen Port erstellen Dieser Abschnitt beschreibt, wie Sie schnell einen neuen Port erstellen knnen. In vielen Fllen ist dies allerdings nicht ausreichend, dann werden Sie in diesem Buch weiterlesen mssen. Als Erstes besorgen Sie sich das Original-Tarball (komprimiertes Archiv) und legen es im DISTDIR ab, welches standardmig /usr/ports/distfiles ist. Im Folgenden wird angenommen, dass die Software unverndert kompiliert werden konnte, dass also keinerlei nderungen ntig waren, um den Port auf Ihrem FreeBSD-Rechner zum Laufen zu bringen. Falls Sie nderungen vornehmen mussten, werden Sie auch den nchsten Abschnitt beachten mssen. Das <filename>Makefile</filename> 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 eingefgt, wenn der Port in den Haupt-Ports-Tree importiert wird. Ein detailliertes Beispiel finden Sie im Abschnitt sample Makefile. Die Beschreibungsdateien erstellen Es gibt zwei Beschreibungsdateien, die fr jeden Port bentigt werden, ob sie tatschlich im Paket enthalten sind oder nicht. Dies sind pkg-descr und pkg-plist. Der pkg- Prfix unterscheidet sie von anderen Dateien. <filename>pkg-descr</filename> Diese enthlt eine lngere Beschreibung des Ports. Einer oder mehrere Abstze, die kurz und prgnant erklren, was der Port macht, sind ausreichend. pkg-descr enthlt 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 prgnanten Beschreibungen des Ports oder sie sind in einem ungnstigen Format (Manualpages haben z.B. bndige Zwischenrume). Wenn es fr die portierte Software eine offizielle Webseite gibt, sollten Sie diese hier angeben. Fgen Sie hierzu eine der Webseiten mit dem Prfix 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/ <filename>pkg-plist</filename> Diese Datei enthlt eine Liste aller Dateien, die von diesem Port installiert werden. Sie wird auch die Packliste genannt, da das Paket durch die hier aufgefhrten Dateien erstellt wird. Die Pfadangaben sind relativ zum Installationsprfix (fr gewhnlich /usr/local oder /usr/X11R6). Wenn Sie die MANn-Variablen verwenden (was Sie auch machen sollten), fhren Sie hier keine Manualpages auf. Wenn der Port whrend der Installation Verzeichnisse erstellt, stellen Sie sicher entsprechende @dirrm-Zeilen einzufgen, um die Verzeichnisse zu entfernen, wenn das Paket gelscht 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 Fr weitere Details zur Packliste lesen Sie in der &man.pkg.create.1; Manualpage nach. Es wird empfohlen alle Dateinamen in dieser Datei alphabetisch sortiert zu halten. Das erlaubt Ihnen die nderungen bei einem Upgrade Ihres Ports deutlich einfacher zu berprfen. Eine Packlist von Hand zu erzeugen kann eine sehr mhsame Aufgabe sein. Wenn der Port eine groe 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, knnen diese in den Variablen PLIST_FILES und PLIST_DIRS im Makefile aufgelistet werden. Zum Beispiel knnten wir im obigen Beispiel ohne pkg-plist fr den oneko-Port auskommen, indem wir die folgenden Zeilen ins Makefile einfgen: 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 Natrlich sollte PLIST_DIRS ungesetzt bleiben, wenn der Port keine eigenen Verzeichnisse installiert. Der Preis fr diese Art die Dateien eines Ports anzugeben ist, dass man keine Befehlsfolgen wie in &man.pkg.create.1; nutzen kann. Deshalb ist es nur fr 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 Erwgung, bevor Sie pkg-plist benutzen. Spter werden wir uns ansehen, wie pkg-plist und PLIST_FILES benutzt werden knnen, um anspruchsvollere Aufgaben zu erfllen. Die Checksummendatei erzeugen Geben Sie einfach make makesum ein. Die Regeln von Make sorgen dafr, dass die Datei distinfo automatisch erstellt wird. Wenn sich die Checksumme einer heruntergeladenen Datei regelmig ndert und Sie sicher sind, dass Sie der Quelle trauen knnen (weil sie z.B. von einer Hersteller-CD oder tglich erstellter Dokumentation stammt), sollten Sie diese Dateien in der Variable IGNOREFILES angeben. Dann wird die Checksumme fr diese Datei bei make makesum nicht berechnet, sondern auf IGNORE gesetzt. 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 berprfen sollten. pkg-plist enthlt nichts, das nicht von Ihrem Port installiert wurde. pkg-plist enthlt alles, was von Ihrem Port installiert wurde. Ihr Port kann mit Hilfe von make reinstall mehrmals installiert werden. Ihr Port rumt bei der Deinstallation hinter sich auf. Empfohlene Testreihenfolge make install make package make deinstall pkg_add Paket-Name make deinstall make reinstall make package Stellen Sie bitte sicher, dass whrend make package und make deinstall keine Warnungen ausgegeben werden. Nach Schritt 3 berprfen 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 grndlichste Weg diese Schritte zu automatisieren ist eine Tinderbox zu installieren. Diese verwaltet Jails, in denen Sie alle oben genannten Schritte durchfhren knnen, ohne den Zustand Ihres laufenden Systems zu verndern. Mehr Informationen hierzu entlt ports/ports-mgmt/tinderbox Ihren Port mit <command>portlint</command> berprfen 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. 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, mssen Sie ihn nur noch in den Haupt-Ports-Tree von &os; einbringen, damit alle daran teilhaben knnen. Wir bentigen nicht Ihr work-Verzeichnis oder Ihr pkgname.tgz-Paket – diese knnen Sie nun lschen. Wenn Ihr Port beispielsweise oneko heit, wechseln Sie in das Verzeichnis, in dem sich das Verzeichnis oneko befindet und fhren den Befehl shar `find oneko` > oneko.shar aus. Fgen Sie Ihre Datei oneko.shar einem Fehlerbericht an und senden Sie diesen mit Hilfe des Programms &man.send-pr.1; (unter Bug Reports and General Commentary finden Sie weitere Informationen ber &man.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)!). Fgen 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). Sie knnen 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> fr neue Ports. Wenn Sie sich an dieses Schema halten, ist die Chance, dass sich jemand bald Ihren Bericht ansieht, deutlich besser. Noch einmal: Bitte fgen Sie nicht das distfile der Originalquelle, das work-Verzeichnis oder das Paket, das Sie mit make package erstellt haben, ein. Und verwenden Sie &man.shar.1; fr neue Ports (und NICHT &man.diff.1;). Haben Sie bitte etwas Geduld, nachdem Sie den Port eingereicht haben. Manchmal kann es einige Monate dauern, bevor ein Port in &os; eingefgt wird, obwohl es wahrscheinlich nur ein paar Tage dauert. Sie knnen sich die Liste der PRs, die darauf warten, in &os; committet zu werden, ansehen. Nachdem wir einen Blick auf Ihren Port geworfen haben, werden wir, wenn ntig, bei Ihnen nachfragen und ihn in die Ports-Sammlung bernehmen. Ihr Name taucht dann auch in der Liste der Additional FreeBSD Contributors und in anderen Dateien auf. Ist das nicht toll?! :-) Einen Port in aller Ruhe erstellen Ok, das war nicht ganz einfach und der Port hat einige Vernderungen erfordert, um funktionieren zu knnen. In diesem Abschnitt werden wir Schritt fr Schritt erklren, wie man den funktionierenden Port den Vorgaben der Ports entsprechend anpasst. Die Funktionsweise Beginnen wir mit der Abfolge der Ereignisse, die eintreten, wenn der Nutzer das erste make in Ihrem Portsverzeichnis ausfhrt. Sie empfinden es fr das Verstndnis vielleicht hilfreich bsd.port.mk in einem anderen Fenster offen zu haben, whrend Sie diesen Abschnitt lesen. Aber machen Sie sich keine Sorgen, falls Sie nicht wirklich verstehen, was bsd.port.mk macht, die Wenigsten begreifen dies... :> Das Target fetch wird aufgerufen. Es ist dafr verantwortlich sicherzustellen, dass der Tarball lokal im DISTDIR verfgbar ist. Falls fetch die bentigten 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 fr weitere Nutzung abgelegt und fhrt fort. Das Target extract wird aufgerufen. Es sucht nach den Distfiles Ihres Ports (normalerweise ein gzip-komprimierter Tarball) in DISTDIR und entpackt diese in ein temporres Unterverzeichnis, welches von WRKDIR festgelegt wird (standardmig work). Das Target patch wird aufgerufen. Zuerst werden alle in PATCHFILES festgelegten Patches eingespielt. Anschlieend werden, falls Patches der Form patch-* in PATCHDIR (standardmig das files-Unterverzeichnis) gefunden werden, diese in alphabetischer Reihenfolge eingespielt. Das Target configure wird aufgerufen. Dieses kann viele verschiedene Dinge machen. Existiert scripts/configure, so wird es aufgerufen. Falls HAS_CONFIGURE oder GNU_CONFIGURE gesetzt sind, wird WRKSRC/configure ausgefhrt. Falls USE_IMAKE gesetzt ist, wird XMKMF (standardmig xmkmf -a) ausgefhrt. Das Target build wird aufgerufen. Es ist fr das Wechseln in das private Arbeitsverzeichnis (WRKSRC) und das Bauen des Ports zustndig. Ist USE_GMAKE gesetzt, so wird GNU make verwendet, sonst das System-make. Die oben genannten Schritte sind die Standardaktionen. Zustzlich knnen 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 ausgefhrt, bevor die vordefinierten Bau-Regeln abgearbeitet sind. Es wird empfohlen, dass Sie Makefile-Targets verwenden, falls die Aktionen es erlauben, da es so fr jemanden einfacher sein wird herauszufinden, was fr eine nicht-standardmige Aktion der Port bentigt. Die Standardaktionen werden aus den Targets bsd.port.mk do-irgendwas 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, knnen Sie es verndern, indem Sie das Target do-irgendwas in Ihrem Makefile neu definieren. 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 gendert werden. Falls Sie das Entpacken verndern wollen, verndern 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. 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 mglich, 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 fr die gebruchlichsten Seiten. Bitte nutzen Sie diese Seiten und die zugehrigen Definitionen, soweit dies mglich ist. Damit wird vermieden, immer und immer wieder dieselben Informationen zu wiederholen. Da die Hauptseiten regelmig angepasst werden mssen, vereinfacht dieses Vorgehen die Pflege der Dateien fr jeden Beteiligten. Falls keine zuverlssige 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 zuverlssigen Seite abgelegt werden. Dies knnte z.B. die eigene Internetseite sein. Ist kein geeigneter Ort zum Ablegen des Quelltextes auffindbar, ist es mglich diesen intern auf ftp.FreeBSD.org abzulegen; dies sollte jedoch als letzte Mglichkeit 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 auerdem MASTER_SITES nach MASTER_SITE_LOCAL und MASTER_SITE_SUBDIR auf den freefall-Benutzernamen angepasst. Sollte sich das Distfile des Ports regelmig ohne Versionsanpassungen des Autors ndern, sollte berlegt werden, das Disfile auf der eigenen Internetseite abzulegen und diese in der Liste der MASTER_SITES an die erste Stelle zu setzen. Falls mglich, sollte der Autor des Ports gebeten werden, dies zu erledigen; hierber wird die Kontrolle des Quelltextes verbessert. Wird eine eigene Version des Quelltextes auf eigenen Internetseiten verfgbar gemacht, verhindert dies Warnungen von checksum mismatch und reduziert den Arbeitsaufwand der Maintainer der FTP-Seiten. Auch wenn nur eine Quelle fr den Quelltext des Ports zur Verfgung steht, ist es empfohlen, ein Backup auf einer weiteren Seite abzulegen und diese als zweiten Eintrag in MASTER_SITES aufzunehmen. Sind fr den Port zustzlich aus dem Internet verfgbare 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 ). Den Port bearbeiten Entpacken Sie eine Kopie des Tarballs in ein privates Verzeichnis und nehmen Sie alle nderungen vor, die ntig sind, um den Port unter einer aktuellen &os;-Version kompilieren zu knnen. Protokollieren Sie sorgfltig alle Schritte, die Sie vornehmen, da Sie den Prozess in Krze automatisieren werden. Alles, auch das Entfernen, Hinzufgen 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/Vernderungen durch den Benutzer bentigt, um ihn zu Kompilieren oder zu Installieren, sollten Sie einen Blick auf Larry Walls klassische Configure-Skripte werfen oder vielleicht etwas hnliches selbst erstellen. Das Ziel der Ports-Sammlung ist es, jeden Port so plug-and-play-fhig wie mglich fr den Endbenutzer zu machen, whrend ein Minimum an Speicherplatz gebraucht wird. Solange nicht anders angegeben wird von Patch-Dateien, Skripten und anderen Dateien, die Sie erstellt und der &os; Ports-Sammlung hinzugefgt haben, angenommen, dass Sie unter den standardmigen BSD-Copyright-Bedingungen stehen. Fehlerbehebung (Patches) Bei der Vorbereitung eines Ports knnen die Dateien, die hinzugefgt oder verndert wurden, mittels &man.diff.1; abgefangen werden, um Sie spter an &man.patch.1; zu bergeben. Jeder Patch, der dem Quelltext 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 bernommen werden. Alle Patches mssen 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 fr eine Datei zu nutzen (z.B. patch-file und patch-file2, welche beide WRKSRC/foobar.c verndern). Beachten Sie, dass, falls der Pfad einer zu korrigierenden Datei einen Unterstrich (_) enthlt, 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. Fr 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, erwhnen Sie immer den Pfad und Dateinamen. RCS-Zeichenketten sollten vermieden werden, da CVS diese verstmmeln wrde, sobald wir diese Dateien in die Ports-Sammlung einpflegen. Wenn wir die Dateien wieder abrufen wren diese verndert und der Patch wrde fehlschlagen. RCS-Zeichenketten sind in Dollar-Zeichen ($) eingefgte Zeichen und beginnen blicherweise mit $Id oder $RCS. Die Option rekursiv () zu nutzen &man.diff.1;, um Patches zu erstellen, ist zulssig, jedoch sollte der Patch anschlieend geprft werden, um Unntiges 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, berflssig 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 gro!); – hier sollte USE_AUTOTOOLS=autoconf:261 definiert und das Diff aus configure.in genutzt werden. Zustzlich sollte man unntige Markup-nderungen in Patches/nderungen mglichst vermeiden. In der Open Source-Welt teilen sich Projekte hufig groe Teile des Quellcodes. Allerdings verwenden die einzelnen Projekte oft unterschiedliche Programmierstile und Vorgaben fr Einrckungen. Wenn man also einen funktionierenden Teil einer Funktion aus einem Projekt verwendet, um ein hnliches Problem in einem anderen Projekt zu lsen, sollte man besonders vorsichtig sein, weil sich ansonsten die CVS-nderungseintrge mit berflssigen Eintrgen fllen, die nur das Markup des Quellcodes betreffen, ohne dass sich an der Funktion des eigentlichen Quellcode etwas ndert (withspace-only changes). Solche nderungen vergrern nicht nur das CVS-Repository, sondern erschweren es auch die Ursache fr eventuell auftretende Probleme zu finden. War es notwendig eine Datei zu entfernen, wird dies besser mittels des post-extract-Targets als ber den Patch selbst realisiert. Ein einfacher Austausch kann direkt ber das Makefile des Ports umgesetzt werden, indem der in-place-Modus von &man.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 hufig ergibt sich die Situation, in der die portierte Software die CR/LF-Konventionen fr Zeilenenden nutzt (dies ist bei unter &windows; entwickelter Software hufig der Fall). Dies kann bei weiteren Patches Probleme (Compiler-Warnungen, Fehlermeldungen bei der Ausfhrung 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 ber verschiedene Unterverzeichnisse konvertiert werden, kann DOS2UNIX_REGEX genutzt werden, dessen Argumente find-kompatible, regulre Ausdrcke sind. Mehr zur Formatierung findet sich in &man.re.format.7;. Diese Option ist beim Konvertieren aller Dateien mit definierter Endung, z.B. aller Dateien im Quellcode, wobei binre Dateien unberhrt bleiben, sinnvoll: USE_DOS2UNIX= yes DOS2UNIX_REGEX= .*\.(c|cpp|h) Wenn Sie einen Patch zu einer bereits existierenden Datei erstellen wollen, knnen Sie von ihr eine Kopie mit der Endung .orig erstellen und anschlieend die Originaldatei bearbeiten. Das make-Ziel makepatch fhrt dann zu einer entsprechenden Patch-Datei im Verzeichnis files des Ports. Konfigurieren Fgen Sie alle zustzlichen Vernderungsbefehle Ihrem Skript configure hinzu und speichern Sie es im scripts-Unterverzeichnis. Wie vorstehend schon erwhnt, knnen Sie dies auch mit den Targets Makefile und/oder Skripte mit dem Namen pre-configure oder post-configure erledigen. Handhabung von Benutzereingaben Sollte der Port Eingaben vom Benutzer bentigen, muss IS_INTERACTIVE im Makefile des Ports gesetzt werden. Dies erlaubt overnight builds Ihren Port zu 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 fr interaktive Optionen gesetzt sind, die PACKAGE_BUILDING-Variable zu prfen und das interaktive Skript abzuschalten. Dies macht es uns mglich, Pakete fr CDROMs und FTP-Server zu bauen. Die Konfiguration des Makefile Das Konfigurieren des Makefile ist sehr einfach und wir schlagen vor, dass Sie zunchst einen Blick auf vorhandene Beispiele werfen. Zustzlich 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: 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, knnen Sie zum nchsten Schritt bergehen. Falls nicht, sollten Sie versuchen, die Variablen DISTVERSION, DISTNAME, EXTRACT_CMD, EXTRACT_BEFORE_ARGS, EXTRACT_AFTER_ARGS, EXTRACT_SUFX, oder DISTFILES zu ndern. Das hngt davon ab, wie fremdartig das Distributionsfile Ihres Ports ist (der hufigste Fall ist EXTRACT_SUFX=.tar.Z, wenn der Tarball durch ein normales compress und nicht durch gzip gepackt wurde). Im schlimmsten Fall knnen Sie einfach Ihre eigene Vorgabe mittels do-extract erzeugen und die Standardvorgabe berschreiben; aber dies sollte in den wenigsten Fllen, wenn berhaupt, notwendig sein. Bezeichnungen Der erste Teil des Makefile beschreibt die Versionsnummer des Ports und fhrt ihn in der richtigen Kategorie auf. <varname>PORTNAME</varname> und <varname>PORTVERSION</varname> Setzen Sie bitte die Variable PORTNAME auf den Basisnamen Ihres Ports und die Variable PORTVERSION auf dessen Versionsnummer. <varname>PORTREVISION</varname> und <varname>PORTEPOCH</varname> <varname>PORTREVISION</varname> Die PORTREVISION-Variable ist ein streng monoton wachsender Wert, welcher auf 0 zurckgesetzt wird, nachdem PORTVERSION erhht wurde (d.h. jedes Mal, wenn ein offizielles Release erfolgt). Sie wird an den Namen des Pakets angehngt, wenn sie ungleich 0 ist. nderungen an PORTREVISION werden von automatisierten Werkzeugen (z.B. &man.pkg.version.1;) genutzt, um anzuzeigen, dass ein neues Paket verfgbar ist. PORTREVISION sollte jedes Mal erhht werden, wenn eine nderung am Port erfolgt, die betrchtliche Auswirkungen auf den Inhalt oder Struktur des aus dem Port erzeugten Pakets zur Folge hat. Beispiele dafr, wann PORTREVISION erhht werden sollte: Hinzufgen von Patches, welche Sicherheitslcken schlieen, Fehler beseitigen oder neue Funktionalitt zum Port hinzufgen. nderungen am Makefile des Ports, welche compile-time-Optionen hinzufgen oder entfernen. nderungen bezglich Packliste oder am Verhalten whrend der Installation des Pakets (d.h. nderungen an einem Skript, welches Ausgangsdaten fr das Paket erzeugt, wie z.B. SSH-Hostschlssel). Versionssprung einer Shared-Library, welche eine Abhngigkeit dieses Ports ist (In diesem Fall wrde ein Anwender bei der Installation des alten Pakets scheitern, falls er eine neue Version der Abhngigkeit bereits installiert hat, weil nach der alten Bibliothek libfoo.x anstatt nach libfoo.(x+1)) gesucht wird). Schleichende nderungen am Distfile, welche bedeutende funktionale nderungen verursachen, d.h. nderungen des Distfile erfordern eine Korrektur an distinfo, ohne dass damit zusammenhngend die PORTVERSION verndert wird, obwohl ein diff -ru zwischen der alten und der neuen Version bedeutende Vernderungen am Code nachweist. Beispiele fr nderungen, welche keine Erhhung von PORTREVISION erfordern: Stilistische nderungen am Grundgerst des Ports ohne funktionale nderungen am daraus resultierenden Paket. nderungen an der Variable MASTER_SITES oder andere funktionale nderungen, welche das resultierende Paket nicht verndern. Marginale Patches am Distfile wie die Korrektur von Tippfehlern, welche nicht wichtig genug sind, um dem Benutzer die Brde eines Upgrades aufzuerlegen. Build fixes, die ein Paket erst kompilierbar machen, welches ohne diese nderungen vorher nicht erzeugt werden konnte (solange die nderungen keine funktionale Differenz bringen auf Plattformen, auf denen dieses Paket schon vorher gebaut werden konnte). Da PORTREVISION den Inhalt des Pakets wiederspiegelt, ist es nicht notwendig PORTREVISION zu erhhen, wenn das Paket vorher nicht erstellt werden konnte. Als Faustregel gilt: Stellen Sie sich die Frage, ob die durchgefhrte nderung am Port jedem hilft (entweder aufgrund einer Verbesserung, Beseitigung eines Fehlers, oder der Annahme, dass das neue Paket berhaupt erst funktioniert) und wgen Sie es gegen den Umstand ab, dass jedermann, der seine Ports-Sammlung regelmssig auf dem neuesten Stand hlt, zu einer Aktualisierung gezwungen wird. Falls Sie die Frage positiv beantworten sollten, erhhen Sie die Variable PORTREVISION. <varname>PORTEPOCH</varname> Von Zeit zu Zeit geschieht es, dass irgendjemand (Drittanbieter von Software oder FreeBSD Ports Committer) etwas Dummes tut und eine Version einer Software verffentlicht, deren Versionsnummer niedriger ist als die der vorherigen. Ein Beispiel hierfr ist ein Port, der von foo-20000801 auf foo-1.0 gendert wird (der Erstere wird flschlicherweise als neue Version behandelt, weil 2000801 ein numerisch grerer Wert ist als 1). In Situationen wie diesen sollte die Variable PORTEPOCH erhht werden. Wenn PORTEPOCH grer als 0 ist, wird sie an den Namen des Pakets angehngt, wie in Abschnitt 0 oberhalb bereits beschrieben. PORTEPOCH darf niemals verringert oder auf 0 gesetzt werden, weil der Vergleich des Pakets mit einem frheren Zeitpunkt scheitern wrde (d.h. das Paket wrde 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 grer erkannt, als das implizit angenommene Suffix ,0 im frheren Paket. Das Entfernen oder Zurcksetzen von PORTEPOCH fhrt zu unendlichem rger. Wenn Sie die obigen Ausfhrungen nicht vollstndig verstanden haben, lesen Sie es bitte unbedingt nochmals bis Sie es vollstndig verinnerlicht haben, oder fragen Sie vor jeder nderung auf den Mailinglisten nach! Es wird erwartet, dass PORTEPOCH fr die weitaus berwiegende Zahl der Ports nicht verwendet wird und der verantwortungsvolle und vorausschauende Umgang mit PORTVERSION macht es meist berflssig, falls ein spteres Release die Versionsstruktur ndern sollte. Vorsicht ist geboten, wenn ein Release einer Drittanbieter-Software ohne eine offizielle Versionsnummer verffentlicht 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 fhrt, wenn das nchste offizielle Release erscheint. Wenn z.B. ein Snapshot zum Datum 20000917 verffentlicht wird und die vorherige Version der Software war 1.2, dann sollte der Snapshot die PORTVERSION 1.2.20000917 oder hnlich erhalten und nicht 20000917, damit das nachfolgende Release, angenommen 1.3, immer noch einen greren numerischen Wert aufweist. Beispiel fr den Gebrauch von <varname>PORTREVISION</varname> und <varname>PORTEPOCH</varname> 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 erhht. PORTNAME= gtkmumble PORTVERSION= 0.10 PORTREVISION= 1 PKGNAME wird zu gtkmumble-0.10_1 Eine neue Version wird vom Software-Drittanbieter verffentlicht, 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 spt). Da die neue Unterversion 2 numerisch kleiner ist als die vorherige Version 10, muss PORTEPOCH erhht werden, um sicherzustellen, dass das neue Paket auch als neuer erkannt wird. Da es ein neues Release des Drittanbieters ist, wird PORTREVISION auf 0 zurckgesetzt (oder aus dem Makefile entfernt). PORTNAME= gtkmumble PORTVERSION= 0.2 PORTEPOCH= 1 PKGNAME wird zu gtkmumble-0.2,1 Das nchste 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 Falls PORTEPOCH mit diesem Upgrade auf 0 zurckgesetzt worden wre, dann wrde jemand, der das Paket gtkmumble-0.10_1 installiert htte, 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. <varname>PKGNAMEPREFIX</varname> und <varname>PKGNAMESUFFIX</varname> Zwei optionale Variablen, PKGNAMEPREFIX und PKGNAMESUFFIX, werden verknpft mit PORTNAME und PORTVERSION, um PKGNAME zu bilden als ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION} . Stellen Sie bitte unbedingt sicher, dass diese Variablen den Richtlinien fr einen guten Paketnamen entsprechen. Insbesondere drfen 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! <varname>LATEST_LINK</varname> Die Umgebungsvariable LATEST_LINK wird whrend der Paketerstellung verwendet, um einen Kurznamen festzulegen, der danach von pkg_add -r genutzt werden kann. Dadurch wird es beispielsweise mglich, 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 Fllen knnen mehrere Versionen einer Applikation gleichzeitig in der Ports-Sammlung sein. Das index build- und das package build-System mssen 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 Fllen sollte die optionale Variable LATEST_LINK auf einen unterschiedlichen Wert fr alle Ports gesetzt werden mit Ausnahme des Haupt-Ports. Beispiele hierfr 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 fr alle Versionen (aber nicht fr die Hauptversion) ntzlich sein kann. Beachten Sie bitte, dass die Frage der Auswahl der wichtigsten Version (am populrsten, am besten Untersttzt, zuletzt gepatcht usw.) ausserhalb der Mglichkeiten dieses Handbuches liegt. Wir sagen Ihnen nur, wie Sie die anderen Ports spezifizieren, nachdem Sie den Haupt-Port erkoren haben. Namensregeln fr Pakete Im Folgenden finden Sie die Regeln fr die Benennung Ihrer Pakete. Diese sollen gewhrleisten, dass das Paketverzeichnis leicht zu durchsuchen ist, da es bereits abertausende Pakete gibt und die Nutzer sich mit Schauder abwenden, wenn Ihre Augen berstrapaziert werden! Der Paketname soll aussehen wie language_region-name-compiled.specifics-version.numbers. Der Paketname ist definiert als ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION} . Stellen Sie bitte sicher, dass die Variablen Ihres Ports diesem Format entsprechen. FreeBSD bemht sich ausserordentlich, die Landessprachen seiner Nutzer zu untersttzen. Die language-Variable soll eine Abkrzung mit 2 Buchstaben sein der Sprachen gem ISO-639, falls der Port fr eine bestimmte Sprache spezifisch ist. Beispiele hierfr sind ja fr Japanisch, ru fr Russisch, vi fr Vietnamesisch, zh fr Chinesisch, ko fr Koreanisch und de fr Deutsch. Sollte der Port spezifisch sein fr eine gewisse Region innerhalb eines Sprachraumes, dann fgen Sie bitte auch den Lndercode mit 2 Buchstaben hinzu. Beispiele sind en_US fr nordamerikanisches Englisch und fr_CH fr schweizerisches Franzsisch. Der language-Teil muss in der PKGNAMEPREFIX-Variable gesetzt werden. Der erste Buchstabe des name-Teils muss kleingeschrieben werden (der Rest des Namens kann Grobuchstaben enthalten. Daher seien Sie bitte umsichtig, wenn Sie den Namen einer Software konvertieren, welche Grossbuchstaben enthlt). Es ist Tradition, Perl 5-Module durch ein vorstehendes p5- und durch Umwandlung des doppelten Doppelpunktes in Bindestriche zu bezeichnen. So wird z.B. aus dem Data::Dumper-Modul der p5-Data-Dumper-Port. Vergewissern Sie sich, dass der Name des Ports und seine Versionsnummer klar getrennt sind und in den Variablen PORTNAME und PORTVERSION stehen. Der einzige Grund, um in PORTNAME einen Versionsteil aufzunehmen ist der, dass die Software wirklich so bezeichnet wird, wie z.B. die Ports 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 Indexeintrge) unterschieden durch die Werte von PKGNAMEPREFIX, PKGNAMESUFFIX und LATEST_LINK. Falls der Port mit verschiedenen, fest kodierten Vorgaben (blicherweise Teil des Verzeichnisnamens in einer Familie von Ports) gebaut werden kann, dann soll der -compiled.specifics-Teil die einkompilierten Vorgaben anzeigen (der Bindestrich ist optional). Beispiele hierfr sind Papiergren und Font-Einheiten. Der -compiled.specifics-Teil muss in der Variablen PKGNAMESUFFIX gesetzt werden. Die Versionszeichenfolge sollte einen Bindestrich (-) am Schluss haben und eine von Punkten getrennte Liste von Integer-Zahlen und kleingeschriebenen Buchstaben sein. Es ist nicht zulssig, einen weiteren Bindestrich innerhalb des Versionsstrings zu verwenden! Die einzige Ausnahme hiervon ist die Zeichenfolge pl (bedeutet patchlevel), welche nur dann gebraucht werden darf, wenn die Applikation ber keine Haupt– oder Unterversionsnummern verfgt. Wenn die Versionsbezeichnung der Software Zeichenketten wie alpha, beta, rc oder pre enthlt, 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 Verffentlichung auf jeden Fall kleiner als yyyy sein wird. Hier sind einige reale Beispiele, die aufzeigen, wie man den Namen einer Applikation zu einem vernnftigen Paketnamen umwandelt: Softwarename PKGNAMEPREFIX PORTNAME PKGNAMESUFFIX PORTVERSION Grund mule-2.2.2 (leer) mule (leer) 2.2.2 Keine nderung erforderlich EmiClock-1.0.2 (leer) emiclock (leer) 1.0.2 keine Grobuchstaben fr einzelne Applikationen rdist-1.3alpha (leer) rdist (leer) 1.3.a Keine Zeichenketten wie alpha erlaubt es-0.9-beta1 (leer) es (leer) 0.9.b1 keine Zeichenketten wie beta erlaubt mailman-2.0rc3 (leer) mailman (leer) 2.0.r3 keine Zeichenketten wie rc erlaubt v3.3beta021.src (leer) tiff (leer) 3.3 Was sollte denn das eigentlich sein? tvtwm (leer) tvtwm (leer) pl11 Versionsstring zwingend erforderlich piewm (leer) piewm (leer) 1.0 Versionsstring zwingend erforderlich xvgr-2.10pl1 (leer) xvgr (leer) 2.10.1 pl nur erlaubt, wenn keine Versionsnummer vorhanden gawk-2.15.6 ja- gawk (leer) 2.15.6 Japanische Sprachversion psutils-1.13 (leer) psutils -letter 1.13 Papergre beim Paketbau fix kodiert pkfonts (leer) pkfonts 300 1.0 Paket fr 300 DPI Schriftarten Falls es in der Originalquelle berhaupt keinen Anhaltspunkt fr irgendeine Versionsbezeichnung gibt und es unwahrscheinlich ist, dass der Autor jemals eine neue Version verffentlichen wird, dann setzen Sie bitte die Version einfach auf 1.0 (wie im obigen Beispiel piewm). Sie knnen auch den Autor fragen oder eine Datumszeichenfolge in der Art 0.0.yyyy.mm.dd als Version verwenden. Kategorisierung <varname>CATEGORIES</varname> 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 groe 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 fr Ihren Port aus. Diese Liste legt auch fest, an welcher Stelle in der Ports-Sammlung der Port eingefgt 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 fr weitere Informationen darber, wie man die richtige Kategorie bestimmt. Aktuelle Liste der Kategorien Hier ist die aktuelle Liste der Kategorien. Die mit einem Asterisk (*) bezeichneten sind virtuelle Kategorien, also solche, welche ber kein eigenes Unterverzeichnis in der Ports-Sammlung verfgen. Sie werden nur als Sekundrkategorien benutzt und sind nur fr Suchzwecke eingerichtet worden. Fr nicht-virtuelle Kategorien finden Sie eine einzeilige Beschreibung in der Variable COMMENT im Makefile des jeweiligen Unterverzeichnisses. Kategorie Beschreibung Anmerkung accessibility Ports fr behinderte Menschen. afterstep* Ports fr den AfterStep Window Manager. arabic Arabische Sprachuntersttzung. archivers Archivierungswerkzeuge. astro Ports fr Astronomie. audio Sound-Untersttzung. benchmarks Benchmarking-Werkzeuge. biology Software fr Biologie. cad CAD-Werkzeuge. chinese Chinesische Sprachuntersttzung. comms Kommunikationsprogramme. Hauptschlich Software fr serielle Schnittstellen. converters Zeichensatz-Konverter. databases Datenbanken. deskutils Dinge, die vor der Erfindung des Computers auf dem Schreibtisch waren. devel Entwicklungs-Werkzeuge. Legen Sie keine Bibliotheken hier ab, nur weil es Bibliotheken sind, es sei denn, sie gehren wirklich nirgendwo anders hin. dns DNS-bezogene Software. docs* Meta-Ports fr die FreeBSD-Dokumentation. editors allgemeine Editoren. Spezielle Editoren gehren in Ihre jeweilige Kategorie, (z.B. gehrt ein mathematischer Formeleditor in math). elisp* Emacs-lisp-Ports. emulators Emulatoren fr andere Betriebssysteme. Terminal-Emulatoren gehren nicht hierher; X-basierende gehren zu x11 und text-basierende zu comms oder misc, abhngig von deren genauer Funktionalitt. finance Finanz-Software und hnliches. french Franzsische Sprachuntersttzung. ftp FTP Client- und Server-Werkzeuge. Falls Ihr Port sowohl FTP als auch HTTP untersttzt, stellen Sie ihn in ftp mit der Zweitkategorie www. games Spiele. geography* geografische Software. german Deutsche Sprachuntersttzung. gnome* Ports fr GNOME gnustep* Software fr GNUstep. graphics grafische Werkzeuge. hamradio* Software fr Amateurfunk. haskell* Software fr die Haskell-Programmiersprache. hebrew Hebrische Sprachuntersttzung. hungarian Ungarische Sprachuntersttzung. ipv6* IPv6-bezogene Software. irc Internet Relay Chat (IRC)-Werkzeuge. japanese Japanische Sprachuntersttzung. java Software fr die Java™-Programmiersprache. Die java-Kategorie sollte nicht die Einzige fr einen Port sein mit Ausnahme der direkt nur mit der Programmiersprache zusammenhngenden Applikationen. Porter sollten java nicht als Hauptkategorie eines Ports whlen. kde* Ports fr das K Desktop Environment (KDE)-Projekt. kld* Kernelmodule. korean Koreanische Sprachuntersttzung. lang Programmiersprachen. linux* Linux-Applikationen und -Werkzeuge. lisp* Software fr die Lisp-Programmiersprache. mail Mail-Software. math Numerische Berechnungen und andere mathematische Werkzeuge. mbone* MBone-Applikationen. misc Verschiedene Werkzeuge. Hauptschlich Werkzeuge, die nicht anderswo hingehren. Versuchen Sie, falls irgend mglich, eine bessere Kategorie fr 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 fr Palm™. parallel* Applikationen fr paralleles Rechnen. pear* Ports fr das Pear PHP-Framework. perl5* Ports, welche Perl Version 5 bentigen. plan9* Verschiedene Programme von Plan9. polish Polnische Sprachuntersttzung. ports-mgmt Hilfsprogramme fr das Installieren und Entwickeln von FreeBSD Ports und Paketen. portuguese Portugiesische Sprachuntersttzung. print Drucker-Software. Desktop Verffentlichungs-Werkzeuge (DTP, Betrachter etc.) gehren auch hierher. python* Software fr Python. ruby* Software fr Ruby. rubygems* Ports fr RubyGems-Pakete. russian Russische Sprachuntersttzung. scheme* Software fr die Scheme-Programmiersprache. science Wissenschaftliche Programme, die in keine andere Kategorie passen wie z.B. astro, biology und math. security Security-Werkzeuge. shells Shells. spanish* Spanische Sprachuntersttzung. sysutils System-Werkzeuge. tcl* Ports, welche Tcl bentigen. textproc Textverarbeitungsprogramme. Dies beinhaltet nicht DTP-Werkzeuge, diese gehren in print. tk* Ports, welche Tk bentigen. ukrainian Ukrainische Sprachuntersttzung. vietnamese Vietnamesische Sprachuntersttzung. windowmaker* Ports fr den WindowMaker Window-Manager. www Software fr das World Wide Web (WWW). HTML-Werkzeuge gehren auch hierher. x11 X-Window-System und dergleichen. Diese Kategorie ist nur fr Software, welche direkt X untersttzt. Fgen Sie keine normalen X-Applikationen hinzu. Die meisten davon gehren in eine andere x11-*-Kategorie (siehe unten). Falls Ihr Port eine X-Applikation ist, dann definieren Sie bitte USE_XLIB (impliziert durch USE_IMAKE) und fgen 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-Untersttzung. Whlen der richtigen Kategorie Da viele der Kategorien sich berlappen, mssen Sie oft festlegen, welches die primre Kategorie Ihres Ports ist. Hierzu gibt es einige Regeln, welche diese Auswahl bestimmen. Hier ist die Liste der Regeln mit abnehmender Wichtigkeit: Die erste (primre) Kategorie muss eine physische (keine virtuelle, siehe oben) sein. Dies ist notwendig damit Pakete erstellt werden knnen. Die nachfolgenden Kategorien knnen 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 aufgefhrt werden und nicht umgekehrt. Genauso sollten Sie keinen Port unter net auffhren, wenn er zu irc, mail, news, security oder www passt, da net in diesen Kategorien bereits implizit eingeschlossen ist. x11 wird nur als sekundre Kategorie benutzt, wenn die primre Kategorie eine sprachspezifische ist. Keinesfalls sollten Sie x11 in die Kategorie-Zeile einer X-Applikation setzen. Emacs modes gehren in die gleiche Kategorie wie die vom jeweiligen mode untersttzte Applikation und nicht in editors. Ein Emacs mode z.B. fr das Editieren von Quelltext einer bestimmten Programmiersprache gehrt zur Kategorie lang. Fr 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 knnen! Falls Ihr Port wirklich in keine andere Kategorie passt, verwenden Sie bitte misc. Falls Sie sich ber die Kategorie im Unklaren sind, hinterlassen Sie bitte einen Kommentar in Ihrem per &man.send-pr.1; eingereichten Bericht, damit wir diese Frage vor dem Import diskutieren knnen. Falls Sie ein Committer sind, schicken Sie bitte eine Nachricht an &a.ports;, damit die Frage im Vorhinein errtert werden kann. Neue Ports werden zu hufig falsch kategorisiert und werden sofort wieder verschoben. Das blht das Master Source Repository unntig auf. Eine neue Kategorie vorschlagen Da die Ports-Sammlung ber viele Jahre gewachsen ist, wurden viele neue Kategorien hinzugefgt. Neue Kategorien knnen virtuell (ohne eigenes Unterverzeichnis in der Ports-Sammlung) oder physisch sein. Der nachfolgende Text fhrt einige Punkte auf, welche bei der Neueinfhrung einer physischen Kategorie beachtet werden mssen, damit Sie dies bei einem eventuellen Vorschlag Ihrerseits bercksichtigen knnen. Unsere bestehende Maxime ist die Vermeidung der Neuanlage von physischen Kategorien, solange nicht eine groe Zahl von Ports zugeordnet werden knnen oder falls ihr nicht Ports zugehren wrden, welche eine logisch abgegrenzte Gruppe von limitiertem ffentlichem Interesse zugehren wrden (zum Beispiel neue Sprachkategorien) oder vorzugsweise beides. Die Erklrung dafr ist, dass eine Neuanlage einer physischen Kategorie einen erheblichen Arbeitsaufwand sowohl fr die Committer als auch diejenigen Nutzer bedeutet, welche die nderungen der Ports-Sammlung nachvollziehen. Zustzlich verursachen Vorschlge fr neue Kategorien oftmals Kontroversen (natrlich deswegen, weil es keinen klaren Konsens darber gibt, welche Kategorie als zu gro betrachtet werden muss noch ob sich bestimmte Kategorien zur einfachen Suche eignen (und wie viele Kategorien berhaupt ideal wren) und so weiter). Hier ist das Prozedere: Schlagen Sie die neue Kategorie auf &a.ports; vor. Sie sollten eine detaillierte Begrndung fr die neue Kategorie beifgen einschlielich einer Erklrung, warum Sie meinen, die existierenden Kategorien seien nicht ausreichend. Zeigen Sie auerdem eine Liste der zu verschiebenden Ports (falls neue Ports in GNATS auf ihren commit warten, die in diese Kategorie passen wrden. Listen Sie diese bitte auch mit auf). Sind Sie der Maintainer oder Einreicher dieser Ports, erwhnen Sie es bitte. Es verleiht Ihrem Vorschlag mehr Gewicht. Nehmen Sie an der Diskussion teil. Falls es Untersttzung fr Ihren Vorschlag geben sollte, reichen Sie bitte einen PR ein, welcher die Begrndung und die Liste der betroffenen Ports enthlt, die verschoben werden mssen. Idealerweise sollte der PR Patches fr Folgendes enthalten: Makefiles fr die neuen Ports nach dem Repocopy Makefile fr die neue Kategorie Makefile fr die alten Kategorien der betroffenen Ports Makefiles fr Ports, welche von den alten Ports abhngen Fr zustzliches Ansehen sorgen Sie, wenn Sie die anderen Dateien, die gendert werden mssen, beifgen wie in der Direktive des Committer's Guide beschrieben. Da es die Ports-Infrastruktur beeinflusst und nicht nur die Durchfhrung von Repocopies und mglicherweise sogar Regressionstests auf dem Build Cluster durchgefhrt werden mssen, sollte der PR dem Ports Management Team &a.portmgr; zugeordnet werden. Sobald der PR besttigt wurde muss ein Committer den Rest der Prozedur durchfhren, welche im Committers Guide beschrieben ist. Das Vorschlagen einer neuen virtuellen Kategorie ist hnlich, aber wesentlich weniger aufwendig, weil keine Ports verschoben werden mssen. In diesem Falle mssen nur die Patches an den PR beigefgt werden, welche die neue Kategorie zur Variable CATEGORIES der betroffenen Ports hinzufgen. Vorschlagen einer Neuorganisation aller Kategorien Von Zeit zu Zeit schlgt jemand eine komplette Neuorganisation aller Ports, entweder mit einer zweistufigen Struktur oder irgendeiner Art von Schlsselwrtern, vor. Bis heute wurde keiner dieser Vorschlge umgesetzt, weil sie zwar einfach zu machen sind, aber der Aufwand zur Umsetzung und Reorganisation der kompletten Ports-Sammlung schlichtweg mrderisch wre. Bitte lesen Sie die Geschichte dieser Vorschlge in den Archiven der Mailinglisten nach, bevor Sie diese Ideen nochmals unterbreiten. Zudem sollten Sie gewappnet sein, dass man Sie auffordert, einen arbeitsfhigen Prototyp vorzulegen. Die Distributionsdateien Der zweite Teil des Makefile beschreibt die Dateien, welche heruntergeladen werden mssen, um den Port zu bauen und wo diese Dateien zu finden sind. <varname>DISTVERSION/DISTNAME</varname> DISTNAME ist der Name der Applikation wie er von den Autoren vergeben wurde. DISTNAME hat als Vorgabe ${PORTNAME}-${PORTVERSION} also berschreiben Sie diese Vorgabe nur, wenn es notwendig ist. DISTNAME wird nur an zwei Stellen genutzt. Erstens: (DISTFILES) hat als Vorgabe ${DISTNAME}${EXTRACT_SUFX}. Zweitens: Die Distributionsdatei soll in einem Unterverzeichnis namens WRKSRC extrahiert werden, dessen Vorgabe work/${DISTNAME} ist. Manche Drittanbieter-Namen, welche nicht in das Schema ${PORTNAME}-${PORTVERSION} passen, knnen durch Setzen von DISTVERSION automatisch behandelt werden. PORTVERSION und DISTNAME werden automatisch abgeleitet, knnen aber natrlich manuell berschrieben werden. Die folgende Tabelle fhrt 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 PKGNAMEPREFIX und PKGNAMESUFFIX beeinflussen DISTNAME nicht. Beachten Sie bitte auch, dass Sie DISTNAME unverndert 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 mglicherweise EXTRACT_SUFX) zu setzen. <varname>MASTER_SITES</varname> Dokumentieren Sie das Verzeichnis der FTP/HTTP-URL, welche auf den originalen Tarball zeigt, in der Variable MASTER_SITES. Bitte vergessen Sie niemals den Schrgstrich (/) am Ende! Die make-Makros werden versuchen, diese Festlegung fr 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 aufzufhren, vorzugsweise auf verschiedenen Kontinenten. Dies ist ein Schutz gegen Probleme bei greren Ausfllen im Internet. Wir planen sogar Untersttzung einzubauen, die automatisch einen Server in der Nhe zum Herunterladen bestimmt. Die Verfgbarkeit von vielen Webseiten wird dieses Vorhaben betrchtlich erleichtern. Falls der originale Tarball Teil eines populren Archivs ist, wie SourceForge, GNU oder Perl CPAN, knnen Sie mglicherweise 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 stndig neue Eintrge hinzugefgt, daher stellen Sie bitte unbedingt sicher, dass Sie die neueste Version verwenden, bevor Sie einen Port einschicken. Fr beliebte Seiten existieren sogenannte magic-Makros, die eine bestimmte Verzeichnisstruktur erstellen. Um eines dieser Makros zu verwenden, geben Sie dessen Abkrzung an und Ihr System wird versuchen, das korrekte Unterverzeichnis automatisch zu bestimmen. MASTER_SITES= SF Ist das Ergebnis nicht korrekt, knnen Sie diesen Wert auch berschreiben. MASTER_SITES= SF/stardict/WyabdcRealPeopleTTS/${PORTVERSION} Beliebte magic <varname>MASTER_SITES</varname>-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}
<varname>EXTRACT_SUFX</varname> Falls Sie eine Distributionsdatei haben, die ein eigentmliches 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, wrden 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. Sie mssen niemals beide Variablen EXTRACT_SUFX und DISTFILES setzen. <varname>DISTFILES</varname> Manchmal haben die zu ladenden Dateien keinerlei hnlichkeit mit dem Namen des Ports. Es knnte z.B. source.tar.gz oder hnlich heien. In anderen Fllen knnte der Quelltext in mehreren Archiven sein und alle mssen heruntergeladen werden. Falls dies der Fall ist, setzen Sie DISTFILES als eine durch Leerzeichen getrennte Liste aller Dateien, die geladen werden mssen. DISTFILES= source1.tar.gz source2.tar.gz Wenn nicht ausdrcklich gesetzt, verwendet DISTFILES als Vorgabe ${DISTNAME}${EXTRACT_SUFX}. <varname>EXTRACT_ONLY</varname> Falls nur einige der DISTFILES extrahiert werden mssen (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= <varname>PATCHFILES</varname> Falls Ihr Port zustzliche Patches bentigt, welche per FTP oder HTTP verfgbar sind, dann setzen Sie PATCHFILES auf den Namen der Dateien und PATCH_SITES auf die URL des Verzeichnisses, das diese Patches enthlt (das Format ist das gleiche wie MASTER_SITES). Falls ein Patch wegen einiger zustzlicher 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 zustzliches foozolix-1.0/ vor ihren Dateinamen aufweisen, dann setzen Sie bitte PATCH_DIST_STRIP=-p1. Kmmern 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 knnen Sie nicht PATCHFILES verwenden. In diesem Fall fgen 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 mglicherweise nicht beschreibbar ist. Der Tarball wird zusammen mit dem anderen Quelltext extrahiert werden. Eine ausdrckliche Dekomprimierung eines mit gzip oder compress erzeugten Tarball ist nicht notwendig. Sollten Sie dies dennoch vorgeben, so beachten Sie bitte peinlich genau, dass Sie nichts berschreiben, was bereits im Verzeichnis vorhanden ist. Vergessen Sie auch nicht den kopierten Patch im Target von pre-clean zu entfernen. Verschiedene Distributionsdateien oder Patches von verschiedenen Seiten und Verzeichnissen (<literal>MASTER_SITES:n</literal>) (Betrachten Sie es als in irgendeiner Form fortgeschrittenes Thema. Neulinge sollten mglicherweise diesen Abschnitt beim ersten Lesen berspringen). Dieser Abschnitt stellt Informationen ber die Mechanismen zum Herunterladen von Dateien zur Verfgung 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 verfgt ber eine sehr elegante Option innerhalb der Variablen DISTFILES und PATCHFILES. Sowohl Dateien als auch Patches knnen mit angehngten :n-Bezeichnern versehen werden wobei n in beiden Fllen [0-9] sein kann und eine Gruppenzugehrigkeit anzeigt. Ein Beispiel hierfr ist: DISTFILES= alpha:0 beta:1 In OpenBSD wird die Datei alpha mit der Variable MASTER_SITES0 verknpft anstatt dem in FreeBSD gebruchlichen MASTER_SITES und beta mit MASTER_SITES1. Das ist eine sehr interessante Mglichkeit, die endlose Suche nach der richtigen Download-Seite zu verkrzen. 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. Wre es nicht reine Verschwendung, wenn der Maintainer alle Seiten zuvor berprfen msste? Kein guter Start fr das wundervolle Wochenende! bertragen Sie diesen Umstand auf noch mehr DISTFILES und mehr MASTER_SITES. Ganz sicher wrde unser distfiles survey master die Erleichterung sehr zu schtzen wissen, die eine solche Verringerung der Netzwerkbelastung bringen wrde. In den nchsten Abschnitten sehen Sie die Implementierung dieser Idee durch FreeBSD. Dabei wurde das Konzept von OpenBSD ein wenig verbessert. Prinzipielle Information Dieser Abschnitt informiert Sie, wie Sie schnell ein fein granuliertes Herunterladen von vielen Dateien und Fehlerbereinigungen von verschiedenen Webseiten und Unterverzeichnissen bewerkstelligen. Wir beschreiben hier den Fall der vereinfachten Nutzung von MASTER_SITES:n. Das ist fr die meisten Szenarien ausreichend. Falls Sie weitere Informationen bentigen, sollten Sie den nchsten Abschnitt lesen. Einige Programme bestehen aus mehreren Dateien, welche von verschiedenen Webseiten heruntergeladen werden mssen. Zum Beispiel besteht Ghostscript aus dem Kern des Programms und einer groen Zahl von Treiberdateien, die vom Drucker des Benutzers abhngen. Einige dieser Treiberdateien werden mit der Kernapplikation mitgeliefert aber viele mssen von verschiedenen Webseiten heruntergeladen werden. Um das zu untersttzen, muss jeder Eintrag in DISTFILES mit einem Komma und einem tag name abgeschlossen werden. Jeder in MASTER_SITES aufgefhrte 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 mssen. Das Makefile des Port wrde Zeilen enthalten wie in . Vereinfachtes Beispiel fr den Gebrauch von <literal>MASTER_SITES:n</literal> 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 knnen 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 wrde dann aussehen wie . Vereinfachtes Beispiel fr den Gebrauch von <literal>MASTER_SITES:n</literal> 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 Ausfhrliche Information In Ordnung, das vorherige Beispiel reicht nicht fr Ihre Bedrfnisse? In diesem Abschnitt werden wir im Detail erklren, wie der fein granulierte Mechanismus zum Herunterladen (MASTER_SITES:n) funktioniert und wie Sie Ihre Ports modifizieren, um ihn zu nutzen. Elemente knnen nachstehend bezeichnet werden mit :n wobei n in diesem Falle [^:,]+ ist. Das heit n knnte theoretisch jede alphanumerische Zeichenkette sein, aber wir beschrnken sie auf [a-zA-Z_][0-9a-zA-Z_]+ fr diesen Moment. Zudem ist die Zeichenkette case sensitive; d.h. n unterscheidet sich von N. Allerdings drfen die folgenden Wrter nicht gebraucht werden, da sie spezielle Bedeutungen haben: default, all und ALL (diese Wrter werden intern genutzt in Punkt ). Ausserdem ist DEFAULT ein reserviertes Wort (beachten Sie ). Elemente mit angehngtem :n gehren zur Gruppe n, :m gehrt zur Gruppe m und so weiter. Elemente ohne Anhngsel sind gruppenlos, d.h. sie gehren alle zu der speziellen Gruppe DEFAULT. Falls sie an irgendeinem Element DEFAULT hngen, ist dies berflssig, es sei denn Sie wollen, dass ein Element sowohl zu DEFAULT als auch anderen Gruppen gleichzeitig gehrt (beachten Sie ). Die folgenden Beispiele sind gleichwertig, aber das erste Beispiel ist vorzuziehen: MASTER_SITES= alpha MASTER_SITES= alpha:DEFAULT Gruppen sind nicht ausschliessend, d.h. ein Element kann mehreren Gruppen gleichzeitig angehren und eine Gruppe wiederum kann entweder mehrere Elemente oder berhaupt keine aufweisen. Wiederholte Elemente sind schlicht nur wiederholte Elemente. Wenn Sie wollen, dass ein Element gleichzeitig zu mehreren Gruppen gehrt, dann knnen Sie diese durch ein Komma (,) trennen. Anstatt jedes Mal ein anderes Anhngsel zu verwenden und Wiederholungen aufzufhren, knnen Sie mehrere Gruppen auf einmal in einem einzigen Anhngsel bestimmen. Zum Beispiel markiert :m,n,o ein Element, welches zu den Gruppen m, n und o gehrt. 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 Alle Webseiten in einer Gruppe werden gem MASTER_SORT_AWK sortiert. Alle Gruppen innerhalb von MASTER_SITES und PATCH_SITES werden genauso sortiert. Gruppensemantik kann benutzt werden in den folgenden Variablen: MASTER_SITES, PATCH_SITES, MASTER_SITE_SUBDIR, PATCH_SITE_SUBDIR, DISTFILES und PATCHFILES entsprechend der folgenden Syntax: Elemente mit MASTER_SITES, PATCH_SITES, MASTER_SITE_SUBDIR und PATCH_SITE_SUBDIR mssen mit einem Schrgstrich beendet werden ( /). Falls Elemente zu irgendwelchen Gruppen gehren, muss :n direkt nach dem Trenner / stehen. Der MASTER_SITES:n-Mechanismus verlsst sich auf das Vorhandensein des Trennzeichens /, um verwirrende Elemente zu vermeiden in denen :n ein zulssiger Bestandteil des Elementes ist und das Auftreten von :n die Gruppe n anzeigt. Aus Kompatibilittsgrnden (da der /-Trenner sowohl in MASTER_SITE_SUBDIR als auch PATCH_SITE_SUBDIR-Elementen nicht erforderlich ist) wird, falls das auf das Anhngsel folgende nchste Zeichen kein / ist, auch :n als gltiger Teil des Elementes behandelt anstatt als Gruppenzusatz, selbst wenn ein Element ein angehngtes :n aufweist. Beachten Sie sowohl als auch . Ausfhrliches Beispiel von <literal>MASTER_SITES:n</literal> in <varname>MASTER_SITE_SUBDIR</varname> MASTER_SITE_SUBDIR= old:n new/:NEW Verzeichnisse innerhalb der Gruppe DEFAULT -> old:n Verzeichnisse innerhalb der Gruppe NEW -> new Ausfhrliches Beispiel von <literal>MASTER_SITES:n</literal> 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 fhrt 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 gehren 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 Wie gruppiere ich eine der speziellen Variablen aus bsd.sites.mk, d.h. MASTER_SITE_SOURCEFORGE? Lesen Sie . Ausfhrliches Beispiel von <literal>MASTER_SITES:n</literal> mit <varname>MASTER_SITE_SOURCEFORGE</varname> 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. 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 . sehen knnen. Vereinfachte Nutzung von <literal>MASTER_SITES:n</literal> mit <varname>PATCH_SITES</varname>. PATCH_SITES= http://site1/ http://site2/:test PATCHFILES= patch1:test Was ndert sich fr die Ports? Was ndert sich nicht? Alle bestehenden Ports bleiben gleich. Der Code fr MASTER_SITES:n wird nur aktiviert, falls es Elemente mit angehngtem :n entsprechend den zuvor erwhnten Syntax-Regeln wie in gezeigt gibt. 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 . fetch-list: arbeitet wie das alte fetch-list mit der Ausnahme, dass es nur wie do-fetch gruppiert. master-sites und patch-sites: (inkompatibel zu lteren Versionen) geben nur die Elemente der Gruppe DEFAULT zurck. Beziehungsweise sie fhren 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 berprfung von MASTER_SITES oder PATCH_SITES vorzuziehen. Zudem ist nicht garantiert, dass das direkte berprfen in zuknftigen Versionen funktionieren wird. Sehen Sie fr weitere Informationen zu diesen neuen Port-Targets. Neue Port-Targets Es gibt master-sites-n und patch-sites-n-Targets, welche die Elemente der jeweiligen Gruppe n innerhalb von MASTER_SITES und PATCH_SITES auflisten. Beispielweise werden sowohl master-sites-DEFAULT als auch patch-sites-DEFAULT die Elemente der Gruppe DEFAULT, master-sites-test und patch-sites-test der Gruppe test usw. zurckgeben. Es gibt das neue Target master-sites-all und patch-sites-all, welche die Arbeit der alten Targets master-sites und patch-sites bernehmen. Sie geben die Elemente aller Gruppen zurck,als wrden sie zur gleichen Gruppe gehren - 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 fr master-sites-all und patch-sites-all. <varname>DIST_SUBDIR</varname> 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 enthlt, die einen Namen hat, der mglicherweise mit anderen Ports in Konflikt stehen knnte (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 ndern und stellt tatschlich alle fr Ihren Port bentigten Dateien in dieses Unterverzeichnis. Es wird zustzlich nach dem Unterverzeichnis mit dem gleichen Namen auf der Sicherung der Hauptseite auf ftp.FreeBSD.org suchen (das ausdrckliche Setzen von DISTDIR in Ihrem Makefile wird dies nicht gewhrleisten, also nutzen Sie bitte DIST_SUBDIR). Dies hat keine Auswirkungen auf die Variable MASTER_SITES, die Sie in Ihrem Makefile definieren. <varname>ALWAYS_KEEP_DISTFILES</varname> Falls Ihr Port binre Distfiles benutzt und eine Lizenz aufweist, die verlangt, dass das der Quelltext in Form binrer Pakete verteilt werden muss, z.B. GPL, dann wird ALWAYS_KEEP_DISTFILES den &os; Build Cluster anweisen eine Kopie der Dateien in DISTFILES vorzuhalten. Nutzer dieser Ports bentigen generell diese Dateien nicht, daher ist es ein gutes Konzept, nur dann die Distfiles zu DISTFILES hinzuzufgen, wenn PACKAGE_BUILDING definiert ist. Nutzung von <varname>ALWAYS_KEEP_DISTFILES</varname>. .if defined(PACKAGE_BUILDING) DISTFILES+= foo.tar.gz ALWAYS_KEEP_DISTFILES= yes .endif Wenn Sie zustzliche Dateien zu DISTFILES hinzufgen, dann beachten Sie bitte, dass Sie diese auch in distinfo auffhren. Zudem werden die zustzlichen Dateien normalerweise ebenso in WRKDIR extrahiert, was fr einige Ports zu unbeabsichtigten Seiteneffekten fhren mag und spezielle Behandlung erfordert. <varname>MAINTAINER</varname> Fgen Sie hier Ihre E-Mailadresse ein. Bitte. :-) Beachten Sie bitte, dass nur eine einzelne E-Mailadresse ohne Kommentar in der Variable MAINTAINER zulssig ist. Das Format sollte user@hostname.domain sein. Bitte fgen Sie keinen beschreibenden Text wie z.B. Ihren wirklichen Namen ein, dies verwirrt lediglich bsd.port.mk. Der Maintainer ist dafr verantwortlich, dass der Port aktuell gehalten wird und er sorgt dafr, dass der Port korrekt arbeitet. Fr eine detaillierte Beschreibung der Verantwortlichkeiten eines Maintainers beachten Sie bitte den Abschnitt Die Herausforderung fr einen Port-Maintainer. nderungen am Port werden dem Maintainer zur Begutachtung und Zustimmung vorgelegt, bevor sie committed werden. Falls der Maintainer einem Aktualisierungs-Wunsch nicht binnen 2 Wochen (ausgenommen wichtige ffentliche Feiertage) zustimmt, dann wird dies als Maintainer-Timeout betrachtet und eine Aktualisierung kann ohne ausdrckliche 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 &a.portmgr; oder das &a.security-officer; betreut wird. Es drfen niemals committs ohne vorherige Zustimmung an solchen Ports vorgenommen werden! Wir behalten uns das Recht vor, die Einreichungen eines Maintainers ohne ausdrckliche Zustimmung zu ndern, falls wir der Auffassung sind, dass dadurch die Einhaltung von Richtlinien und stilistischen Vorgaben fr die Ports-Sammlung besser erfllt wird. Zudem knnen grere nderungen an der Infrastruktur der Ports zu nderungen an einem bestimmten Port ohne Zustimmung des Maintainers fhren. Diese nderungen beeinflussen niemals die Funktionalitt eines Ports. Das &a.portmgr; behlt sich das Recht vor, die Maintainerschaft jedem aus irgendeinem Grund zu entziehen oder ausser Kraft zu setzen, und das Security Officer Team &a.security-officer; behlt sich das Recht vor, jede Maintainerschaft aus Sicherheitsgrnden aufzuheben oder ausser Kraft zu setzen. <varname>COMMENT</varname> Dies ist eine einzeilige Beschreibung des Ports. Bitte fgen Sie nicht den Paketnamen (oder die Version der Software) in den Kommentar ein. Der Kommentar soll mit einem Grobuchstaben 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 &man.pkg.info.1; diese zur Anzeige einer kurzen, einzeiligen Zusammenfassung des Ports verwendet. Abhngigkeiten (dependencies) Viele Ports hngen von anderen Ports ab. Dies ist ein sehr praktisches und nettes Feature der meisten Unix-hnlichen Betriebssysteme, &os; nicht ausgeschlossen. Es erlaubt, dass hufig vorkommende Abhngigkeiten nicht mit jedem Port oder Paket zusammen ausgeliefert werden mssen, da viele Ports diese gemeinsam benutzen. Es gibt sieben Variablen, die benutzt werden knnen, um sicherzustellen, dass alle bentigten Teile auf dem Rechner des Nutzers sind. Zustzlich gibt es einige vordefinierte Variablen fr Abhngigkeiten in hufigen Fllen und einige, welche das Verhalten der Abhngigkeiten bestimmen. <varname>LIB_DEPENDS</varname> Diese Variable spezifiziert die Shared-Libraries, von denen der Port abhngt. 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 verfgbar, 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 prfen, 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 hierfr ist install). Der lib-Teil ist ein regulrer Ausdruck, welcher die Ausgabe von ldconfig -r ausgewertet. Werte wie intl.[5-7] und intl sind zulssig. Das erste Muster, intl.[5-7], stimmt berein mit: intl.5, intl.6 oder intl.7. Das zweite Muster, intl, stimmt berein mit jeder Version der intl-Bibliothek. Die Abhngigkeit wird zwei Mal berprft, einmal innerhalb des extract-Target und dann innerhalb des install-Target. Zudem wird der Name der Abhngigkeit in das Paket eingefgt, damit &man.pkg.add.1; es automatisch installiert, falls es nicht auf dem Rechner des Nutzers ist. <varname>RUN_DEPENDS</varname> Diese Variable legt Binrdateien oder Dateien, von denen der Port abhngt, fr die Laufzeit fest. Es ist eine Liste von path:dir:target-Tupeln, wobei path der Name der Binrdatei 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; berprft. Andernfalls wird angenommen, dass es eine Binrdatei ist und which -s wird benutzt, um zu berprfen, ob das Programm im Pfad vorhanden ist. Zum Beispiel wird RUN_DEPENDS= ${LOCALBASE}/etc/innd:${PORTSDIR}/news/inn \ xmlcatmgr:${PORTSDIR}/textproc/xmlcatmgr berprfen, 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 berprft, ob die Binrdatei 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. In diesem Fall ist innd eine Binrdatei. Falls sich eine Binrdatei an einem ungewhnlichen Platz befindet, der nicht im Suchpfad ist, dann sollten Sie die volle Pfadangabe verwenden. 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 Abhngigkeit wird innerhalb des install-Target berprft. Zudem wird der Name der Abhngigkeit in das Paket bernommen, damit &man.pkg.add.1; es automatisch installieren wird, falls es auf dem System des Nutzers nicht vorhanden ist. Der target-Teil kann weggelassen werden, wenn er der gleiche ist wie in der Variable DEPENDS_TARGET. Es kommt recht hufig vor, dass RUN_DEPENDS genau dasselbe enthlt 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 fhren, dass die Liste der Laufzeitabhngigkeiten mit berflssigen Eintrgen belastet wird, die sich nicht in der ursprnglichen Liste BUILD_DEPENDS des Ports befanden, da sich &man.make.1; bei der Auswertung solcher Zuweisungen trge verhlt. Stellen Sie sich ein Makefile mit USE_*-Variablen vor, die von ports/Mk/bsd.*.mk verarbeitet werden, um initiale Bauabhngigkeiten zusammenzutragen. Zum Beispiel fgt USE_GMAKE=yes devel/gmake zu BUILD_DEPENDS hinzu. Um zu verhindern, dass solche zustzlichen Abhngigkeiten 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} <varname>BUILD_DEPENDS</varname> Diese Variable legt Binrdateien oder Dateien fest, die dieser Port zur Erstellung bentigt. Wie RUN_DEPENDS ist es eine Liste von path:dir:target-Tupeln. Zum Beispiel wird BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip berprfen, ob eine Binrdatei unzip vorhanden ist und in das Unterverzeichnis archivers/unzip Ihrer Ports-Sammlung wechseln und sie erstellen und installieren, falls sie nicht gefunden wird. Erstellen bedeutet hier alles von der Extraktion bis zur Kompilierung. Die Abhngigkeit wird im extract-Target berprft. Der target-Teil kann weggelassen werden, falls er identisch mit der Variable DEPENDS_TARGET ist. <varname>FETCH_DEPENDS</varname> Diese Variable legt eine Binrdatei oder Datei fest, welche der Port bentigt, um heruntergeladen werden zu knnen. Wie die vorherigen beiden Variablen ist er eine Liste von path:dir:target-Tupeln. Zum Beispiel wird FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2 berprfen, ob eine Binrdatei namens ncftp2 vorhanden ist, in das Unterverzeichnis net/ncftp2 Ihrer Ports-Sammlung wechseln, sie erstellen und installieren, falls sie nicht gefunden wird. Die Abhngigkeit wird innerhalb des fetch-Target berprft. Der target-Teil kann weggelassen werden, falls er identisch mit der Variable DEPENDS_TARGET ist. <varname>EXTRACT_DEPENDS</varname> Diese Variable spezifiziert eine Binrdatei oder eine Datei, welche dieser Port fr die Extraktion bentigt. Wie die vorherigen Variablen ist er eine Liste von path:dir:target-Tupeln. Zum Beispiel wird EXTRACT_DEPENDS= unzip:${PORTSDIR}/archivers/unzip berprfen, ob eine Binrdatei namens unzip vorhanden ist, in das Unterverzeichnis archivers/unzip Ihrer Ports-Sammlung wechseln, sie erstellen und installieren, falls sie nicht gefunden wird. Die Abhngigkeit wird innerhalb des extract-Target berprft. Der target-Teil kann weggelassen werden, falls er identisch mit der Variable DEPENDS_TARGET ist. 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 beschrieben zum Laufen gebracht werden kann. <varname>PATCH_DEPENDS</varname> Diese Variable legt eine Binrdatei oder eine Datei fest, welche dieser Port zum Patchen bentigt. 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 Abhngigkeit wird innerhalb des patch-Target berprft. Der target-Teil kann entfallen, falls er identisch mit der Variable DEPENDS_TARGET ist. <varname>USE_<replaceable>*</replaceable></varname> Es gibt eine Reihe von Variablen, um gebruchliche Abhngigkeiten einzukapseln, die viele Ports aufweisen. Obwohl Ihre Verwendung optional ist, knnen sie helfen die bersichtlichkeit des Makefile eines Ports zu erhhen. Jede von ihnen ist im Stil von USE_*. Der Gebrauch dieser Variablen ist beschrnkt 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_* fr diese Zwecke. Es ist immer falsch, irgendeine USE_*-Variable in der /etc/make.conf zu setzen. Zum Beispiel wrde das Setzen von USE_GCC=3.4 eine Abhngigkeit fr GCC34 fr jeden Port einschliesslich GCC34 selbst hinzufgen! Die <varname>USE_<replaceable>*</replaceable></varname>-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 fr die Erstellung. USE_CDRTOOLS Der Port erfordert cdrecord entweder von sysutils/cdrtools oder sysutils/cdrtools-cjk, abhngig davon, was der Nutzer vorgibt. USE_GCC Dieser Port bentigt eine bestimmte Version von gcc zur Erstellung. Die genaue Version kann festgelegt werden mit Werten wie 3.4. Mit 3.4+ kann die mindestens erforderliche Version spezifiziert werden. Der gcc aus dem Basissystem wird genutzt, wenn er die erforderliche Version erfllt, andernfalls wird eine geeignete Version des gcc aus den Ports kompiliert und die Variablen CC und CXX werden angepasst.
Variablen zugehrig zu gmake und dem configure-Skript werden in beschrieben, whrenddessen autoconf, automake und libtool in beschrieben sind. Perl-spezifische Variablen werden in behandelt. X11-Variablen sind aufgelistet in . behandelt GNOME-bezogene Variablen und KDE-bezogene Variablen. dokumentiert Java-Variablen, whrend Informationen zu Apache, PHP und PEAR-Modulen enthlt. Python wird in und Ruby in errtert. stellt Variablen fr SDL-Programme zur Verfgung und enthlt schliesslich Variablen fr Xfce. Minimale Version einer Abhngigkeit Eine minimale Version einer Abhngigkeit 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 enthlt einen abhngigen Paketnamen, welcher einem Eintrag in der Paketdatenbank entsprechen muss und einen Vergleich mit einer Paketversion. Die Abhngigkeit wird erfllt, wenn p5-Spiffy-0.26 oder eine neuere Version auf dem System installiert ist. Anmerkungen zu Abhngigkeiten Wie vorstehend beschrieben ist das Vorgabe-Target DEPENDS_TARGET, wenn eine Abhngigkeit bentigt wird. Die Vorgabe hierfr ist install. Dies ist eine Nutzer-Variable; sie wird niemals im Makefile eines Ports definiert. Falls Ihr Port einen besonderen Weg bentigt, um mit einer Abhngigkeit umzugehen, dann benutzen Sie bitte den :target-Teil der *_DEPENDS-Variablen, anstatt DEPENDS_TARGET zu ndern. Falls Sie make clean schreiben, werden dessen Abhngigkeiten auch gesubert. 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 Abhngigkeiten hat, das sehr viel Zeit fr einen rebuild bentigt wie KDE, GNOME oder Mozilla. Um von einem anderen Port bedingungslos abhngig 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 bentigen. Sie knnen 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. Zirkulre Abhngigkeiten sind fatal Fhren Sie niemals irgendwelche zirkulren Abhngigkeiten in der Ports-Sammlung ein! Die Struktur fr die Erstellung von Ports dulde keinerlei zirkulre Abhngigkeiten. Falls Sie dennoch eine verwenden, wird es irgendjemanden irgendwo auf der Welt geben, dessen FreeBSD-Installation nahezu sofort zusammenbricht und vielen anderen wird es sehr schnell genauso ergehen. So etwas kann extrem schwer festzustellen sein. Falls Sie Zweifel haben vor einer nderung, dann vergewissern Sie sich, dass Sie folgendes getan haben: cd /usr/ports; make index. Dieser Prozess kann auf alten Maschinen sehr langsam sein, aber Sie ersparen sich und einer Vielzahl von Menschen mglicherweise eine Menge rger. <varname>MASTERDIR</varname> Falls Ihr Port wegen einer Variable, die verschiedene Werte annimmt (z.B. Auflsung oder Papiergre), leicht unterschiedliche Versione von Paketen erzeugen muss, dann legen Sie bitte ein Unterverzeichnis pro Paket an, um es fr den Nutzer einfacher begreiflich zu machen, was zu machen ist. Aber versuchen Sie dabei so viele Dateien wie mglich zwischen diesen Ports gemeinsam zu nutzen. Normalerweise bentigen Sie nur ein sehr kurzes Makefile in allen ausser einem Unterverzeichnis, wenn Sie Variablen intelligent nutzen. In diesem einzigen Makefile knnen Sie MASTERDIR verwenden, um anzugeben, wo der Rest der Dateien liegt. Benutzen Sie bitte auch eine Variable fr 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 verfgt ebenfalls ber alle Patches, Paket-Dateien usw. Wenn Sie make eintippen, wird der Port die Standardvorgabe fr die Auflsung nehmen (300) und den Port ganz normal erstellen. Genauso wie fr alle anderen Auflsungen ist dies das vollstndige xdvi118/Makefile: RESOLUTION= 118 MASTERDIR= ${.CURDIR}/../xdvi300 .include "${MASTERDIR}/Makefile" (xdvi240/Makefile und xdvi400/Makefile sind hnlich). Die MASTERDIR-Definition teilt dem bsd.port.mk mit, dass die normalen Unterverzeichnisse wie FILESDIR und SCRIPTDIR unter xdvi300 gefunden werden knnen. Die RESOLUTION=118-Zeile wird die RESOLUTION=300-Zeile in xdvi300/Makefile berschreiben und der Port wird mit einer Auflsung von 118 erstellt. Manualpages Die Variablen MAN[1-9LN] werden automatisch jede Manualpage zur pkg-plist hinzufgen (dies bedeutet, dass Sie Manualpages nicht in der pkg-plist auflisten drfen, lesen Sie bitte Erstellung der PLIST fr weitere Details). Sie veranlassen zudem den Installationsabschnitt dazu, die Manualpages zu Komprimieren oder zu Dekomprimieren abhngig vom gesetzten Wert der Variable NO_MANCOMPRESS in /etc/make.conf. Falls Ihr Port versucht verschiedene Namen fr Manualpages unter Zuhilfenahme von Symlinks oder Hardlinks zu installieren, mssen Sie die Variable MLINKS nutzen, um diese zu identifizieren. Der von Ihrem Port installierte Link wird von bsd.port.mk gelscht und wieder eingefgt, um sicherzustellen, dass er auf die korrekte Datei zeigt. Jede Manualpage, welche in MLINKS aufgefhrt ist, darf nicht in der pkg-plist aufgenommen werden. Falls die Manualpages whrend der Installation komprimiert werden sollen, mssen 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 auszufhren 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 mssen es nicht explizit angeben, auer die Standardvorgabe ist fr Ihren Port nicht passend. Wenn Ihr Port den man tree irgendwo anders als in der Variable PREFIX verankert, knnen 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 knnen 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 zustzlich von Ihrem Port installiert werden, oder auch nicht. Unabhngig davon wird ein Symlink erstellt, welcher die Manualpages foo(1) und alt-name(8) einbindet. Falls nur manche Manualpages bersetzt sind, knnen Sie einige dynamisch vom MANLANG-Inhalt erzeugte Variablen nutzen: MANLANG= "" de ja MAN1= foo.1 MAN1_EN= bar.1 MAN3_DE= baz.3 Dies fhrt 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 Info-Dateien Falls Ihr Paket GNU-Info-Dateien installiert, sollten diese in der INFO-Variablen augelistet sein (ohne das angehngte .info) mit einem Eintrag fr jedes Dokument. Von diesen Dateien wird angenommen, dass sie nach PREFIX/INFO_PATH installiert werden. Sie knnen INFO_PATH ndern, falls Ihr Paket einen anderen Ort vorsieht. Jedoch wird dies nicht empfohlen. Die Eintrge 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 vorlufigen pkg-plist hinzugefgt. Makefile-Optionen Einige grere Applikationen knnen mit einer Reihe von Konfigurationen, die zustzliche Funktionalitten hinzufgen, erstellt werden, falls eine oder mehrere Bibliotheken oder Applikationen verfgbar sind. Dazu gehren die Auswahl von natrlichen 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 Verfgung, damit der Autor des Ports bestimmen kann, welche Konfiguration erstellt werden soll. KNOBS (Einstellungen) <varname>WITH_<replaceable>*</replaceable></varname> und <varname>WITHOUT_<replaceable>*</replaceable></varname> 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. Sie sollten nicht annehmen, dass ein WITH_* notwendigerweise eine korrespondierende WITHOUT_*-Variable hat oder umgekehrt. Im Allgemeinen wird diese Vorgabe einfach unterstellt. Falls nicht anderweitig festgelegt, werden diese Variablen nur dahingehend berprft, ob sie gesetzt sind oder nicht – nicht darauf, ob sie auf bestimmte Werte wie YES oder NO gesetzt sind. Hufige <varname>WITH_<replaceable>*</replaceable></varname> und <varname> WITHOUT_<replaceable>*</replaceable></varname>-Variablen Variable Bedeutung WITHOUT_NLS Falls gesetzt, bedeutet sie, dass eine Internationalisierung nicht bentigt wird, was Kompilierzeit sparen kann. Als Vorgabe wird Internationalisierung gebraucht. WITH_OPENSSL_BASE Nutze die Version von OpenSSL aus dem Basissystem. WITH_OPENSSL_PORT Installiert die Version von OpenSSL aus security/openssl, auch wenn das Basissystem auf aktuellem Stand ist. WITHOUT_X11 Falls der Port mit oder ohne Untersttzung fr X erstellt werden kann, dann sollte normalerweise mit X-Untersttzung erstellt werden. Falls die Variable gesetzt ist, soll die Version ohne X-Untersttzung erstellt werden.
Benennung von Knobs (Einstellungen) Um die Anzahl der Knobs niedrig zu halten und zum Vorteil des Anwenders, wird empfohlen, dass Porter hnliche Namen fr 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-Prfix im PORTNAME hat, dann soll das lib-Prfix im Knob-Namen entfallen. <varname>OPTIONS</varname> Hintergrund Die OPTIONS-Variable gibt dem Nutzer, der diesen Port installiert, einen Dialog mit auswhlbaren Optionen und speichert diese in /var/db/ports/portname/options. Bei der nchsten Neuerstellung des Ports werden diese Einstellungen wieder verwandt. Sie werden sich niemals mehr an all die zwanzig WITH_* und WITHOUT_*-Optionen erinnern mssen, die Sie benutzt haben, um diesen Port zu erstellen! Wenn der Anwender make config benutzt (oder ein make build das erste Mal laufen lsst) wird das Framework auf /var/db/ports/portname/options die Einstellungen prfen. Falls die Datei nicht existiert, werden die Werte von OPTIONS genutzt, um eine Dialogbox zu erzeugen, in welcher die Optionen an- oder abgeschaltet werden knnen. Dann wird die options-Datei gespeichert und die ausgewhlten Variablen werden bei der Erstellung des Ports benutzt. Falls eine neue Version des Ports OPTIONS hinzufgt, 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 Lschen. Syntax Die Syntax fr 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 mssen vor der Einbindung von bsd.port.options.mk erscheinen. Die WITH_* und WITHOUT_*-Variablen knnen 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 Einfhrung 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. Einfache Anwendung von <varname>OPTIONS</varname> 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> Veraltete Anwendung von <varname>OPTIONS</varname> OPTIONS= FOO "Enable option foo" On .include <bsd.port.pre.mk> .if defined(WITHOUT_FOO) CONFIGURE_ARGS+= --without-foo .else CONFIGURE_ARGS+= --with-foo .endif .include <bsd.port.post.mk> Automatische Aktivierung von Funktionen Wenn Sie ein GNU-Konfigurationsskript benutzen, sollten Sie ein Auge darauf werfen, welche Funktionen durch die automatische Erkennung aktiviert werden. Schalten Sie Funktionen, die Sie nicht mchten, ausdrcklich durch Verwendung von --without-xxx oder --disable-xxx in der Variable CONFIGURE_ARGS einzeln ab. 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 fgt ihre Funktionen in die Binrdatei ein. Falls der Nutzer sich nun entschliesst libfoo von seinem System zu entfernen, dann wird das Ports-System nicht protestieren (es wurde keine Abhngigkeit von libfoo eingetragen), aber die Applikation bricht ab. 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. 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 berschreiben knnen, falls dies nicht der Fall sein sollte. <varname>WRKSRC</varname> 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, wrden Sie schreiben: WRKSRC= ${WRKDIR}/foo oder mglicherweise WRKSRC= ${WRKDIR}/${PORTNAME} <varname>NO_WRKSUBDIR</varname> Wenn der Port berhaupt nicht in einem Unterverzeichnis extrahiert wird, sollten Sie dies mit dem Setzen von NO_WRKSUBDIR anzeigen. NO_WRKSUBDIR= yes Konfliktbehandlung Es gibt drei verschiedene Variablen, um einen Konflikt zwischen Paketen und Ports zu dokumentieren: CONFLICTS, CONFLICTS_INSTALL sowie CONFLICTS_BUILD. CONFLICTS setzt automatisch die Variable IGNORE, die ausfhrlicher in beschrieben wird. Beim Entfernen eines von mehreren in Konflikt stehenden Ports ist es ratsam, die CONFLICTS-Eintrge in den anderen Ports fr einige Monate beizubehalten, um Nutzer zu untersttzen, die ihre Ports nur sporadisch aktualisieren. <varname>CONFLICTS_INSTALL</varname> Falls Ihr Paket nicht mit anderen Paketen koexistieren kann (wegen Dateikonflikten, Laufzeit-Inkompatibilitten usw.), fhren Sie bitte die anderen Paketnamen in der Variable CONFLICTS_INSTALL auf. Sie knnen hier Shell-Globs wie * und ? verwenden. Paketnamen sollten in der gleichen Weise aufgezhlt werden, wie sie in /var/db/pkg auftauchen. Bitte stellen Sie sicher, dass CONFLICTS nicht mit dem Paket des Ports selbst bereinstimmt, da ansonsten das Erzwingen der Installation durch FORCE_PKG_REGISTER nicht lnger funktionieren wird. <varname>CONFLICTS_BUILD</varname> Wenn Ihr Port nicht gebaut werden kann, wenn ein bestimmter Port bereits installiert ist, geben Sie diesen in der Variable CONFLICTS_BUILD an. Sie knnen hier Shell-Globs wie * und ? verwenden. Paketnamen sollten in der gleichen Weise aufgezhlt werden, wie sie in /var/db/pkg auftauchen. Die CONFLICTS_BUILD-Prfung erfolgt vor dem Bau des Ports. Baukonflikte werden im erzeugten Paket nicht verzeichnet. <varname>CONFLICTS</varname> 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 knnen hier Shell-Globs wie * und ? verwenden. Paketnamen sollten in der gleichen Weise aufgezhlt werden, wie sie in /var/db/pkg auftauchen. Bitte stellen Sie sicher, dass CONFLICTS_INSTALL nicht mit dem Paket des Ports selbst bereinstimmt, da ansonsten das Erzwingen der Installation durch FORCE_PKG_REGISTER nicht lnger funktionieren wird. Die CONFLICTS-Prfung erfolgt vor dem Bau des Ports und vor der Installation des gebauten Ports. Installation von Dateien INSTALL_* macros Nutzen Sie die Makros in bsd.port.mk, um korrekte Modi und Eigentmer von Dateien in Ihren *-install-Targets sicherzustellen. INSTALL_PROGRAM ist ein Befehl, um binre Binrdateien zu installieren. INSTALL_SCRIPT ist ein Befehl, um ausfhrbare Skripte zu installieren. INSTALL_LIB ist ein Befehl zur Installation Shared-Libraries. INSTALL_KLD ist ein Befehl, mit dem Kernelmodule installiert werden knnen. 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 grundstzlich alle install-Befehle mit ihren passenden Flags. Zerlegen von Binrdateien und Shared-Libraries Zerlegen Sie keine Binrdateien manuell, wenn Sie es nicht mssen. Alle Binaries sollten gestripped werden; allerdings vermag das INSTALL_PROGRAM-Makro gleichzeitig eine Binrdatei zu installieren und zu strippen (beachten Sie den nchsten Abschnitt). Das Makro INSTALL_LIB erledigt das gleiche fr Shared-Libraries. Wenn Sie eine Datei strippen mssen, 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 &man.file.1; fr die installierte Applikation, um zu berprfen, ob eine Binrdatei gestripped ist oder nicht. Wenn es nicht meldet not stripped, dann ist es bereits gestripped. Zudem wird &man.strip.1; nicht ein bereits gestripptes Programm nochmals versuchen zu strippen, sondern wird stattdessen einfach sauber beenden. Installation eines ganzen Verzeichnisbaums inklusive Dateien Manchmal muss man eine groe Zahl von Dateien unter Erhalt ihrer hierarchischen Struktur installieren, d.h. Kopieraktionen ber einen ganzen Verzeichnisbaum von WRKSRC zu einem Zielverzeichnis unter PREFIX. Fr 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 ausfhrbar markieren und damit passend fr die Installation in PREFIX/bin vorbereiten. Das zweite Makro, COPYTREE_SHARE, setzt keine Ausfhrungsberechtigungen auf Dateien und ist daher geeignet fr 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. Zustzliche find-Argumente knnen mit dem dritten Argument an die COPYTREE_*-Makros bergeben werden. Um zum Beispiel alle Dateien aus dem 1. Beispiel ohne die Makefiles zu installieren, kann man folgenden Befehl benutzen. 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 hinzufgen, Sie mssen sie immer noch selbst auflisten. Installation zustzlicher Dokumentation Falls Ihre Software zustzlich zu den blichen Manualpages und Info-Seiten weitere Dokumentation hat und Sie diese fr ntzlich halten, dann installieren Sie sie unter PREFIX/share/doc. Dies kann wie vorstehend im Target des post-install geschehen. Legen Sie ein neues Verzeichnis fr Ihren Port an. Das Verzeichnis sollte wiederspiegeln, was der Port ist. Das bedeutet normalerweise PORTNAME. Wie auch immer, wenn Sie meinen, der Nutzer mchte verschiedene Versionen des Ports zur gleichen Zeit installiert haben, dann knnen Sie die gesamte Variable PKGNAME nutzen. Machen Sie die Installation von der Variablen NOPORTDOCS abhngig, damit die Nutzer sie in /etc/make.conf abschalten knnen: post-install: .if !defined(NOPORTDOCS) ${MKDIR} ${DOCSDIR} ${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${DOCSDIR} .endif Hier einige praktische Variablen und wie sie standardmssig 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. NOPORTDOCS behandelt nur zustzliche Dokumentation, die in DOCSDIR installiert ist. Fr 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 mglich. Das bedeutet, dass share/doc/PORTNAME standardmssig 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%%-Prfix 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 fr eine Liste von Dateien und Shell-Globs, um diese zur endgltigen Packliste hinzuzufgen. 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 fr seine Dokumentation, dann mssen Sie die Variable DOCSDIR entsprechend setzen. Wenn ein Verzeichnis in PORTDOCS aufgefhrt ist, oder von einem Shell-Glob dieser Variable abgebildet wird, dann wird der komplette Verzeichnisbaum inklusive Dateien und Verzeichnissen in der endgltigen 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 hinzugefgt. Wie oben gezeigt bleibt es dem Port selbst berlassen, die Dokumentation in PORTDOCS zu installieren. Ein typisches Beispiel fr den Gebrauch von PORTDOCS sieht wie folgt aus: PORTDOCS= README.* ChangeLog docs/* Die quivalente zu PORTDOCS fr unter DATADIR und EXAMPLESDIR installierte Dateien sind PORTDATA beziehungsweise PORTEXAMPLES. Sie knnen auch pkg-message benutzen, um Meldungen whrend der Installation anzuzeigen. Lesen Sie diesen Abschnitt ber den Gebrauch von pkg-message fr weitere Details. Die pkg-message-Datei muss nicht zur pkg-plist hinzugefgt werden. 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 natrlich 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 Binrdateien), sbin (Binrdateien fr Superuser/Manager), info (Dokumentation fr Info-Browser) oder share (Architektur-unabhngige Dateien). Lesen Sie hierzu &man.hier.7;; weitestgehend greifen die Regeln fr /usr auch fr /usr/local. Die Ausnahme sind Ports, welche mit news aus dem USENET arbeiten. In diesem Falle sollte PREFIX/news als Zielort fr die Dateien benutzt werden. Besonderheiten Es gibt einige Dinge mehr, die zu beachten sind, wenn man einen Port erstellt. Dieser Abschnitt erklrt die wichtigsten. 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), whrend des post-install-Targets anzuwenden, um sie im Shared-Library-Cache zu registrieren. Diese Variable, wenn definiert, wird auch dafr sorgen, dass ein entsprechendes @exec /sbin/ldconfig -m und @unexec /sbin/ldconfig -R-Paar zu Ihrer pkg-plist-Datei hinzugefgt wird, sodass ein Benutzer, der das Paket installiert, die Bibliothek danach sofort benutzen kann und das System nach deren Deinstallation nicht glaubt, die Bibliothek wre noch da. USE_LDCONFIG= yes Wenn ntig, knnen Sie das Standardverzeichnis auer 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, knnten Sie folgendes in Ihrem Makefile benutzen: USE_LDCONFIG= ${PREFIX}/lib/foo ${PREFIX}/lib/bar Bitte berprfen Sie dies genau. Oft ist das berhaupt nicht ntig oder kann durch -rpath oder das Setzen von LD_RUN_PATH whrend des Linkens umgangen werden (s. lang/moscow_ml fr ein Beispiel), oder durch einen Shell-Wrapper, der LD_LIBRARY_PATH setzt, bevor er die Binrdatei ausfhrt, 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 kmmert sich nur um die Major (erste) Nummer. Wenn sich die Major-Library-Versionsnummer whrend der Aktualisierung zu einer neuen Portversion erhht, sollte auch die PORTREVISION aller Ports, die die Shared-Library linken, erhht werden, damit diese mit der neuen Version der Bibliothek neu kompiliert werden. Ports mit beschrnkter Verbreitung Lizenzen variieren und manche geben Restriktionen vor, wie die Applikation gepackt werden oder ob sie gewinnorientiert verkauft werden kann, usw. Es liegt in Ihrer Verantwortung als Porter die Lizenzbestimmungen der Software zu lesen und sicherzustellen, dass das FreeBSD-Projekt nicht haftbar gemacht wird fr Lizenzverletzungen durch Weiterverbreitung des Quelltextes oder kompilierter Binaries ber FTP/HTTP oder CD-ROM. Im Zweifelsfall kontaktieren Sie bitte die &a.ports;. In solchen Situationen knnen die in den folgenden Abschnitten beschriebenen Variablen gesetzt werden. <varname>NO_PACKAGE</varname> Diese Variable zeigt an, dass wir keine binren Pakete dieser Applikation erzeugen drfen - z.B. wenn die Lizenz die Weiterverteilung von binren Paketen oder Paketen verbietet, die aus verndertem Quelltext erzeugt wurden. Die DISTFILES des Ports drfen allerdings frei ber FTP/HTTP Mirrors weiterverbreitet werden. Sie drfen auch auf CD-ROM (oder hnlichen Medien) weiterverbreitet werden - es sei denn, NO_CDROM ist ebenfalls gesetzt. NO_PACKAGE sollte auch benutzt werden, wenn das binre Paket nicht allgemein brauchbar ist und die Applikation immer aus dem Quelltext kompiliert werden sollte. Zum Beispiel, wenn die Applikation konfigurierte Informationen 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. <varname>NO_CDROM</varname> Diese Variable gibt an, dassobwohl wir binre Pakete erzeugen drfen – wir weder diese Pakete noch die DISTFILES des Ports auf einer CD-ROM (oder hnlichen Medien) verkaufen drfen. Die DISTFILES des Ports drfen allerdings immer noch auf FTP/HTTP Mirrors. Wenn diese Variable und auch NO_PACKAGE gesetzt ist, dann werden nur die DISTFILES des Ports erhltlich 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 fr nichtkommerzielle Zwecke gilt. <varname>NOFETCHFILES</varname> 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 berprfen, sollten diese Dateien ignorieren und sie nicht melden. <varname>RESTRICTED</varname> Setzen Sie diese Variable, wenn die Lizenz der Applikation weder das Spiegeln der DISTFILES der Applikation noch das Weiterverbreiten von binren 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 proprietre Software enthlt und der Benutzer die DISTFILES manuell herunterladen muss – mglicherweise erst nachdem er sich fr die Software registriert oder die Bedingungen eines Endbenutzer-Lizenzvertrags (EULA) akzeptiert hat. <varname>RESTRICTED_FILES</varname> Wenn RESTRICTED oder NO_CDROM gesetzt ist, ist diese Variable auf ${DISTFILES} ${PATCHFILES} voreingestellt, sonst ist sie leer. Wenn nicht jede dieser Dateien beschrnkt ist, dann fhren Sie die betroffenen Dateien in dieser Variable auf. Beachten Sie, dass der Porter fr jede aufgefhrte Distributionsdatei einen Eintrag zu /usr/ports/LEGAL hinzufgen sollte, der genau beschreibt, was die Beschrnkung mit sich bringt. Build-Mechanismen Paralleles Bauen von Ports Das Ports-Framework von &os; untersttzt das parallele Bauen von Ports, indem es mehrere make-Instanzen ausfhrt, damit SMP-Systeme ihre gesamte CPU-Rechenleistung ausntzen knnen und so das Bauen von Ports schneller und effektiver werden kann. Dies ermglicht der Parameter -jX an &man.make.1;, wenn Code von Drittanbietern kompiliert wird. Leider knnen 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 fr Abhngigkeiten im Makefile aktiviert wird. Eine weitere Mglichkeit im Umgang mit dieser Option besteht fr 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 fr alle Ports den Mehrprozessorbau durch FORCE_MAKE_JOBS=yes in /etc/make.conf erzwingt. <command>make</command>, <command>gmake</command> und <command>imake</command> Wenn Ihr Port GNU make benutzt, dann setzen Sie bitte USE_GMAKE=yes. Port-Variablen im Zusammenhang mit <application>gmake</application> Variable Bedeutung USE_GMAKE Der Port bentigt gmake fr 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 dafr, dass die Konfigurationsphase automatisch ein xmkmf -a ausfhrt. Wenn das Flag ein Problem fr 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 fr install und INSTALL_TARGET. <command>configure</command> 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 zustzliche Argumente bergeben wollen (das Vorgabeargument ist --prefix=${PREFIX} --infodir=${PREFIX}/${INFO_PATH} --mandir=${MANPREFIX}/man --build=${CONFIGURE_TARGET}), setzen Sie diese zustzlichen Argumente in CONFIGURE_ARGS. Zustzliche Umgebungsvariablen knnen berdie Variable CONFIGURE_ENV bergeben werden. Variablen fr Ports, die <command>configure</command> benutzen Variable Bedeutung GNU_CONFIGURE Der Port benutzt ein configure-Skript, um das Bauen vorzubereiten. HAS_CONFIGURE Wie GNU_CONFIGURE, nur dass kein Standard-Konfigurations-Target zu CONFIGURE_ARGS hinzugefgt wird. CONFIGURE_ARGS Zustzliche Argumente fr das configure-Skript. CONFIGURE_ENV Zustzliche Umgebungsvariablen fr die Abarbeitung des configure-Skriptes. CONFIGURE_TARGET Ersetzt das Standard-Konfigurations-Target. Vorgabewert ist ${MACHINE_ARCH}-portbld-freebsd${OSREL}.
Benutzung von <command>scons</command> Wenn Ihr Port SCons benutzt, definieren Sie USE_SCONS=yes. Variablen fr Ports, die <command>scons</command> benutzen Variable Bedeutung SCONS_ARGS Port-spezifische SCons-Argumente, die der SCons-Umgebung 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 bergeben wird – hnlich MAKE_TARGET.
Um SConstruct im Quelltext alles, was SCons in SCONS_ENV bergeben wird, respektieren zu lassen (das ist hauptschlich 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. Benutzung von GNU autotools Einfhrung Die verschiedenen GNU autotools stellen einen Abstraktionsmechanismus bereit fr das Kompilieren von Software fr 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]+ fr mgliche Versionen). operation ist eine optionale Angabe, die modifiziert, wie das Werkzeug benutzt wird. Es knnen 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 verfgbaren Versionen der Autotools abhngt, was sinnvoll fr Cross-Development ist. Dies kann auch erreicht werden, indem man den Port devel/autotools installiert. <command>libtool</command> Shared-Libraries, die das GNU Build-System benutzen, verwenden normalerweise libtool, um die Kompilierung und Installation solcher Bibliotheken anzupassen. Die bliche Praxis ist, eine Kopie von libtool, die mit dem Quelltext geliefert wird, zu benutzen. Falls Sie ein externes libtool bentigen, knnen Sie die Version, die von der Ports-Sammlung bereitgestellt wird, benutzen: USE_AUTOTOOLS= libtool:version[:env] Ohne zustzliche 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. Auerdem werden einige make– und shell-Variablen zur weiteren Benutzung durch den Port gesetzt. Fr Genaueres siehe bsd.autotools.mk. Mit der Angabe :env wird nur die Umgebung vorbereitet. Schlielich knnen optional LIBTOOLFLAGS und LIBTOOLFILES gesetzt werden, um die hufigsten Argumente und durch libtool gepatchten Dateien auer Kraft zu setzen. Die meisten Ports werden das aber nicht brauchen. Fr Weiteres siehe bsd.autotools.mk. <command>libltdl</command> Einige Ports benutzen das libltdl-Bibliothekspaket, welches Teil der libtool-Suite ist. Der Gebrauch dieser Bibliothek macht nicht automatisch den Gebrauch von libtool selbst ntig, deshalb wird ein separates Konstrukt zur Verfgung gestellt. USE_AUTOTOOLS= libltdl:version Im Moment sorgt dies nur fr eine LIB_DEPENDS-Abhngigkeit von dem entsprechenden libltdl-Port und wird zur Vereinfachung zur Verfgung gestellt, um Abhngigkeiten von den Autotools-Ports ausserhalb des USE_AUTOTOOLS-Systems zu eliminieren. Es gibt keine weiteren Angaben fr dieses Werkzeug. <command>autoconf</command> und <command>autoheader</command> Manche Ports enthalten kein Konfigurationsskript, sondern eine autoconf-Vorlage in der configure.ac-Datei. Sie knnen 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. hnlich wie bei libtool, bereitet die Angabe des optionalen :env nur die Umgebung fr weitere Benutzung vor. Ohne dieses wird der Port auch gepatched und erneut konfiguriert. Die zustzlichen optionalen Variablen AUTOCONF_ARGS und AUTOHEADER_ARGS knnen durch das Makefile des Ports ausser Kraft gesetzt werden, wenn erforderlich. Wie bei den libtool-quivalenten werden die meisten Ports dies aber nicht bentigen. <command>automake</command> und <command>aclocal</command> Manche Pakete enthalten nur Makefile.am-Dateien. Diese mssen durch automake in Makefile.in-Dateien konvertiert und dann durch configure weiterbearbeitet werden, um schlielich ein Makefile zu erzeugen. hnliches gilt fr Pakete, die gelegentlich keine aclocal.m4-Dateien mitliefern, welche ebenfalls zum Erstellen der Software bentigt werden. Diese knnen durch aclocal erzeugt werden, welches configure.ac oder configure.in durchsucht. aclocal hat eine 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. 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 ntig, auer Kraft gesetzt werden kann. Benutzung von GNU <literal>gettext</literal> Grundlegende Benutzung Wenn Ihr Port gettext bentigt, setzen Sie einfach USE_GETTEXT auf yes, und Ihr Port bekommt die Abhngigkeit von devel/gettext. Der Wert von USE_GETTEXT kann auch die bentigte 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 hufiger Fall ist, dass ein Port gettext und configure benutzt. Normalerweise sollte GNU configure gettext automatisch finden knnen. Sollte das einmal nicht funktionieren, knnen Hinweise ber den Ort von gettext in CPPFLAGS und LDFLAGS wie folgt bergeben werden: USE_GETTEXT= yes CPPFLAGS+= -I${LOCALBASE}/include LDFLAGS+= -L${LOCALBASE}/lib GNU_CONFIGURE= yes CONFIGURE_ENV= CPPFLAGS="${CPPFLAGS}" \ LDFLAGS="${LDFLAGS}" Natrlich kann der Code kompakter sein, wenn es keine weiteren Flags gibt, die configure bergeben werden mssen: USE_GETTEXT= yes GNU_CONFIGURE= yes CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include" \ LDFLAGS="-L${LOCALBASE}/lib" Optionale Benutzung Manche Softwareprodukte erlauben die Deaktivierung von NLS - z.B. durch bergeben von an configure. In diesem Fall sollte Ihr Port gettext abhngig vom Status von WITHOUT_NLS benutzen. Fr Ports mit niedriger bis mittlerer Komplexitt knnen 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 nchste Punkt auf Ihrer Todo-Liste ist dafr zu sorgen, dass die Message-Catalog-Dateien nur bedingt in der Packliste aufgefhrt werden. Der Makefile-Teil dieser Aufgabe ist schon durch obiges Idiom erledigt. Das wird im Abschnitt ber Fortgeschrittene pkg-plist-Methoden erklrt. 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 endgltigen Packliste, wenn NLS abgeschaltet ist; andernfalls wird der Prefix einfach nur ausgelassen. Alles, was Sie jetzt noch machen mssen, ist %%NLS%% vor jedem Pfad zu einer Message-Catalog-Datei in pkg-plist einzufgen. Zum Beispiel: %%NLS%%share/locale/fr/LC_MESSAGES/foobar.mo %%NLS%%share/locale/no/LC_MESSAGES/foobar.mo In sehr komplexen Fllen mssen Sie eventuell fortgeschrittenere Techniken als die hier vorgestellte benutzen - wie z.B. Dynamische Packlistenerzeugung. 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 gelscht werden. Die Verzeichnisse fr die gebruchlichsten Sprachen sind in /etc/mtree/BSD.local.dist aufgelistet; das heisst, sie sind Teil des Systems. Die Verzeichnisse fr 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 fr eine seltene Sprache installiert. Die Benutzung von <literal>perl</literal> 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 fr p5-Module-Name-Module. Die Top-Level-Hierarchie kann unter cpan.org angeschaut werden. Dies sorgt dafr, dass der Port weiter funktioniert, wenn sich der Autor des Moduls ndert. Die Ausnahme dieser Regel ist, dass das entsprechende Verzeichnis selber oder das Distfile in diesem Verzeichnis nicht existiert. In solchen Fllen 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 untersttzten 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. Variablen fr Ports, die <literal>perl</literal> benutzen Variable Bedeutung USE_PERL5 Bedeutet, dass der Port perl 5 zum Erstellen und zum Ausfhren 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. PERL Der gesamte Pfad zu perl 5 – entweder im Basissystem oder nachinstalliert ber einen Port – ohne die Versionsnummer. Benutzen Sie diese Variable, wenn Sie #!-Zeilen in Skripten ersetzen mssen. PERL_CONFIGURE Perls MakeMaker fr die Konfiguration benutzen. Dies impliziert USE_PERL5. PERL_MODBUILD Module::Build fr configure, build und install benutzen. Dies impliziert PERL_CONFIGURE. Nur lesbare Variablen Bedeutung PERL_VERSION Die volle Version des installierten perl (z.B. 5.8.9). PERL_LEVEL Die installierte perl-Version als ein Integer der Form MNNNPP (z.B. 500809). PERL_ARCH Wo perl architektur abhngige Bibliotheken ablegt. Vorgabe ist ${ARCH}-freebsd. PERL_PORT Name des perl-Ports, der installiert ist (z.B. perl5). SITE_PERL Verzeichnis, in das die Site-spezifischen perl-Pakete kommen. Dieser Wert wird zu PLIST_SUB hinzugefgt.
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). Benutzung von X11 X.Org-Komponenten Die X11-Implementierung, welche die Ports-Sammlung bereitstellt, ist X.Org. Wenn Ihre Applikation von X-Komponenten abhngt, listen Sie die bentigten 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 knnen eine Abhngigkeit von verschiedenen Komponenten diese Projektes in der Variable USE_GL spezifizieren. ouml;gliche Optionen sind: glut, glu, glw, glew, gl und linux. Fr Abwrtskompatibilitt gilt der Wert yes als glu. Beispiel fr USE_XORG USE_XORG= xrender xft xkbfile xt xaw USE_GL= glu Viele Ports definieren USE_XLIB, was dafr sorgt, dass der Port von allen (rund 50) Bibliotheken abhngt. Diese Variable existiert, um Abwrtskompatibilitt sicherzustellen (sie stammt noch aus der Zeit vor dem modularem X.Org), und sollte bei neuen Ports nicht mehr benutzt werden. Variablen fr Ports, die X benutzen USE_XLIB Der Port benutzt die X-Bibliotheken. Soll nicht mehr verwendet werden - benutzen Sie stattdessen eine Liste von Komponenten in USE_XORG. USE_X_PREFIX Soll nicht mehr benutzt werden, ist jetzt quivalent zu USE_XLIB und kann einfach durch letzteres ersetzt werden. USE_IMAKE Der Port benutzt imake. Impliziert USE_X_PREFIX. XMKMF Ist auf den Pfad zu xmkmf gesetzt, wenn nicht in PATH. Vorgabe ist xmkmf -a.
Variablen bei Abhngigkeit von einzelnen Teilen von X11 X_IMAKE_PORT Ein Port, der imake und einige andere 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 fr 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;-Schriftarten bereitstellt. X_FONTS_TYPE1_PORT Ein Port, der Type1-Schriftarten bereitstellt. X_MANUALS_PORT Ein Port, der entwicklerorientierte Manualpages bereitstellt.
Benutzung von X11-bezogenen Variablen in einem Port # Port benutzt X11-Bibliotheken und hngt 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 Ports, die Motif bentigen Wenn Ihr Port eine Motif-Bibliothek bentigt, definieren Sie USE_MOTIF im Makefile. Die Standard-Motif-Implementierung ist x11-toolkits/open-motif. Benutzer knnen stattdessen x11-toolkits/lesstif whlen, 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 berall ${MOTIFLIB} benutzt, wo die Motif-Bibliothek im Original Makefile oder Imakefile referenziert wird. Es gibt zwei verbreitete Flle: 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 mssen kein -L oder -l davor einfgen. X11 Schriftarten Wenn Ihr Port Schriftarten fr das X-Window-System installiert, legen Sie diese nach LOCALBASE/lib/X11/fonts/local. Erzeugen eines knstlichen <envar>DISPLAY</envar> durch Xvfb Manche Applikationen bentigen ein funktionierendes X11-Display, damit die Kompilierung funktioniert. Das stellt fr 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 bergeben. USE_DISPLAY= yes Desktop-Eintrge Desktop-Eintrge (Freedesktop Standard) knnen in Ihrem Port einfach ber die DESKTOP_ENTRIES-Variable erzeugt werden. Diese Eintrge erscheinen dann im Applikationsmen von standardkonformen Desktop-Umgebungen wie GNOME oder KDE. Die .desktop-Datei wird dann automatisch erzeugt, installiert und der pkg-plist hinzugefgt. Die Syntax ist: DESKTOP_ENTRIES= "NAME" "COMMENT" "ICON" "COMMAND" "CATEGORY" StartupNotify Die Liste der mglichen Kategorien ist auf der Freedesktop Webseite abrufbar. StartupNotify zeigt an, ob die Applikation den Status in Umgebungen, die Startup-Notifications kennen, lschen 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 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. Benutzung von Qt Ports, die Qt bentigen Variablen fr Ports, die Qt bentigen USE_QT_VER Der Port benutzt das Qt-Toolkit. Mgliche Werte sind 3 und 4; diese spezifizieren die Major Version von Qt, die benutzt werden soll. Entsprechende Parameter werden an das configure-Skript und make bergeben. QT_PREFIX Enthlt den Pfad, wohin Qt installiert ist (nur lesbare Variable). MOC Enthlt den Pfad von moc (nur lesbare Variable). Voreingestellt entsprechend des USE_QT_VER-Werts. QTCPPFLAGS Zustzliche Compiler-Flags, die ber CONFIGURE_ENV an das Qt-Toolkit bergeben werden. Voreingestellt entsprechend des USE_QT_VER-Wertes. QTCFGLIBS Zustzliche Bibliotheken, die ber CONFIGURE_ENV fr das Qt-Toolkit gelinkt werden sollen. Voreingestellt entsprechend des USE_QT_VER-Wertes. QTNONSTANDARD nderungen von CONFIGURE_ENV, CONFIGURE_ARGS und MAKE_ENV sollen unterdrckt werden.
Zustzliche Variablen fr Ports, die Qt 4.xi benutzen QT_COMPONENTS Spezifiziert Tool– und Bibliothek-Abhngigkeiten fr Qt4. Siehe unten fr Details. UIC Enthlt den Pfad von uic (nur lesbare Variable). Voreingestellt entsprechend des USE_QT_VER-Wertes. QMAKE Enthlt den Pfad von qmake (nur lesbare Variable). Voreingestellt entsprechend des USE_QT_VER-Wertes. QMAKESPEC Enthlt den Pfad der Konfigurationsdatei fr qmake (nur lesbare Variable). Voreingestellt entsprechend des USE_QT_VER-Wertes.
Wenn USE_QT_VER gesetzt ist, werden dem configure-Skript einige ntzliche Einstellungen 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 bergeben: CONFIGURE_ENV+= UIC="${UIC}" QMAKE="${QMAKE}" QMAKESPEC="${QMAKESPEC}" MAKE_ENV+= QMAKESPEC="${QMAKESPEC}" Komponentenauswahl (nur bei Qt 4.x) Wenn USE_QT_VER auf 4 gesetzt ist, knnen individuelle Qt4-Tool- und Bibliotheksabhngigkeiten in der Variable QT_COMPONENTS angegeben werden. An jede Komponente kann _build oder _run als Suffix angehngt werden, was eine Abhngigkeit zur Build- bzw. Laufzeit angibt. Ohne Suffix gilt die Abhngigkeit sowohl zur Build- als auch zur Laufzeit. Bibliothekskomponenten sollten normalerweise ohne Suffix angegeben werden, Tool-Komponenten mit _build und Plugin-Komponenten mit _run. Die gebruchlichsten Komponenten werden im Folgenden angegeben (alle verfgbaren Komponenten sind in _QT_COMPONENTS_ALL in /usr/ports/Mk/bsd.qt.mk aufgelistet): Verfgbare Qt4-Bibliothekskomponenten Name Beschreibung corelib Kern-Bibliothek (kann weggelassen werden– es sei denn, der Port benutzt nichts auer corelib) gui Graphische Benutzeroberflchen-Bibliothek network Netzwerk-Bibliothek opengl OpenGL-Bibliothek qt3support Qt3-Kompatibilitts-Bibliothek qtestlib Modultest-Bibliothek script Skript-Bibliothek sql SQL-Bibliothek xml XML-Bibliothek
Sie knnen herausfinden, welche Bibliotheken die Applikation bentigt, indem Sie nach erfolgreicher Kompilierung ldd auf die Hauptbinrdatei anwenden. Verfgbare Qt4-Tool-Komponenten Name Beschreibung moc meta object compiler (wird zum Build fast jeder Qt-Applikation bentigt) qmake Makefile-Generator / Build-Werkzeug rcc Resource-Compiler (wird bentigt, falls die Applikation *.rc oder *.qrc Dateien enthlt) uic User-Interface-Compiler (wird bentigt, falls die Applikation von Qt-Designer erzeugte *.ui Dateien enthlt - gilt fr praktisch jede Qt-Applikation mit einer GUI)
Verfgbare Qt4-Plugin-Komponenten Name Beschreibung iconengines SVG-Icon-Engine Plugin (wenn die Applikation SVG-Icons mitliefert) imageformats Bildformatplugins fr GIF, JPEG, MNG und SVG (wenn die Applikation Bilddateien mitliefert)
Qt4-Komponenten auswhlen 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 Abhngigkeit von der Core-Bibliothek impliziert, muss corelib nicht angegeben werden. Die Qt4-Codeerzeugungstools moc, uic und rcc, sowie der Makefile Generator qmake werden nur fr den Build bentigt, deshalb bekommen die den Suffix _build: USE_QT_VER= 4 QT_COMPONENTS= gui moc_build qmake_build rcc_build uic_build Zustzliche Besonderheiten Wenn die Applikation keine configure Datei, sondern eine .pro Datei hat, knnen Sie das Folgende benutzen: HAS_CONFIGURE= yes do-configure: @cd ${WRKSRC} && ${SETENV} ${CONFIGURE_ENV} \ ${QMAKE} -unix PREFIX=${PREFIX} texmaker.pro Beachten Sie die hnlichkeit mit der qmake-Zeile im mitgelieferten BUILD.sh-Skript. Die bergabe von CONFIGURE_ENV stellt sicher, dass qmake die QMAKESPEC-Variable bergeben bekommt, ohne die es nicht funktioniert. qmake erzeugt Standard-Makefiles, sodass es nicht ntig ist ein eigenes neues build-Target zu schreiben. Qt-Applikationen sind oft so geschrieben, dass sie plattformbergreifend sind, und oft ist X11/Unix nicht die Plattform, auf der sie entwickelt werden. Das sorgt oft fr bestimmte fehlende Kleinigkeiten wie z.B.: Fehlende zustzliche Include-Pfade. Viele Applikationen kommen mit System-Tray-Icon Support– unterlassen es aber Includes oder Bibliotheken in den X11 Verzeichnissen zu suchen. Sie knnen qmake ber die Kommandozeile sagen, es soll Verzeichnisse zu den Include- und Bibliotheks-Suchpfaden hinzufgen - 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 hierfr ein Beispiel– siehe patch-texmaker.pro im files-Verzeichnis dieses Ports als eine Vorlage, die zeigt, wie man dies direkt in der Qmake Projektdatei lst. Benutzung von KDE Variablen-Definitionen (KDE 3) Variablen fr Ports, die KDE 3 benutzen USE_KDELIBS_VER Der Port benutzt KDE-Bibliotheken. Die Variable spezifiziert die Major Version von KDE, die benutzt werden soll, und impliziert USE_QT_VER der entsprechenden Version. Der einzig mgliche Wert ist 3. USE_KDEBASE_VER Der Port benutzt die KDE-Base. Die Variable spezifiziert die Major Version von KDE, die benutzt werden soll, und impliziert USE_QT_VER der entsprechenden Version. Der einzig mgliche Wert ist 3.
Variablen-Definitionen (KDE 4) Falls Ihre Anwendung von KDE 4 abhngt, weisen Sie USE_KDE4 eine Liste mit bentigten Komponenten zu. Die am hufigsten gebrauchten sind unten aufgelistet (_USE_KDE4_ALL in /usr/ports/Mk/bsd.kde4.mk enthlt stets die aktuelle Liste): Verfgbare KDE 4-Komponenten Name Beschreibung akonadi Personal Information Management (PIM)-Speicherdienst automoc4 Lsst 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 standardmig gesetzte Variable PREFIX berschreibt. Die Ports bernehmen jedoch, jeden ber die Umgebungsvariable MAKEFLAGS oder make-Parameter festgelegten Wert fr PREFIX. Es knnte 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 mglich, KDE 4-Ports unter einem angepassten PREFIX zu installieren. Wenn PREFIX als MAKEFLAGS-Umgebungsvariable oder als make-Parameter gesetzt wird, berschreibt dies den von kdeprefix festgelegten Wert. <varname>USE_KDE4</varname>-Beispiel Dies ist ein einfaches Beispiel fr 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 Abhngigkeit von KDE-Bibliotheken und die Verwendung von automoc4 whrend der Kompilierung fest. Mit Hilfe des configure-Protokolls knnen die KDE-Komponenten und andere Abhngigkeiten festgestellt werden. USE_KDE4 impliziert USE_QT_VER nicht. Falls der Port Qt 4-Komponenten bentigt, 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 Benutzung von Java Variablen-Definitionen Wenn Ihr Port ein Java™ Development Kit (JDK™) bentigt, 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 bentigt, knnen Sie definieren welche. Die aktuelle Version ist java/jdk16. Variablen, die von Ports, die Java benutzen, gesetzt werden mssen Variable Bedeutung USE_JAVA Sollte definiert sein, damit die brigen Variablen irgendeinen Effekt haben. JAVA_VERSION Durch Leerzeichen getrennte Liste von geeigneten Java-Versionen fr den Port. Ein optionales "+" ermglicht die Angabe eines Bereiches von Versionen (mgliche Werte: 1.5[+] 1.6[+] 1.7[+]). JAVA_OS Durch Leerzeichen getrennte Liste von geeigneten JDK-Port-Betriebssystemen fr den Port. (erlaubte Werte: native linux). JAVA_VENDOR Durch Leerzeichen getrennte Liste von geeigneten JDK-Port-Anbietern fr den Port. (erlaubte Werte: freebsd bsdjava sun openjdk). JAVA_BUILD Bedeutet, falls gesetzt, dass der ausgewhlte JDK-Port zu den Build-Abhngigkeiten des Ports hinzugefgt werden soll. JAVA_RUN Bedeutet, falls gesetzt, dass der ausgewhlte JDK-Port zu den Laufzeit-Abhngigkeiten des Ports hinzugefgt werden soll. JAVA_EXTRACT Bedeutet, falls gesetzt, dass der ausgewhlte JDK-Port zu den Extract-Abhngigkeiten des Ports hinzugefgt werden soll.
Das Folgende ist eine Liste aller Variablen, die ein Port bekommt, nachdem er USE_JAVA gesetzt hat: Bereitgestellte Variablen fr Ports, die Java benutzen Variable Wert JAVA_PORT Der Name des JDK-Ports (z.B. 'java/diablo-jdk16'). JAVA_PORT_VERSION Die volle Version des JDK Ports (z.B. '1.6.0'). Wenn Sie nur die ersten beiden Stellen dieser Versionsnummer bentigen, 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'. JAR Pfad zum jar-Werkzeug, das benutzt werden soll (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'). JAVA Pfad zur java Binrdatei. Benutzen Sie dies, um Java-Programme auszufhren (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 enthlt, ${JAVA_HOME}/jre/lib/rt.jar.
Sie knnen das java-debug make-Target benutzen, um Information zum Debuggen Ihres Ports zu erhalten. Es wird die Werte vieler der obenangegebenen Variablen anzeigen. Zustzlich sind die folgenden Konstanten definiert, damit alle Java-Ports auf eine konsistente Art installiert werden knnen: Konstanten, die fr Ports, welche Java benutzen, definiert sind Konstante Wert JAVASHAREDIR Das Basis-Verzeichnis fr alles, was mit Java zusammenhngt. Standardmig ${PREFIX}/share/java. JAVAJARDIR Das Verzeichnis, wohin JAR-Dateien installiert werden sollen. Standardmig ${JAVASHAREDIR}/classes. JAVALIBDIR Das Verzeichnis, in dem JAR-Dateien, die von anderen Ports installiert wurden, liegen. Standardmig ${LOCALBASE}/share/java/classes.
Die entsprechenden Eintrge sind sowohl in PLIST_SUB (dokumentiert in ) als auch in SUB_LIST definiert. 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 hnelt dem USE_GMAKE-Mechanismus, der in dokumentiert ist. 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 Gre der Packlistendatei zu reduzieren, knnen 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-Abhngigkeiten). Die Benutzung von ${JAVASHAREDIR}/${PORTNAME} wird in dieser Beziehung dringend empfohlen. Es liegt im Entscheidungsbereich des Portierenden, ob der Port die zustzlichen JAR-Abhngigkeiten unter diesem Verzeichnis installieren oder direkt die schon installierten (aus ${JAVAJARDIR}) benutzen soll. Unabhngig von der Art Ihres Ports (Bibliothek oder Applikation), sollte die zustzliche Dokumentation an die gleiche Stelle installiert werden wie bei jedem anderen Port auch. Das JavaDoc-Werkzeug ist dafr bekannt einen unterschiedlichen Satz von Dateien abhngig von der Version des benutzten JDKs zu erstellen. Fr 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. Auerdem, selbst wenn Sie den Satz von Dateien, den javadoc erzeugen wird, voraussagen knnen, die Gre der resultierenden pkg-plist befrwortet die Benutzung von PORTDOCS. Der Vorgabewert fr DATADIR ist ${PREFIX}/share/${PORTNAME}. Es ist eine gute Idee, DATADIR fr Java-Ports stattdessen auf ${JAVASHAREDIR}/${PORTNAME} zu setzen. In der Tat wird DATADIR automatisch zu PLIST_SUB (dokumentiert in ) hinzugefgt, d.h. Sie knnen %%DATADIR%% direkt in pkg-plist benutzen. Zu der Frage, ob Java-Ports aus dem Quelltext gebaut werden, oder direkt bereitgestellte binre Distributionen benutzt werden sollten, gab es, als dies geschrieben wurde, keine definierte Richtlinie. Allerdings ermutigen Mitglieder des &os; Java-Projekts Porter dazu, Ihre Ports aus dem Quelltext kompilieren zu lassen, wann immer dies kein Problem darstellt. Alle Eigenschaften, die in diesem Abschnitt prsentiert wurden sind in bsd.java.mk implementiert. Sollten Sie jemals der Meinung sein, dass Ihr Port ausgefeiltere Java-Untersttzung bentigt, 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 fr viele andere Java Ports ntzlich sein knnte, wenden Sie sich bitte an die &a.java;. Obwohl es eine java-Kategorie fr Fehlerberichte gibt, bezieht sich diese auf die JDK-Portierungsbemhungen des &os; 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 klren versuchen, steht in Zusammenhang entweder mit einer JDK-Implementierung oder bsd.java.mk. Gleichermaen gibt es eine definierte Richtlinie fr die CATEGORIES eines Java-Ports, die in erklrt wird. Webanwendungen, Apache und PHP Apache Variablen fr Ports, die Apache verwenden USE_APACHE Der Port bentigt Apache. Mgliche Werte: yes (beliebige Version), 1.3, 2.0, 2.2, 2.0+, etc. – Standard ist Version 1.3. WITH_APACHE2 Der Port bentigt Apache 2.0. Ist diese Variable nicht gesetzt, so bentigt der Port Apache 1.3. Diese Variable ist veraltet und sollte nicht mehr verwendet werden. APXS Vollstndiger Pfad zu der apxs Binrdatei. Die Variable kann neu gesetzt werden. HTTPD Vollstndiger Pfad zu der httpd Binrdatei. Die Variable kann neu gesetzt werden. APACHE_VERSION Beinhaltet die Versionsnummer des aktuell installierten Apache (nur lesbare Variable). Diese Variable ist nach Einbinden der Datei bsd.port.pre.mk verfgbar. Mgliche Werte: 13, 20, 22. APACHEMODDIR Verzeichnis der Apache-Module. Diese Variable wird automatisch in pkg-plist ersetzt. APACHEINCLUDEDIR Verzeichnis der Apache Header-Dateien. Diese Variable wird automatisch in pkg-plist ersetzt. APACHEETCDIR Verzeichnis der Apache-Konfigurationsdateien. Diese Variable wird automatisch in pkg-plist ersetzt.
Ntzliche Variablen fr Ports von Apache-Modulen MODULENAME Name des Moduls. Standardwert ist PORTNAME. Beispiel: mod_hello SHORTMODNAME Der gekrzte Name des Moduls. Standardmig wird der Wert von MODULENAME 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 fr zustzliche Header-Dateien, die beim Kompilieren mitverwendet werden. AP_LIB Verzeichnis fr zustzliche Bibliothek-Dateien, welche beim Kompilieren mitverwendet werden. AP_EXTRAS Zustzliche Flags fr apxs.
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 verfgbar. 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 bentigt, so sollte dieser auch nicht als Abhngigkeit des Ports aufgefhrt werden. Dadurch bleibt es dem Benutzer berlassen Apache oder einen anderen Webserver zu verwenden. PHP Variablen fr Ports, die PHP verwenden USE_PHP Der Port bentigt PHP. Der Wert yes bewirkt eine Abhngigkeit des Ports von PHP. Es kann auch eine Liste der bentigten PHP-Erweiterungen angegeben werden. Beispiel: pcre xml gettext DEFAULT_PHP_VER Legt die Version von PHP fest, die standardmig installiert wird, falls noch kein PHP vorhanden ist. Standardwert ist 4. Mgliche Werte sind: 4,5 IGNORE_WITH_PHP Der Port funktioniert nicht mit der angegebenen Version von PHP. Mgliche Werte: 4, 5 USE_PHPIZE Der Port wird als PHP-Erweiterung gebaut. USE_PHPEXT Der Port wird wie eine PHP-Erweiterung behandelt – Installation und Eintragung in die PHP-Registry fr Erweiterungen. USE_PHP_BUILD Setzt PHP als build-Anhngigkeit. WANT_PHP_CLI Bentigt die Kommandozeilen-Version von PHP. WANT_PHP_CGI Bentigt die CGI-Version von PHP. WANT_PHP_MOD Bentigt das Apache-Modul von PHP. WANT_PHP_SCR Bentigt die Kommandozeilen- oder die CGI-Version von PHP. WANT_PHP_WEB Bentigt das Apache-Modul oder die CGI-Version von PHP.
PEAR Module Das Portieren von PEAR-Modulen ist sehr einfach. Mit Hilfe der Variablen FILES, TESTS, DATA, SQLS, SCRIPTFILES, DOCS und EXAMPLES knnen die zu installierenden Dateien angegeben werden. Alle aufgefhrten Dateien werden automatisch in die jeweiligen Verzeichnisse installiert und der Datei pkg-plist hinzugefgt. Die Datei ${PORTSDIR}/devel/pear/bsd.pear.mk muss am Ende des Makefiles eingebunden werden. Beispiel eines Makefiles fr 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> Python benutzen Die Ports untersttzen parallele Installationen mehrerer Python-Versionen. Ports sollten sicherstellen, dass der richtige python-Interpreter verwendet wird – entsprechend der durch den Benutzer definierbaren Variable PYTHON_VERSION. Hufig 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 Prfix des Paketnamens haben, sodass in deren Paketname die zugehrige Python Version aufgefhrt wird. PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX} Ntzliche Variablen fr Ports, die Python verwenden USE_PYTHON Der Port bentigt Python. Die minimal bentigte Version kann durch Werte wie 2.3+ angegeben werden. Bereiche von Versionsnummern knnen durch Angabe der minimalen und maximalen Versionsnummer, getrennt durch einen Gedankenstrich, festgelegt werden, z.B.: 2.1-2.3 USE_PYDISTUTILS Verwende Python-distutils zum Konfigurieren, Kompilieren und Installieren. Dies ist erforderlich, falls der Port eine setup.py-Datei beinhaltet. Dadurch werden die do-build und do-install-Ziele und eventuell auch das do-configure-Ziel bergangen, falls GNU_CONFIGURE nicht definiert ist. PYTHON_PKGNAMEPREFIX Wird als PKGNAMEPREFIX verwendet, um Pakete fr unterschiedliche Python-Versionen zu trennen. Beispiel: py24- PYTHON_SITELIBDIR Verzeichnis des site-Pakete Baums, der das Installationsverzeichnis von Python (blicherweise LOCALBASE) beinhaltet. Die PYTHON_SITELIBDIR-Variable kann sehr ntzlich bei der Installation von Python-Modulen sein. PYTHONPREFIX_SITELIBDIR Die prfix-freie Variante von PYTHON_SITELIBDIR. Benutzen Sie immer %%PYTHON_SITELIBDIR%% in pkg-plist, wenn mglich. Der Standardwert von %%PYTHON_SITELIBDIR%% ist lib/python%%PYTHON_VERSION%%/site-packages PYTHON_CMD Kommandozeilen-Interpreter fr Python mit Versionsnummer. PYNUMERIC Liste der Abhngigkeiten fr numerische Erweiterungen. PYNUMPY Liste der Abhngigkeiten fr die neue numerische Erweiterung numpy. (PYNUMERIC ist vom Anbieter als veraltet deklariert) PYXML Liste der Abhngigkeiten fr XML-Erweiterungen (wird ab Python 2.0 nicht mehr bentigt, da im Basispaket enthalten). USE_TWISTED Setzt die Abhngigkeit des Ports von twistedCore. Die Liste der erforderlichen Komponenten kann als Wert spezifiziert werden. Beispiel: web lore pair flow USE_ZOPE Setzt Zope, eine Plattform fr Webanwendungen, als Abhngigkeit des Ports. Setzt die Versionsabhngigkeit von Python auf 2.3. Setzt ZOPEBASEDIR auf das Verzeichnis, in welches Zope installiert wurde.
Eine vollstndige Liste aller verfgbaren Variablen ist in /usr/ports/Mk/bsd.python.mk zu finden. Benutzung von <application>Tcl/Tk</application> Die Ports-Sammlung untersttzt die parallele Installation mehrerer Tcl/Tk-Versionen. Ports sollten mindestens die vorgegebene Tcl/Tk-Version oder hher zu untersttzen versuchen anhand der Variablen USE_TCL und USE_TK. Es ist mglich, die gewnschte Version von tcl mit der Variable WITH_TCL_VER vorzuschreiben. uerst ntzliche Variablen fr Ports, die <application>Tcl/Tk</application> benutzen USE_TCL Der Port bentigt die Tcl-Bibliothek (nicht die Shell). Eine notwendige Mindestversion kann mit Werten wie 84+ angegeben werden. Einzelne nicht untersttzte Versionen knnen mit der Variable INVALID_TCL_VER festgelegt werden. USE_TCL_BUILD Der Port bentigt Tcl nur whrend der Zeit, in der er gebaut wird. USE_TCL_WRAPPER Ports, welche zwar die Tcl-Shell, aber nicht eine bestimmte Version von tclsh verlangen, sollten diese neue Variable verwenden. Ein Wrapperskript fr tclsh wird auf dem System installiert. Der Benutzer kann festlegen, welche tcl-Shell gewnscht ist bzw. verwendet werden soll. WITH_TCL_VER Benutzerdefinierte Variable, welche die gewnschte Tcl-Version bestimmt. PORTNAME_WITH_TCL_VER Gleich wie WITH_TCL_VER, nur portspezifisch. USE_TCL_THREADS Fordere threadfhiges Tcl/Tk. USE_TK Der Port bentigt die Tk-Bibliothek (nicht die Wish-Shell). Impliziert USE_TCL mit dem gleichen Wert. Fr weitere Informationen siehe die Beschreibung der Variable USE_TCL. USE_TK_BUILD Analog zur Variable USE_TCL_BUILD. USE_TK_WRAPPER Analog zur Variable USE_TCL_WRAPPER. WITH_TK_VER Analog zur Variable WITH_TCL_VER und impliziert WITH_TCL_VER mit dem gleichen Wert.
Eine vollstndige Liste der zur Verfgung stehenden Variablen befindet sich in /usr/ports/Mk/bsd.tcl.mk. Emacs benutzen Dieser Abschnitt muss noch geschrieben werden. Ruby benutzen Ntzliche Variablen fr Ports, die Ruby verwenden Variable Description USE_RUBY Der Port bentigt Ruby. USE_RUBY_EXTCONF Der Port verwendet extconf.rb fr die Konfiguration. USE_RUBY_SETUP Der Port verwendet setup.rb fr die Konfiguration. RUBY_SETUP Legt den alternativen Namen von setup.rb fest. blich ist der Wert install.rb.
Die folgende Tabelle listet ausgewhlte Variablen auf, die Portautoren ber die Port-Infrastruktur zur Verfgung stehen. Diese Variablen sollten fr die Installation von Dateien in die entsprechenden Verzeichnisse verwendet werden. Sie sollten in pkg-plist so hufig wie mglich verwendet und in einem Port nicht neu definiert werden. Ausgewhlte read-only-Variablen fr Ports, die Ruby verwenden Variable Beschreibung Beispiel RUBY_PKGNAMEPREFIX Wird als PKGNAMEPREFIX verwendet, um Pakete fr verschiedene Versionen von Ruby zu unterscheiden. ruby18- RUBY_VERSION Vollstndige Version von Ruby in der Form x.y.z. 1.8.2 RUBY_SITELIBDIR Installationsverzeichnis der von der Rechnerarchitektur unabhngigen Bibliotheken. /usr/local/lib/ruby/site_ruby/1.8 RUBY_SITEARCHLIBDIR Installationsverzeichnis der von der Rechnerarchitektur abhngigen Bibliotheken. /usr/local/lib/ruby/site_ruby/1.8/amd64-freebsd6 RUBY_MODDOCDIR Installationsverzeichnis fr die Dokumentation der Module. /usr/local/share/doc/ruby18/patsy RUBY_MODEXAMPLESDIR Installationsverzeichnis fr die Beispiele der Module. /usr/local/share/examples/ruby18/patsy
Eine vollstndige Liste der verfgbarenVariablen kann in /usr/ports/Mk/bsd.ruby.mk eingesehen werden. SDL verwenden Die Variable USE_SDL wird fr die automatische Konfiguration der Abhngigkeiten fr 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 abhngt, so wre die Syntax: USE_SDL= net mixer Die Abhngigkeit von devel/sdl12, die durch net/sdl_net und audio/sdl_mixer entsteht, wird automatisch zum Port hinzugefgt. Falls USE_SDL im Port verwendet wird, so wird automatisch: die Abhngigkeit von sdl12-config zu BUILD_DEPENDS hinzugefgt die Variable SDL_CONFIG zu CONFIGURE_ENV hinzugefgt die Abhngigkeit der ausgewhlten Bibliotheken zu LIB_DEPENDS hinzugefgt Um zu berprfen, ob die SDL-Bibliotheken verfgbar 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> <application>wxWidgets</application> verwenden Dieser Abschnitt beschreibt den Status der wxWidgets-Bibliotheken in den Ports und deren Einbindung in das Ports-System. Einfhrung 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 gelst, dass jede Version unter einem eigenen Namen installiert wird, der die Versionsnummer als Suffix beinhaltet. Der offensichtliche Nachteil dabei ist, dass jede Anwendung so verndert werden muss, dass sie die erwartete Version vorfindet. Die meisten solcher Anwendungen benutzen das wx-config-Skript, um die bentigten Compiler- und Linkerflags zu erhalten. Dieses Skript hat fr jede verfgbare Version einen anderen Namen. Die meisten Anwendungen beachten eine Umgebungsvariable oder ein Argument beim configure-Skript, um das gewnschte wx-config-Skript festzulegen. Ansonsten mssen sie gepatcht werden. 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): Variablen, um die <application>wxWidgets</application>-Version festzulegen Variable Beschreibung Standardwert USE_WX Liste der Versionen, die der Port verwenden kann Alle verfgbaren Versionen USE_WX_NOT Liste der Versionen, die der Port nicht verwenden kann Nichts
Es folgt eine Liste an mglichen wxWidgets-Versionen und deren zugehriger Port: Verfgbare <application>wxWidgets</application>-Versionen Version Port 2.4 x11-toolkits/wxgtk24 2.6 x11-toolkits/wxgtk26 2.8 x11-toolkits/wxgtk28
Ab Version 2.5 werden auch Versionen in Unicode untersttzt und ber einen Unterport mit dem Suffix -unicode installiert. Dies kann aber auch ber Variablen gehandhabt werden (siehe ). Die Variablen in knnen auf einen oder mehrere (durch Leerzeichen getrennt) der folgenden Werte gesetzt werden: Spezifikationen der <application>wxWidgets</application>-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, ber die eine bevorzugte Version festgelegt werden kann. Die Versionen knnen als Liste angegeben werden, wobei die Reihenfolge der Priorisierung entspricht. Variablen zur Festlegung der bevorzugten <application>wxWidgets</application>-Version Name Bestimmt fr WANT_WX_VER den Port WITH_WX_VER den Benutzer
Komponentenauswahl Desweiteren gibt es Anwendungen, die nicht direkt wxWidgets-Bibliotheken sind, aber trotzdem mit diesen zusammenhngen. Diese Anwendungen knnen ber die Variable WX_COMPS festgelegt werden. Die folgenden Komponenten sind verfgbar: Verfgbare <application>wxWidgets</application>-Komponenten Name Beschreibung Versionsbeschrnkungen 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 Abhngigkeit kann fr jede Komponente durch hinzufgen eines Suffix (durch Strichpunkt getrennt) festgelegt werden. Falls der Typ nicht angegeben wird, wird ein Standardwert verwendet (siehe ). Die folgenden Typen sind verfgbar: Verfgbare Typen von <application>wxWidgets</application>-Abhngigkeiten Name Beschreibung build Komponente wird zum Bau bentigt – quivalent zu BUILD_DEPENDS run Komponente wird zum Ausfhren bentigt – quivalent zu RUN_DEPENDS lib Komponente wird zum Bau und Ausfhren bentigt – quivalent zu LIB_DEPENDS
Die Standardwerte fr die einzelnen Komponenten sind in der folgenden Tabelle aufgefhrt: Standardtypen der <application>wxWidgets</application>-Abhngigkeiten Komponente Typ der Abhngigkeit wx lib contrib lib python run mozilla lib svg lib
Auswahl von <application>wxWidgets</application>-Komponenten Der folgende Ausschnitt entspricht einem Port, der die wxWidgets-Version 2.4 und die zugehrigen Bibliotheken verwendet. USE_WX= 2.4 WX_COMPS= wx contrib Unicode Die wxWidgets-Bibliotheken untersttzen Unicode seit der Version 2.5. In den Ports sind beide Versionen verfgbar und knnen ber die folgenden Variablen ausgewhlt werden: Variablen, um Unicode in den <application>wxWidgets</application>-Versionen auszuwhlen Variable Beschreibung Bestimmt fr WX_UNICODE Der Port funktioniert ausschlielich mit der Unicode-Version den Port WANT_UNICODE Der Port funktioniert in beiden Versionen – bevorzugt wird jedoch Unicode den Port WITH_UNICODE Der Port verwendet die Unicode-Version den Benutzer WITHOUT_UNICODE Der Port verwendet, falls untersttzt, die normale Version (falls WX_UNICODE nicht definiert ist) den Benutzer
Die Variable WX_UNICODE darf nicht bei Ports benutzt werden, die sowohl die Version mit als auch ohne Untersttzung fr Unicode verwenden knnen. Falls der Port standardmig Untersttzung fr Unicode bieten soll, verwenden Sie WANT_UNICODE stattdessen. 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. Installierte <application>wxWidgets</application>-Versionen und –Komponenten feststellen Der folgende Ausschnitt kann in einem Port verwendet werden, der wxWidgets verwendet, falls es installiert ist, oder falls eine Option dafr ausgewhlt 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 Untersttzung fr wxPython zustzlich zu der von wxWidgets zu aktivieren (beide in Version 2.6), wenn das installiert ist, oder die Option ausgewhlt 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 Vordefinierte Variablen Die folgenden Variablen sind in den Ports verfgbar (nachdem sie entsprechend definiert wurden). Vordefinierte Variablen fr Ports, die <application>wxWidgets</application> 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) WX_UNICODE Falls Untersttzung fr Unicode nicht explizit definiert, jedoch verwendet wird, dann wird die Untersttzung automatisch aktiviert.
Verarbeitung in <filename>bsd.port.pre.mk</filename> Falls die Variablen gleich nach dem Importieren von bsd.port.pre.mk benutzt werden sollen, so muss die Variable WX_PREMK definiert werden. Falls WX_PREMK definiert ist, so werden Version, Abhngigkeiten, Komponenten und vordefinierte Variablen nicht gendert, wenn die Variablen des wxWidgets-Ports nach dem Einbinden von bsd.port.pre.mk gendert werden. Verwendung von <application>wxWidgets</application>-Variablen in Kommandos Der folgende Ausschnitt zeigt die Verwendung von WX_PREMK durch Ausfhren des wx-config-Skriptes, um die vollstndige Version als Zeichenkette zu erhalten, diese dann einer Variablen zuzuweisen und die Variable anschlieend einem Programm zu 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 Die wxWidgets-Variablen knnen problemlos in Kommandos benutzt werden, falls diese in Targets ohne gesetztes WX_PREMK verwendet werden. Weitere <command>configure</command>-Argumente Einige GNU configure-Skripte knnen wxWidgets nicht auffinden, falls nur die Umgebungsvariable WX_CONFIG gesetzt ist, sondern bentigen zustzliche Argumente. Dafr kann die Variable WX_CONF_ARGS benutzt werden. Zulssige Werte fr <varname>WX_CONF_ARGS</varname> Mglicher Wert Resultierendes Argument absolute --with-wx-config=${WX_CONFIG} relative --with-wx=${LOCALBASE} --with-wx-config=${WX_CONFIG:T}
Verwendung von <application>Lua</application> Dieser Abschnitt beschreibt den Status der Lua-Bibliotheken in den Ports und deren Einbindung in das Ports System. Einfhrung 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 gelst, indem jede Version unter einem eigenen Namen mit der Versionsnummer als Suffix installiert wird. Der offensichtliche Nachteil dabei ist, dass jede Anwendung so verndert werden muss, dass sie die erwartete Version vorfindet. Dies kann jedoch durch zustzliche Flags fr Compiler und Linker gelst werden. 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): Variablen, um die <application>Lua</application>-Version festzulegen Variable Beschreibung Standardwert USE_LUA Liste der Versionen, welche der Port verwenden kann Alle verfgbaren Versionen USE_LUA_NOT Liste der Versionen, die der Port nicht verwenden kann Nichts
Es folgt eine Liste an mglichen Lua-Versionen und deren zugehriger Port: Verfgbare <application>Lua</application>-Versionen Version Port 4.0 lang/lua4 5.0 lang/lua50 5.1 lang/lua
Die Variablen in knnen auf einen oder mehrere (durch Leerzeichen getrennt) der folgenden Werte gesetzt werden: Spezifikationen der <application>Lua</application>-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, ber die eine bevorzugte Version festgelegt werden kann. Die Versionen knnen als Liste angegeben werden, wobei die Reihenfolge der Priorisierung entspricht. Variablen zur Festlegung der bevorzugten <application>Lua</application>-Version Name Bestimmt fr WANT_LUA_VER den Port WITH_LUA_VER den Benutzer
Auswahl der <application>Lua</application>-Version Der folgende Ausschnitt entspricht einem Port, der Lua in den Versionen 5.0 oder 5.1 verwenden kann und standardmig 5.0 verwendet. Diese Einstellung kann durch die benutzerdefinierte Variable WITH_LUA_VER berschrieben werden. USE_LUA= 5.0-5.1 WANT_LUA_VER= 5.0 Komponentenauswahl Desweiteren gibt es Anwendungen, die nicht direkt Lua-Bibliotheken sind, aber trotzdem mit diesen zusammenhngen. Diese Anwendungen knnen ber die Variable LUA_COMPS festgelegt werden. Die folgenden Komponenten sind verfgbar: Verfgbare <application>Lua</application>-Komponenten Name Beschreibung Versionseinschrnkungen lua Hauptbibliothek Keine tolua Bibliothek fr die Untersttzung von C/C++-Code 4.0-5.0 ruby Ruby-Bindungen 4.0-5.0
Es gibt weitere Komponenten, die jedoch Module fr den Interpreter sind und nicht von Anwendungen benutzt werden (nur von anderen Modulen). Der Typ der Abhngigkeit kann fr jede Komponente durch Hinzufgen eines Suffix (durch Strichpunkt getrennt) festgelegt werden. Falls der Typ nicht angegeben wird, wird ein Standardwert verwendet (siehe ). Die folgenden Typen sind verfgbar: Verfgbare Typen von <application>Lua</application>-Abhngigkeiten Name Beschreibung build Komponente wird zum Bau bentigt – quivalent zu BUILD_DEPENDS run Komponente wird zum Ausfhren bentigt – quivalent zu RUN_DEPENDS lib Komponente wird zum Bau und zum Ausfhren bentigt – quivalent zu LIB_DEPENDS
Die Standardwerte fr die einzelnen Komponenten sind in der folgenden Tabelle aufgefhrt: Standardtypen fr <application>Lua</application>-Abhngigkeiten Komponente Typ der Abhngigkeit lua lib fr 4.0-5.0 (shared) und build fr 5.1 (static) tolua build (static) ruby lib (shared)
Auswahl von <application>Lua</application>-Komponenten Der folgende Ausschnitt entspricht einem Port, welcher die Lua-Version 4.0 und die zugehrigen Ruby-Bindungen verwendet. USE_LUA= 4.0 LUA_COMPS= lua ruby 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. Installierte <application>Lua</application>-Versionen und– Komponenten feststellen Der folgende Ausschnitt kann in einem Port verwendet werden, der Lua benutzt, falls es installiert ist oder eine Option dafr ausgewhlt 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 Untersttzung fr tolua zustzlich zu der von Lua zu aktivieren (beide in Version 4.0), wenn dies installiert ist oder die Option ausgewhlt 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 Vordefinierte Variablen Die folgenden Variablen sind in den Ports verfgbar (nachdem sie entsprechend definiert wurden). Vordefinierte Variablen fr Ports, die <application>Lua</application> verwenden Name Beschreibung LUA_VER Die Lua-Version, die verwendet wird (z.B. 5.1) LUA_VER_SH Die Hauptversion fr shared-Lua-Bibliotheken (z.B. 1) LUA_VER_STR Die Lua-Version ohne die Punkte (z.B. 51) LUA_PREFIX Der Prfix, unter dem Lua (und Komponenten) installiert ist LUA_SUBDIR Das Verzeichnis unter ${PREFIX}/bin, ${PREFIX}/share und ${PREFIX}/lib, in welchem Lua installiert ist LUA_INCDIR Das Verzeichnis, in dem Lua- und tolua-Header-Dateien installiert sind LUA_LIBDIR Das Verzeichnis, in dem Lua– und tolua-Bibliotheken installiert sind LUA_MODLIBDIR Das Verzeichnis, in dem Lua Modul-Bibliotheken (.so) installiert sind LUA_MODSHAREDIR Das Verzeichnis, in dem Lua-Module (.lua) installiert sind LUA_PKGNAMEPREFIX Der Paketnamen-Prfix, 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
Einem Port mitteilen, in welchem Verzeichnis <application>Lua</application> 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}" Verarbeitung in <filename>bsd.port.pre.mk</filename> Falls die Variablen gleich nach dem Einbinden von bsd.port.pre.mk benutzt werden sollen, so muss die Variable LUA_PREMK definiert werden. Falls LUA_PREMK definiert ist, so werden Version, Abhngigkeiten, Komponenten und vordefinierte Variablen nicht gendert, wenn die Variablen des Lua-Ports nach dem Einbinden von bsd.port.pre.mk gendert werden. Verwendung von <application>Lua</application>-Variablen in Kommandos Der folgende Ausschnitt zeigt die Verwendung von LUA_PREMK durch Ausfhren des Lua-Interpreters, um die vollstndige Version als Zeichenkette zu erhalten, diese dann einer Variablen zuzuweisen und die Variable schlielich einem Programm zu 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 Die Lua-Variablen knnen problemlos in Befehlen benutzt werden, falls diese in Targets ohne gesetztes LUA_PREMK verwendet werden. Xfce verwenden Die USE_XFCE-Variable wird fr die automatische Konfiguration der Abhngigkeiten 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 untersttzt: 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 zustzlichen Parameter werden untersttzt: configenv: Benutzen Sie dies, wenn Ihr Port eine speziell angepasste CONFIGURE_ENV-Variable bentigt, um seine erforderlichen Bibliotheken zu finden. -I${LOCALBASE}/include -L${LOCALBASE}/lib wird CPPFLAGS hinzugefgt und ergibt CONFIGURE_ENV. Wenn also ein Port von sysutils/xfce4-mcs-manager abhngt und die speziellen CPPFLAGS in seiner configure-Umgebung verlangt, dann wrde die Syntax wie folgt aussehen: USE_XFCE= mcsmanager configenv Mozilla verwenden Variablen fr Ports, die Mozilla verwenden USE_GECKO Vom Port untersttzte Gecko-Backends. Mgliche Werte sind: libxul (libxul.so), seamonkey (libgtkembedmoz.so, (veraltet, sollte daher nicht mehr verwendet werden). USE_FIREFOX Der Port bentigt Firefox, um korrekt zu funktionieren. Mgliche Werte sind: yes (verwendet die Standardversion), 40, 36, 35. Die Standardversion ist derzeit 40. USE_FIREFOX_BUILD Um den Port zu bauen, muss Firefox installiert sein. Wird diese Variable gesetzt, wird automatisch auch USE_FIREFOX gesetzt. USE_SEAMONKEY Der Port bentigt Seamonkey, um korrekt zu funktionieren. Mgliche Werte sind: yes (verwendet die Standardversion), 20, 11 (veraltet, sollte daher nicht mehr verwendet werden). Die Standardversion ist 20. USE_SEAMONKEY_BUILD Um den Port zu bauen, muss Seamonkey installiert sein. Wird diese Variable gesetzt, wird automatisch auch USE_SEAMONKEY gesetzt. USE_THUNDERBIRD Dieser Port bentigt Thunderbird, um korrekt zu funktionieren. Mgliche Werte sind: yes (verwendet die Standardversion), 31, 30 (veraltet, sollte daher nicht mehr verwendet werden). Die Standardversion ist 31. USE_THUNDERBIRD_BUILD Um den Port zu bauen, muss Thunderbird installiert sein. Wird diese Variable gesetzt, wird automatisch auch USE_THUNDERBIRD gesetzt.
Eine komplette Liste aller verfgbaren Variablen finden Sie in der Datei /usr/ports/Mk/bsd.gecko.mk. Benutzung von Datenbanken Variablen fr Ports, die Datenbanken benutzen Variable Bedeutung USE_BDB Falls die Variable auf yes gesetzt ist, fge eine Abhngigkeit von databases/db41 hinzu. Die Variable kann auch folgende Werte annehmen: 40, 41, 42, 43, 44, 46, 47, 48 oder 51. Sie knnen eine Folge akzeptierter Werte angeben - USE_BDB=42+ stellt die hchste installierte Version fest und greift auf 42 zurck, falls sonst nichts installiert ist. USE_MYSQL Falls die Variable auf yes gesetzt ist, fge databases/mysql55-server als Abhngigkeit hinzu. Die damit verknpfte Variable WANT_MYSQL_VER kann Werte wie 323, 40, 41, 50, 51, 52, 55, oder 60 annehmen. USE_PGSQL Falls die Variable auf yes gesetzt ist, fge eine Abhngigkeit von databases/postgresql84 hinzu. Die damit verknpfte 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. Starten und Anhalten von Diensten (rc Skripten) rc.d-Skripten werden zum Starten von Diensten whrend 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 knnen im rc.d Kapitel des Handbuchs nachgelesen werden. Ausfhrliche Beschreibungen der verfgbaren Befehle stehen in &man.rc.8; und &man.rc.subr.8;. Desweiteren gibt es einen Artikel zu praktischen Aspekten bezglich rc.d-Skripten. Ein oder mehrere rc.d-Skripten knnen installiert werden mittels: USE_RC_SUBR= doormand Skripten mssen im Unterverzeichnis files abgelegt und jeder Skript-Datei muss ein .in-Suffix hinzugefgt werden. Standardmige SUB_LIST-Ersetzungen werden fr diese Dateien untersttzt. Die Verwendung von %%PREFIX%% und %%LOCALBASE%% wird dringend empfohlen. Nheres zu SUB_LIST kann im zugehrigen Kapitel nachgelesen werden. Fr &os;-Versionen, die lter als 6.1-RELEASE sind, ist die Integration mittels &man.rcorder.8; mglich, 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 &os; 6.1-RELEASE sind lokale rc.d-Skripten (inklusive der durch Ports installierten) im allgemeinen &man.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 dafr besteht, einen Dienst frher starten zu lassen, sollten alle Ports-Skripten REQUIRE: LOGIN verwenden. Falls der Port von einem bestimmten Benutzer (auer root) ausgefhrt 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, wre dies nicht notwendig. Fr 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 ":=" wrde in diesem Fall die Benutzerdefinition berschreiben. Es sollten keine weiteren Skripten mit der .sh-Endung hinzugefgt werden. Irgendwann wird es ein Massenumbenennen aller Skripten im Repository geben, die immer noch diese Endung haben. Anhalten und Deinstallieren von Diensten Es ist mglich, dass ein Dienst whrend 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 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 zugefgt werden: @stopdaemon doormand Das Argument muss dabei mit dem Inhalt der USE_RC_SUBR-Variablen bereinstimmen. Hinzufgen von Benutzern und Gruppen Manche Ports setzen voraus, dass ein bestimmter Benutzer auf dem System angelegt ist. Whlen Sie in einem solchen Fall eine freie Kennnummer zwischen 50 und 999 aus und tragen Sie diese in ports/UIDs (fr Benutzer) oder ports/GIDs (fr Gruppen) ein. Stellen Sie dabei sicher, dass Sie keine Kennnummer auswhlen, die bereits vom System oder von anderen Ports verwendet wird. Erstellen Sie bitte eine entsprechende Patch-Datei fr diese beiden Dateien, wenn fr Ihren Port ein neuer Benutzer oder eine neue Gruppe angelegt werden muss. Sie knnen 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). Von Kernelquellen abhngige Ports Einige Ports (beispielsweise vom Kernel ladbare Module) bentigen die Kernelsourcen, damit sie gebaut werden knnen. Die folgenden Zeilen beschreiben den korrekten Weg, wie Sie feststellen knnen, ob der Benutzer die Kernelsourcen installiert hat: .if !exists(${SRC_BASE}/sys/Makefile) IGNORE= requires kernel sources to be installed .endif Fortgeschrittene <filename>pkg-plist</filename>-Methoden nderungen an <filename>pkg-plist</filename> mit Hilfe von make-Variablen Einige Ports, insbesondere die p5--Ports, mssen, abhngig von ihren Konfigurationsoptionen (oder im Falle der p5-Ports von der perl-Version), die pkg-plist verndern. Um dies zu vereinfachen, werden fr 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 vollstndige Versionsnummer von perl (z.B. 5.8.9) an. Weitere, die Dokumentationsdateien des Ports betreffende %%VARS%%, werden im entsprechenden Abschnitt erlutert. Falls Sie weitere Ersetzungen von Variablen durchfhren mssen, knnen 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 knnen Sie etwas wie OCTAVE_VERSION= 2.0.13 PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION} in das Makefile schreiben und %%OCTAVE_VERSION%% verwenden, unabhngig davon, wo die Variable in pkg-plist verwendet wird. In diesem Fall mssen Sie bei einem Upgrade des Ports nicht dutzende (oder manchmal sogar hunderte) Zeilen in pkg-plist anpassen. Falls Ihr Port in Abhngigkeit von den ausgewhlten Optionen Dateien installiert, ist es 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 hinzugefgt wird, der die Paket-Werkzeuge die Zeile ignorieren lsst: .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 Hinzufgen weiterer Manualpages) wird zwischen den pre-install- und do-install-Targets ausgefhrt, indem aus PLIST gelesen und in TMPPLIST geschrieben wird (Standard: WRKDIR/.PLIST.mktmp). Falls Ihr Port also PLIST whrend dem Erstellen generiert, so sollte dies vor oder in pre-install geschehen. Muss Ihr Port die resultierende Datei verndern, so sollte dies in post-install mit der Ausgabedatei TMPPLIST erfolgen. Eine weitere Mglichkeit, die Paketliste eines Ports zu verndern, 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 unverndert in die endgltige Paketliste bernommen, whrend den Namen aus PLIST_DIRS noch der Wert von @dirrm vorangestellt wird. Damit die Verwendung von PLIST_FILES und PLIST_DIRS berhaupt mglich ist, mssen diese gesetzt werden, bevor TMPPLIST geschrieben wird – z.B. in pre-install oder vorher. Leere Verzeichnisse Aufrumen leerer Verzeichnisse Bitte sorgen Sie dafr, dass ihre Ports bei der Deinstallation leere Verzeichnisse lschen. Dazu wird fr jedes Verzeichnis, das der Port erzeugt hat, eine @dirrm-Zeile angegeben. Um ein Verzeichnis zu lschen mssen 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 knnen Sie @dirrmtry verwenden, um nur Verzeichnisse zu lschen, die wirklich leer sind, und damit Warnhinweise vermeiden. @dirrmtry share/doc/gimp Dadurch wird es weder eine Fehlermeldung geben noch wird &man.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. Erstellen leerer Verzeichnisse Um leere Verzeichnisse whrend 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 &man.pkg.add.1; nur die Verzeichnisse erstellt, die dafr bentigt werden. Um sicher zu gehen, dass das leere Verzeichnis erstellt wird, wenn ein Paket installiert wird, muss die folgende Zeile in pkg-plist ber der entsprechenden @dirrm Zeile eingetragen werden: @exec mkdir -p %D/share/foo/templates Konfigurationsdateien Sollte Ihr Port Konfigurationsdateien in PREFIX/etc bentigen, so sollten Sie diese nicht einfach installieren und in pkg-plist auflisten. Dies wrde &man.pkg.delete.1; veranlassen, diese Dateien zu lschen, 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 gelscht werden, aber nur, wenn sie nicht vom Benutzer verndert wurde. Das alles muss sowohl im Makefile des Ports als auch in der pkg-plist (fr 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 knnen 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 ausgefhrt werden kann. 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, verfgbar 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 mglich ist den Dateiinhalt zu betrachten ohne ein Distfile Herunterladen oder Kompilieren zu mssen. Eine dynamische Paketliste ist eine Paketliste, die beim Kompilieren des Ports erstellt wird, abhngig davon, welche Dateien und Verzeichnisse installiert werden. Es ist nicht mglich diese Liste zu betrachten, bevor der Quelltext heruntergeladen und kompiliert oder nachdem ein make clean ausgefhrt wurde. Der Einsatz dynamischer Paketlisten ist zwar nicht untersagt, aber Sie sollten, wann immer das mglich ist, statische Paketlisten verwenden, da die Nutzer dann &man.grep.1; auf alle verfgbaren Ports anwenden knnen, um z.B. herauszufinden, von welchem eine bestimmte Datei installiert wurde. Dynamische Paketlisten sollten fr komplexe Ports verwendet werden, bei denen sich die Liste abhngig von den gewhlten Funktionen sehr stark ndern kann (wodurch die Pflege von statischen Listen unmglich wird), oder Ports, welche die Paketliste abhngig von den Versionen verwendeter Abhngigkeiten verndern (z.B. Ports, die Ihre Dokumentation mit Javadoc erzeugen). Maintainer, die dynamische Paketlisten bevorzugen, werden dazu aufgefordert, neue Targets zu Ihren Ports hinzuzufgen, welche die pkg-plist-Datei erzeugen, sodass Benutzer den Inhalt berprfen knnen. Automatisiertes Erstellen von Paketlisten Als Erstes sollten Sie sich vergewissern, dass der Port bis auf pkg-plist vollstndig ist. Als Nchstes erstellen Sie einen temporren Verzeichnisbaum, in welchem Ihr Port installiert werden kann, und installieren Sie alle Abhngigkeiten. &prompt.root; mkdir /var/tmp/`make -V PORTNAME` &prompt.root; mtree -U -f `make -V MTREE_FILE` -d -e -p /var/tmp/`make -V PORTNAME` &prompt.root; make depends PREFIX=/var/tmp/`make -V PORTNAME` Speichern Sie die Verzeichnisstruktur in einer neuen Datei. &prompt.root; (cd /var/tmp/`make -V PORTNAME` && find -d * -type d) | sort > OLD-DIRS Erstellen Sie eine leere pkg-plist-Datei: &prompt.root; :>pkg-plist Wenn Ihr Port auf PREFIX achtet (was er machen sollte), so kann der Port nun installiert und die Paketliste erstellt werden. &prompt.root; make install PREFIX=/var/tmp/`make -V PORTNAME` &prompt.root; (cd /var/tmp/`make -V PORTNAME` && find -d * \! -type d) | sort > pkg-plist Sie mssen auch alle neu erstellten Verzeichnisse in die Paketliste aufnehmen. &prompt.root; (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 aufgerumt werden - es funktioniert eben nicht alles automatisch. Manualpages sollten im Makefile des Ports unter MANn aufgefhrt sein und nicht in der Paketliste. Konfigurationsdateien des Benutzers sollten entfernt oder als filename.sample installiert werden. Die info/dir-Datei sollte nicht aufgefhrt sein und die zugehrigen install-info-Zeilen sollten hinzugefgt 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 knnen 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 Abstzen 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: &prompt.root; make install PREFIX=/var/tmp/`make -V PORTNAME` Und lassen Sie plist die pkg-plist-Datei erstellen: &prompt.root; /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 aufgerumt werden, wie es oben erklrt 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 berprft und bei Bedarf von Hand nachbearbeitet werden. Die <filename>pkg-*</filename> Dateien Es gibt noch einige Tricks mit pkg-*, die wir noch nicht erwhnt haben, die aber oft sehr praktisch sind. <filename>pkg-message</filename> Wenn Sie dem Anwender bei der Installation weitere Informationen anzeigen wollen, so knnen Sie diese Nachricht in pkg-message speichern. Diese Vorgehensweise ist oft ntzlich, um zustzliche Schritte anzuzeigen, die nach &man.pkg.add.1; durchgefhrt werden mssen. Dadurch knnen Sie auch Lizenzinformationen darstellen. Wollen Sie nur ein paar Zeilen ber die Einstellungen zum Erstellen des Ports oder Warnungen ausgeben, benutzen Sie ECHO_MSG. pkg-message ist nur fr 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, whrend Letzteres fr Kommando-Pipelining bestimmt ist. Ein gutes Beispiel fr 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 Die pkg-message wird nicht zur pkg-plist hinzugefgt. Sie wird auch nicht automatisch angezeigt, falls ein Anwender den Port installiert. Sie mssen also die Ausgabe selbst im post-install-Ziel des Make-Vorgangs veranlassen. <filename>pkg-install</filename> Sollte es ntig sein, dass Ihr Port bei der Installation des Binrpakets mit &man.pkg.add.1; Befehle ausfhrt, knnen Sie das Skript pkg-install benutzen. Dieses Skript wird automatisch dem Paket hinzugefgt und zweimal von &man.pkg.add.1; ausgefhrt: 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 ausgefhrt wird. Die Umgebungsvariable PKG_PREFIX wird auf das Verzeichnis gesetzt, in welches das Paket installiert wird. Siehe &man.pkg.add.1; fr weiterfhrende Informationen. Das Skript wird nicht automatisch ausgefhrt, wenn Sie den Port mit make install installieren. Wenn Sie es ausfhren lassen wollen, dann mssen Sie es im Makefile aufrufen: PKG_PREFIX=${PREFIX} ${SH} ${PKGINSTALL} ${PKGNAME} PRE-INSTALL. <filename>pkg-deinstall</filename> Dieses Skript wird ausgefhrt, wenn ein Paket deinstalliert wird. Es wird zweimal von &man.pkg.delete.1; aufgerufen. Das erste Mal als ${SH} pkg-deinstall ${PKGNAME} DEINSTALL und dann als ${SH} pkg-deinstall ${PKGNAME} POST-DEINSTALL. <filename>pkg-req</filename> Muss Ihr Port entscheiden, ob er installiert werden soll oder nicht, knnen 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 whrend der Installation von &man.pkg.add.1; als pkg-req ${PKGNAME} INSTALL aufgerufen. Bei der Deinstallation wird es von &man.pkg.delete.1; als pkg-req ${PKGNAME} DEINSTALL ausgefhrt. ndern der Namen der <filename>pkg-*</filename> Dateien Alle Namen der pkg-* Dateien werden durch Variablen festgelegt. Sie knnen sie bei Bedarf also im Makefile des Ports ndern. Das ist besonders ntzlich, wenn Sie die gleichen pkg-* Dateien in mehreren Ports nutzen oder in eine der oben genannten Dateien schreiben wollen. Schreiben Sie niemals auerhalb des Unterverzeichnisses WRKDIR pkg-*, eine Erklrung hierzu finden Sie in Schreiben ausserhalb von WRKDIR. Hier ist eine Liste von Variablennamen und ihren Standardwerten (PKGDIR ist standardmig ${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 ndern. Wenn Sie PKG_ARGS modifizieren, werden diese Dateien bei der Installation des Ports nicht korrekt in /var/db/pkg installiert. Nutzung von <varname>SUB_FILES</varname> und <varname>SUB_LIST</varname> Die Variablen SUB_FILES und SUB_LIST sind ntzlich, um dynamische Werte in Port-Dateien zu verwenden, wie beispielsweise der Installations-PREFIX in pkg-message. Die Variable SUB_FILES enthlt eine Liste von Dateien, die automatisch verndert 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 hinzugefgt. Fr die Dateien pkg-message, pkg-install, pkg-deinstall und pkg-req werden die jeweiligen Makefile-Variablen selbstttig auf die genderte 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 gebruchliche 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 gelscht. 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 fr 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. Ihren Port testen <command>make describe</command> ausfhren Einige der &os;-Werkzeuge zur Pflege von Ports, wie zum Beispiel &man.portupgrade.1;, verwenden eine Datenbank names /usr/ports/INDEX, welche Eigenschaften, wie z.B. Port-Abhngigkeiten, verfolgt. INDEX wird vom Makefile der hchsten Ebene, ports/Makefile, mittels make index erstellt, welches in das Unterverzeichnis jedes Ports wechselt und dort make describe ausfhrt. Wenn also make describe bei einem Port fehlschlgt, kann INDEX nicht generiert werden und schnell werden viele Leute darber unzufrieden sein. Es ist wichtig diese Datei erzeugen zu knnen, unabhngig davon, welche Optionen in make.conf vorhanden sind. Bitte vermeiden Sie es daher beispielsweise .error-Anweisungen zu benutzen, wenn zum Beispiel eine Abhngigkeit nicht erfllt wird (Lesen Sie dazu bitte ). 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 ber deren Bedeutung zu erfahren. Beachten Sie bitte auerdem, dass die Benutzung einer aktuellen Version von portlint (wie im nchsten Abschnitt beschrieben) automatisch make describe startet. Portlint Bitte berprfen Sie Ihre Arbeit stets mit portlint, bevor Sie diese einreichen oder committen. portlint warnt Sie bei hufigen Fehlern, sowohl funktionaler als auch stilistischer Natur. Fr einen neuen (oder repokopierten) Port ist portlint -A die grndlichste Variante; fr einen bereits existierenden Port ist portlint -C ausreichend. Da portlint heuristische Methoden zur Fehlersuche benutzt, kann es vorkommen, dass Warnungen fr Fehler erzeugt werden, die keine sind. Gelegentlich kann etwas, das als Problem angezeigt wird, aufgrund von Einschrnkungen im Port-System nicht anders gelst werden. Wenn es Zweifel gibt, fragen Sie am besten auf &a.ports; nach. 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, knnen Sie port test verwenden, damit die Tests, inklusive der portlint-berprfung, durchgefhrt werden. Dieser Befehl sprt ausserdem alle nicht in pkg-plist enthaltenen Dateien auf und gibt eine Liste dieser aus. Hier ein Beispiel: &prompt.root; port test /usr/ports/net/csup <varname>PREFIX</varname> und <varname>DESTDIR</varname> 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 / eingehngt ist). Ein Port wird unter DESTDIR/PREFIX installiert und registriert sich in der Paket-Datenbank unter DESTDIR/var/db/pkg. Da DESTDIR mittels eines &man.chroot.8;-Aufrufs vom Ports-System automatisch gesetzt wird, brauchen Sie keine nderungen oder besondere Pflege fr 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 erfllen. Fr X-Ports, die imake benutzen, geschieht dies automatisch; andernfalls kann dies erreicht werden, indem alle Angaben von /usr/local (oder /usr/X11R6 fr 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 bergeben wird. Vergewissern Sie sich bitte, dass Ihre Anwendung nichts unter /usr/local an Stelle von PREFIX installiert. Um dies festzustellen, knnen Sie folgendes machen: &prompt.root; make clean; make package PREFIX=/var/tmp/`make -V PORTNAME` Wenn etwas auerhalb von PREFIX installiert wird, so gibt der Prozess der Paketerstellung eine Meldung aus, dass es die Dateien nicht finden kann. Dies prft nicht das Vorhandensein eines internen Verweises oder die richtige Verwendung von LOCALBASE fr Verweise auf Dateien anderer Ports. Das Testen der Installation in /var/tmp/`make -V PORTNAME` wrde dies erledigen. Die Variable PREFIX kann in Ihrem Makefile oder der Umgebung des Benutzers neu gesetzt werden. Allerdings wird fr einzelne Ports dringend davon abgeraten diese Variable in den Makefiles direkt zu setzen. Verweisen Sie bitte auerdem auf Programme/Dateien von anderen Ports durch die oben erwhnten Variablen und nicht mit den eindeutigen Pfadnamen. Wenn Ihr Port zum Beispiel vom Makro PAGER erwartet, dass es den vollstndigen Pfadnamen von less enthlt, benutzen Sie folgendes Compiler-Flag: -DPAGER=\"${LOCALBASE}/bin/less\" anstatt -DPAGER=\"/usr/local/bin/less\". Somit ist die Wahrscheinlichkeit hher, dass es auch funktioniert, wenn der Administrator den ganzen /usr/local-Baum an eine andere Stelle verschoben hat. Die Tinderbox Wenn Sie ein begeisterter Ports-Entwickler sind mchten 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 knnen Tinderbox installieren, indem Sie den Port ports-mgmt/tinderbox benutzen. Bitte lesen Sie die mitgelieferte Dokumentation grndlich, da die Konfiguration nicht einfach ist. Um Nheres darber zu erfahren, besuchen Sie bitte die Tinderbox Homepage. 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 zustzlich den Vorteil, dass Sie so auch alle Abhngigkeiten des Ports aktuell halten. Der nchste Schritt besteht darin festzustellen, ob bereits eine Aktualisierung des Ports darauf wartet committet zu werden. Um das sicherzustellen haben Sie folgende Mglichkeiten. Es gibt eine durchsuchbare Schnittstelle zur FreeBSD Problembericht Datenbank (PR - Problem Report) (auch bekannt als GNATS). Whlen Sie dazu Ports im Drop-Down-Men und geben Sie den Namen des Ports ein. Allerdings wird manchmal vergessen den Namen des Ports eindeutig im Feld fr die Zusammenfassung anzugeben. In diesem Fall knnen 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 knnen Sie die bersicht eines Ports verwenden. Wenn es keine wartenden PRs gibt, ist der nchste 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 Stabilittsproblemen der neuen Version). Sie wollen sicher nicht die Arbeit des Maintainers doppelt machen. Beachten Sie bitte, dass fr Ports ohne Maintainer ports@FreeBSD.org eingetragen ist. Das ist nur die allgemeine &a.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 &man.diff.1;, das bereits im Basissystem enthalten ist. Um einen brauchbaren diff fr einen einzelne Datei zu erstellen, kopieren Sie die zu patchende Datei nach dateiname.orig und speichern Ihre nderungen in die Datei dateiname. Danach erzeugen Sie den Patch: &prompt.user; /usr/bin/diff dateiname.orig dateiname > dateiname.diff Soll mehr als eine Datei gepatcht werden, knnen Sie entweder cvs diff verwenden (siehe dazu ) oder Sie kopieren den kompletten Port in ein neues Verzeichnis und speichern die Ausgabe des rekursiven &man.diff.1; auf das neue und alte Portverzeichniss (wenn Ihr verndertes Portverzeichnis z.B. superedit und das Original superedit.bak heit, dann speichern Sie bitte die Ergebnisse von diff -ruN superedit.bak superedit). Sowohl vereinheitlichendes als auch kontextabhngiges 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 gebruchliche Weg diff dazu zu bewegen korrekt damit umzugehen, neue Dateien anzulegen und alte zu lschen. Bevor Sie das diff einsenden berprfen Sie bitte die Ausgabe, um sicherzugehen, dass die nderungen sinnvoll sind. Stellen Sie insbesondere sicher, dass Sie das Arbeitsverzeichnis mit make clean aufgert haben). Um gngige Operationen mit Korrekturdateien zu vereinfachen, knnen 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 Erwgung sich als Maintainer zu melden. &os; hat mehr als 4000 Ports ohne Maintainer und in diesem Bereich werden immer zustzliche Freiwillige bentigt (Fr eine ausfhrliche Beschreibung der Verantwortlichkeiten eines Maintainers lesen Sie bitte im Developer's Handbook nach). Der beste Weg uns das diff zu schicken ist mittels &man.send-pr.1; (Kategorie Ports). Wenn Sie der Maintainer des Ports sind, fgen 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 erwhnen Sie alle hinzugefgten oder gelschten Dateien in der Nachricht, da diese beim Commit ausdrcklich an &man.cvs.1; bergeben werden mssen. Wenn das diff grer ist als 20 Kilobyte komprimieren und uuencoden Sie es bitte. Ansonsten knnen Sie es in den PR einfgen wie es ist. Bevor Sie den PR mit &man.send-pr.1; abschicken, sollten Sie den Abschnitt Den Problembericht schreiben im Artikel ber Problemberichte lesen. Dieser enthlt sehr viel mehr Informationen darber, wie man ntzliche Problemberichte verfasst. Wenn Sie Ihre Aktualisierung aufgrund von Sicherheitsbedenken oder eines schwerwiegenden Fehlers bereitstellen wollen, informieren Sie bitte das &a.portmgr;, um einen sofortigen Rebuild und eine Neuverteilung des Pakets Ihres Ports durchzufhren. Sonst werden ahnungslose Nutzer von &man.pkg.add.1; ber mehrere Wochen die alte Version durch pkg_add -r installieren. Noch einmal: Bitte verwenden Sie &man.diff.1; und nicht &man.shar.1;, um Aktualisierungen existierender Ports zu senden. Sie erleichtern es damit den Ports-Committern, Ihre nderungen nachzuvollziehen. Nun, da Sie all das geschafft haben, knnen Sie in nachlesen, wie Sie den Port aktuell halten. Patches mit CVS erstellen Wenn mglich, sollten Sie stets eine &man.cvs.1;-Differenz einreichen. Diese sind leichter zu bearbeiten als Differenzen zwischen neuen und alten Verzeichnissen. Auerdem knenn Sie so einfacher feststellen, welche nderungen Sie vorgenommen haben oder Ihren Patch modifizieren, falls dies durch nderungen in einem anderen Bereich der Ports-Sammlung notwendig wird oder Sie vom Committer um eine Korrektur Ihres Patches gebeten werden. &prompt.user; cd ~/my_wrkdir &prompt.user; cvs -d R_CVSROOT co pdnsd &prompt.user; cd ~/my_wrkdir/pdnsd Das Verzeichnis, in dem Sie den Port bauen wollen. Dieses Arbeitsverzeichnis kann sich auch auerhalb von /usr/ports/ befinden. R_CVSROOT steht fr einen ffentlichen CVS-Server. Eine Liste aller verfgbaren Server finden Sie im &os; Handbuch. 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 fr den Port german/selfhtml de-selfhtml). Um den Namen des Moduls herauszufinden, knnen Sie entweder die cvsweb-Schnittstelle verwenden oder den kompletten Pfad des Ports angeben (in unserem Beispiel wre der komplette Pfad also ports/dns/pdnsd). Danach modifizieren Sie den Port in gewohnter Weise. Falls Sie Dateien hinzufgen oder entfernen, sollten Sie dies mit cvs protokollieren: &prompt.user; cvs add new_file &prompt.user; cvs remove deleted_file berprfen Sie die Funktion Ihres Ports anhand der Checklisten in und . &prompt.user; cvs status &prompt.user; cvs update Dadurch wird versucht, die Differenz zwischen Ihrer genderten 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 vollstndige Liste dieser Prfixe finden Sie in . Von cvs update verwendete Prfixe U Die Datei wurde aktualisiert. Es traten dabei keine Probleme auf. P Die Datei wurde ohne Probleme aktualisiert (dieses Prfix wird nur verwendet, wenn Sie mit einem entfernten Repository arbeiten). M Die Datei wurde modifiziert. Es traten keine Konflikte auf. C Die Datei wurde modifiziert, allerdings kam es dabei zu Konflikten zwischen Ihrer genderten Version und der aktuellen Version im CVS.
Wird das Prfix C nach einem cvs update angezeigt, bedeutet dies, dass im CVS etwas gendert wurde und &man.cvs.1; daher nicht in der Lage war, Ihre nderungen und die nderungen im CVS zu kombinieren. Es ist immer sinnvoll, sich die nderungen anzusehen, da cvs keine Informationen darber hat, wie ein Port aufgebaut sein soll. Es kann (und wird wahrscheinlich) daher vorkommen, dass sich manchmal nderungen ergeben, die keinen Sinn machen. Im letzten Schritt erzeugen Sie einen unified &man.diff.1; gegen die derzeit im CVS vorhandenen Dateien: &prompt.user; cvs diff -uN > ../`basename ${PWD}`.diff Verwenden Sie unbedingt die Option , um sicherzustellen, dass von hinzugefgte oder gelschte Dateien im Patch erfasst sind. Der Patch entht auch von Ihnen gelschte 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 folgen. Die Dateien UPDATING und MOVED Wenn die Aktualisierung des Ports spezielle Schritte wie die Anpassung von Konfigurationsdateien oder die Ausfhrung eines speziellen Programms erfordert, sollten Sie diesen Umstand in der Datei /usr/ports/UPDATING dokumentieren. Eintrge 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 einfgen wollen, stellen Sie bitte sicher, dass alle Sonderzeichen korrekt dargestellt werden. Wurde der Port gelscht oder umbenannt, sollten Sie dies in der Datei /usr/ports/MOVED vermerken. Eintrge in dieser Datei haben das folgende Format: old name|new name (blank for deleted)|date of move|reason Sicherheit der Ports Warum Sicherheit so wichtig ist Es finden sich immer wieder Fehler in Software. Die gefhrlichsten davon sind wohl jene, die Sicherheitslcken ffnen. Technisch gesehen mssen diese Lcken geschlossen werden, indem die Fehler, die Sie verursacht haben, beseitigt werden. Aber die Vorgehensweisen, wie mit bloen Fehlern und Sicherheitslcken umgegangen wird, sind sehr unterschiedlich. Ein typischer kleiner Fehler betrifft nur Nutzer, die eine bestimmte Kombination von Optionen aktiviert haben, die den Fehler auslst. Der Entwickler wird letztendlich einen Patch herausgeben, gefolgt von einer neuen Version des Programms, die den Fehler nicht mehr enthlt – jedoch wird die Mehrheit der Nutzer nicht sofort aktualisieren, da sie von diesem Fehler nicht betroffen sind. Ein kritischer Fehler, der zu Datenverlust fhren 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 Sicherheitslcke ist dies ganz anders. Erstens wird sie vielleicht jahrelang nicht entdeckt, da dies oftmals keine Fehlfunktion im Programm verursacht. Zweitens kann eine bswillige Person unerlaubten Zugriff auf ein unsicheres System erlangen, um empfindliche Daten zu verndern oder zu zerstren; 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 gefhrdet wre. Deshalb reicht es nicht aus eine Sicherheitslcke nur zu schlieen: Die Zielgruppe sollte mglichst genau und umfassend darber informiert werden, damit sie die Gefahr einschtzen und passende Manahmen ergreifen knnen. Sicherheitslcken schliessen Bei Ports und Paketen kann eine Sicherheitslcke im ursprnglichen Programm oder in den Port-Dateien verursacht werden. Im ersten Fall wird der ursprngliche Entwickler den Fehler wahrscheinlich umgehend korrigieren oder eine neue Version herausgeben und Sie mssen den Port nur aktualisieren und die Korrekturen des Autors beachten. Falls sich die Korrektur aus irgendeinem Grund verzgert, sollten Sie den Port als FORBIDDEN markieren oder selbst den Fehler fr den Port korrigieren. Falls die Sicherheitslcke im Port verursacht wird, sollten Sie ihn sobald wie mglich berichtigen. In jedem Fall sollte die Standardvorgehensweise zum Einreichen von nderungen beachtet werden – es sei denn, Sie haben das Recht diese direkt in den Ports-Baum zu committen. Ports-Committer zu sein ist nicht genug, um nderungen an einem beliebigen Port zu committen. Bitte denken Sie daran, dass Ports blicherweise Maintainer haben, die Sie respektieren sollten. Bitte stellen Sie sicher, dass die Revision des Ports erhht wird, sobald die Sicherheitslcke geschlossen wurde. Dadurch sehen die Nutzer, die installierte Pakete regelmig aktualisieren, dass es an der Zeit ist eine Aktualisierung durchzufhren. Auerdem wird ein neues Paket gebaut, ber FTP– und WWW-Spiegel verteilt und die unsichere Version damit verdrngt. PORTREVISION sollte erhht werden – es sei denn, PORTREVISION hat sich im Laufe der Korrektur des Fehlers gendert. Das heit, Sie sollten PORTREVISION erhhen, wenn Sie eine Korrektur hinzugefgt haben. Sie sollten diese aber nicht erhhen, wenn Sie den Port auf die neueste Version des Programms gebracht haben und PORTREVISION somit schon verndert wurde. Bitte beachten Sie den betreffenden Abschnitt fr weitere Informationen. Die Community informiert halten Die VuXML-Datenbank Ein sehr wichtiger und dringender Schritt, den man unternehmen muss, sobald eine Sicherheitslcke entdeckt wurde, ist die Gemeinschaft der Anwender des Ports ber die Gefahr zu informieren. Diese Benachrichtigung hat zwei Grnde. Erstens wird es sinnvoll sein, wenn die Gefahr wirklich so gro ist, sofort Abhilfe zu schaffen, indem man z.B. den betreffenden Netzwerkdienst beendet oder den Port komplett deinstalliert, bis die Lcke 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 verfgbar ist, sofort aktualisieren mssen. Angesichts der riesigen Zahl an Ports kann nicht fr jeden Vorfall ein Sicherheitshinweis erstellt werden, ohne durch die Flut an Nachrichten die Aufmerksamkeit der Empfnger zu verlieren, im Laufe der Zeit kommt es so zu ernsten Problemen. Deshalb werden Sicherheitslcken von Ports in der FreeBSD VuXML-Datenbank aufgezeichnet. Das Team der Sicherheitsverantwortlichen beobachtet diese wegen Angelegenheiten, die Ihr Eingreifen erfordern. Wenn Sie Committerrechte haben, knnen Sie die VuXML-Datenbank selbst aktualisieren. Auf diese Weise helfen Sie den Sicherheitsverantwortlichen und liefern die kritischen Informationen frhzeitig an die Community. Aber auch wenn Sie kein Committer sind und glauben, Sie haben eine auergewhnlich schwerwiegende Lcke gefunden – egal welche – zgern 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 knnen Sie im Port security/vuxml finden. Deshalb wird der komplette Pfadname PORTSDIR/security/vuxml/vuln.xml lauten. Jedes Mal, wenn Sie eine Sicherheitslcke in einem Port entdecken, fgen Sie bitte einen Eintrag dafr in diese Datei ein. Solange Sie nicht mit VuXML vertraut sind, ist es das Beste, was Sie machen knnen, einen vorhandenen Eintrag, der zu Ihrem Fall passt, zu kopieren und als Vorlage zu verwenden. Eine kurze Einfhrung in VuXML Das komplette XML ist komplex und wrde den Rahmen dieses Buches sprengen. Allerdings bentigen Sie fr 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 ffnenden <Tag> muss ein passendes </Tag> existieren. Tags knnen geschachtelt werden. Wenn sie geschachtelt werden mssen die inneren Tags vor den ueren geschlossen werden. Es gibt eine Hierarchie von Tags – das heit komplexere Regeln zur Schachtelung. Klingt so hnlich wie HTML, oder? Der grte Unterschied ist: XML ist erweiterbar (eXtensible) – das heit es basiert darauf mageschneiderte Tags zu definieren. Aufgrund seiner wesentlichen Struktur bringt XML ansonsten formlose Daten in eine bestimmte Form. VuXML ist speziell darauf zugeschnitten Beschreibungen von Sicherheitslcken zu verwalten. Lassen Sie uns nun einen realistischen VuXML-Eintrag betrachten: <vuln vid="f4bc80f4-da62-11d8-90ea-0004ac98a7b9"> <topic>Several vulnerabilities found in Foo</topic> <affects> <package> <name>foo</name> <name>foo-devel</name> <name>ja-foo</name> <range><ge>1.6</ge><lt>1.9</lt></range> <range><ge>2.*</ge><lt>2.4_1</lt></range> <range><eq>3.0b1</eq></range> </package> <package> <name>openfoo</name> <range><lt>1.10_7</lt></range> <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> <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> <freebsdsa>SA-10:75.foo</freebsdsa> <freebsdpr>ports/987654</freebsdpr> <cvename>CAN-2010-0201</cvename> <cvename>CAN-2010-0466</cvename> <bid>96298</bid> <certsa>CA-2010-99</certsa> <certvu>740169</certvu> <uscertsa>SA10-99A</uscertsa> <uscertta>SA10-99A</uscertta> <mlist msgid="201075606@hacker.com">http://marc.theaimsgroup.com/?l=bugtraq&amp;m=203886607825605</mlist> <url>http://j.r.hacker.com/advisories/1</url> </references> <dates> <discovery>2010-05-25</discovery> <entry>2010-07-13</entry> <modified>2010-09-17</modified> </dates> </vuln> Die Namen der Tags sollten selbsterklrend sein  – also werfen wir einen genaueren Blick auf die Felder, die Sie selbst ausfllen mssen: Dies ist die hchste Tag-Ebene eines VuXML-Eintrags. Es ist ein vorgeschriebenes Attribut vid, welches eine allgemein einzigartige Kennung (universally unique identifier, UUID) in Anfhrungszeichen fr diesen Eintrag festlegt. Sie sollten eine UUID fr 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 knnen &man.uuidgen.1; verwenden, um eine VuXML UUID zu erzeugen. Dies ist eine einzeilige Beschreibung des gefundenen Fehlers. Hier werden die Namen betroffener Pakete aufgefhrt. Es knnen mehrere Namen angegeben werden, da mehrere Pakete von einem einzigen Master-Port oder Software-Produkt abhngen knnen. Das schliet Stable– und Developement-Zweige, lokalisierte Versionen und Slave-Ports ein, die verschiedene Auswahlmglichkeiten wichtiger Kompilierungszeit-Optionen bieten. 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 (fr Druck-betreffende Pakete), -without-gui (fr Pakete mit deaktivierter X-Untersttzung) oder hnliche jp-, ru-, zh- und andere, eventuell lokalisierte, Varianten in den entsprechenden Lnderkategorien der Ports-Sammlung 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 berschneiden. In einer Bereichsangabe steht * (Asterisk) fr die kleinste Versionsnummer. Insbesondere ist 2.* kleiner als 2.a. Deshalb kann ein Stern benutzt werden, um auf alle mglichen Alpha -, Beta– und RC -Versionen zuzutreffen. Zum Beispiel passt <ge>2.*</ge><lt>3.* </lt> auf alle Versionen der Form 2.x, whrend <ge> 2.0</ge><lt>3.0</lt> das nicht erfllt, 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 – auerdem Versionen 2.x vor 2.4_1 und Version 3.0b1. Mehrere zusammenhngende Gruppen von Paketen (im wesentlichen Ports) knnen im Abschnitt <affected> aufgefhrt 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 Sicherheitslcken teilen. Beachten Sie den Unterschied zum Anfhren mehrerer Namen innerhalb eines <package> Abschnittes. Die Versionsbereiche sollten, wenn mglich, sowohl PORTEPOCH als auch PORTREVISION erlauben. Bitte denken Sie daran, dass gem der Vergleichsregeln eine Version mit einer PORTEPOCH, die nicht Null ist, grer ist als jede Version ohne PORTEPOCH. Das heit, 3.0,1 ist grer als 3.1 oder sogar 8.9. Das ist die Zusammenfassung des Problems. In diesem Feld wird XHTML verwendet. Zumindest umschlieende <p> und </p> sollten auftauchen. Komplexere Tags sind zwar mglich, aber sollten nur um der Genauigkeit und Klarheit willen verwendet werden: Bitte verwenden Sie hier kein Eye-Candy. Dieser Abschnitt enthlt Verweise auf relevante Dokumente. Es wird empfohlen so viele Referenzen wie ntig aufzufhren. Das ist ein FreeBSD Sicherheitshinweis. Das ist ein FreeBSD Problembericht. Das ist eine Mitre CVE Kennung. Das ist eine SecurityFocus Fehler-Kennung. Das ist ein Sicherheitshinweis von US-CERT. Das ist eine Mitteilung ber eine Schwachstelle von US-CERT. Das ist ein Cyber-Sicherheitsalarm von US-CERT. Das ist ein technischer Cyber-Sicherheitsalarm von US-CERT. Das ist eine URL zu einem archivierten Posting auf einer Mailingliste. Das Attribut msgid ist optional und gibt die Nachrichtenkennung des Postings an. Das ist eine gewhnliche URL. Sie sollte nur verwendet werden, wenn keine der anderen Referenzkategorien verfgbar ist. Das ist das Datum, an dem die Sicherheitslcke bekannt wurde (JJJJ-MM-TT). Das ist das Datum, an dem der Eintrag hinzugefgt wurde (JJJJ-MM-TT). Das ist das Datum, an dem zuletzt irgendeine Information des Eintrags verndert wurde (JJJJ-MM-TT). Neue Eintrge drfen dieses Feld nicht enthalten. Es sollte beim Editieren eines existierenden Eintrags eingefgt werden. Ihre nderungen an der VuXML-Datenbank testen Nehmen wir an, Sie haben gerade einen Eintrag fr eine Sicherheitslcke in dem Paket clamav geschrieben oder ausgefllt, die in der Version 0.65_7 korrigiert wurde. Als Voraussetzung mssen Sie die aktuellen Versionen der Ports ports-mgmt/portaudit, ports-mgmt/portaudit-db sowie security/vuxml installieren. Um packaudit auszufhren, mssen Sie die Berechtigung haben DATABASEDIR zu schreiben – blicherweise ist das /var/db/portaudit. Durch Setzen der Umgebungsvariable DATABASEDIR knnen Sie hier auch ein anderes Verzeichnis angeben. Arbeiten Sie nicht aus dem Verzeichnis ${PORTSDIR}/security/vuxml heraus, mssen Sie zustzlich die Umgebungsvariable VUXMLDIR setzen, um anzugeben, in welchem Verzeichnis sich die Datei vuln.xml befindet. Zuerst berprfen Sie bitte, ob bereits ein Eintrag fr diese Schwachstelle existiert. Wenn es einen solchen Eintrag gibt, sollte er auf die vorige Version 0.65_6 zutreffen: &prompt.user; packaudit &prompt.user; portaudit clamav-0.65_6 Wenn keine vorhandenen Eintrge gefunden werden haben Sie grnes Licht, einen neuen Eintrag fr diese Sicherheitslcke anzulegen. Sie knnen 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 berprfen Sie danach die Syntax mit folgendem Befehl: &prompt.user; cd ${PORTSDIR}/security/vuxml && make validate Sie werden zumindest eines der folgenden Pakete bentigen: textproc/libxml2, textproc/jade. Jetzt bauen Sie bitte die portaudit-Datenbank aus der VuXML-Datei neu: &prompt.user; packaudit Um sicherzustellen, dass der Abschnitt <affected> Ihres Eintrags die richtigen Pakete betrifft, verwenden Sie bitte den folgenden Befehl: &prompt.user; portaudit -f /usr/ports/INDEX -r 74a9541d-5d6c-11d8-80e3-0020ed76ef5a Bitte lesen Sie in &man.portaudit.1; nach, um ein besseres Verstndnis der Befehlssyntax zu entwickeln. Bitte stellen Sie sicher, dass Ihr Eintrag keine falschen Treffer in der Ausgabe erzeugt. Jetzt berprfen Sie bitte, dass Ihr Eintrag die richtigen Versionen des Pakets angibt: &prompt.user; 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. Abschlieend berprfen Sie bitte, ob die Webseite, die aus der VuXML-Datenbank erzeugt wird, wie erwartet aussieht: &prompt.user; mkdir -p ~/public_html/portaudit &prompt.user; packaudit &prompt.user; lynx ~/public_html/portaudit/74a9541d-5d6c-11d8-80e3-0020ed76ef5a.html Was man machen respektive vermeiden sollte Einfhrung Hier ist eine Liste von gebruchlichen Dos and Don'ts (Dinge, die man machen oder vermeiden sollte), welchen Sie whrend des Portierungsprozesses begegnen werden. Sie sollten Ihren Port anhand dieser Liste berprfen. Sie knnen 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. <varname>WRKDIR</varname> Schreiben Sie in keine Dateien auerhalb von WRKDIR. WRKDIR ist der einzige Ort, welcher whrend des Erstellen des Ports garantiert beschreibbar ist (siehe Ports Installieren von CDROM fr ein Beispiel, um Ports in einem schreibgeschtzen Zweig zu erstellen). Wenn Sie eine der pkg-* Dateien modifizieren mssen, sollten Sie eine Variable erneut definieren, anstatt die Datei zu berschreiben. <varname>WRKDIRPREFIX</varname> Vergewissern Sie sich, dass Ihr Port WRKDIRPREFIX beachtet. Die meisten Ports sollten sich darber 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 hnliches ist. Falls Sie WRKDIR selbst definieren, sollten Sie sicherstellen, dass Sie ${WRKDIRPREFIX}${.CURDIR} am Anfang anfgen. Unterschiedliche Betriebssysteme und Betriebssystemversionen Sie knnen auf Quelltext treffen, welcher Modifizierungen oder bedingtes Kompilieren, abhngig davon, unter welcher Unix-Version er luft, bentigt. Falls Sie nderungen an solch einem Quelltext vornehmen mssen, stellen Sie bitte sicher, dass Sie Ihre nderungen so allgemein wie mglich halten, damit wir den Quelltext auf 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 knnen. 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 fgen 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 stoen, wo dies nicht so ist, wrden wir gerne davon erfahren. Bitte senden Sie eine E-Mail an &a.ports;. Eine andere Mglichkeit 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 hinzuzufgen, falls Sie diese Methode benutzen sollten. Sobald Sie sys/param.h hinzugefgt haben, knnen 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 hher) kompiliert werden wird. Der Wert des BSD-Makros ist 199506 fr 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 nderungen von 4.4-Lite2 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 nderung(en), die Sie machen, nur FreeBSD betrifft. Portierungsfallen, wie der Gebrauch von sys_errlist[] gegenber strerror() sind Berkeley-Eigenheiten, keine FreeBSD nderungen. In FreeBSD 2.x, ist __FreeBSD__ auf 2 definiert. In lteren Versionen, ist es 1. Alle spteren Versionen erhhen es, damit es mit der Haupt-Versionsnummer bereinstimmt. Falls Sie zwischen einem FreeBSD 1.x und einem FreeBSD 2.x (oder hher) System unterscheiden mssen, ist es normalerweise richtig, die BSD-Makros (wie oben beschrieben) zu benutzen. Gibt es tatschlich eine FreeBSD-spezifische nderung (wie z.B. spezielle Optionen von Shared-Libraries fr ld), ist es nicht zu beanstanden __FreeBSD__ und #if __FreeBSD__ > 1 zu nutzen, um FreeBSD 2.x und sptere Systeme zu erkennen. Falls Sie eine hhere Genauigkeit bentigen, um FreeBSD Systeme seit 2.0-RELEASE zu erkennen, knnen 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 Flle, in denen __FreeBSD__ htte benutzt werden sollen. Nur weil ein frherer Port es an der falschen Stelle benutzt hatte, bedeutet das nicht, dass Sie dies auch machen sollten. __FreeBSD_version Werte Hier ist eine praktische Liste von __FreeBSD_version-Werten wie in sys/param.h definiert: __FreeBSD_version-Werte Wert Datum Release 119411 2.0-RELEASE 199501, 199503 19. Mrz 1995 2.1-CURRENT 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 gendert) 2.2.1-RELEASE (nicht gendert) 2.2-STABLE nach 2.2.1-RELEASE 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. Mrz 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 &man.semctl.2; 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 &man.mount.2; nderung 300001 24. September 1997 3.0-CURRENT nach &man.mount.2; nderung 300002 2. Juni 1998 3.0-CURRENT nach &man.semctl.2; nderung 300003 7. Juni 1998 3.0-CURRENT nach ioctl arg 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. Mrz 1999 3.1-STABLE nach 3.1-RELEASE 310002 14. April 1999 3.1-STABLE nach 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 binr-inkompatibler IPFW und Socket-nderungen 330000 2. September 1999 3.3-RELEASE 330001 16. September 1999 3.3-STABLE 330002 24. November 1999 3.3-STABLE nach Hinzufgen von &man.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 nderung im Verhalten des dynamischen Linkers. 400002 13. Mrz 1999 4.0-CURRENT nach nderung der C++ Konstruktor/Destruktor Reihenfolge. 400003 27. Mrz 1999 4.0-CURRENT nach funktionierendem &man.dladdr.3;. 400004 5. April 1999 4.0-CURRENT nach der __deregister_frame_info Fehlerbehebung fr den dynamischen Linker (auch 4.0-CURRENT nach EGCS 1.1.2 Integration). 400005 27. April 1999 4.0-CURRENT nach &man.suser.9; API nderung (auch 4.0-CURRENT nach newbus). 400006 31. Mai 1999 4.0-CURRENT nach nderung der cdevsw-Registrierung. 400007 17. Juni 1999 4.0-CURRENT nach Hinzufgen von so_cred fr Zugangsberechtigungen auf Socket-Ebene. 400008 20. Juni 1999 4.0-CURRENT nach Hinzufgen eines poll Syscall-Wrappers zur libc_r. 400009 20. Juli 1999 4.0-CURRENT nach der nderung des Kernel dev_t-Typs zum struct specinfo-Zeiger. 400010 25. September 1999 4.0-CURRENT nach dem Beseitigen eines Fehlers in &man.jail.2;. 400011 29. September 1999 4.0-CURRENT nach der sigset_t Datentyp 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 Hinzufgen der erweiterbaren Linux Mode ioctl-Routinen. 400014 18. Januar 2000 4.0-CURRENT nach dem OpenSSL-Import. 400015 27. Januar 2000 4.0-CURRENT nach der C++ ABI nderung in GCC 2.95.2 von -fvtable-thunks zu -fno-vtable-thunks als Standard. 400016 27. Februar 2000 4.0-CURRENT nach OpenSSH-Import. 400017 13. Mrz 2000 4.0-RELEASE 400018 17. Mrz 2000 4.0-STABLE nach 4.0-RELEASE 400019 5. Mai 2000 4.0-STABLE nach der Einfhrung von verzgerten Prfsummen. 400020 4. Juni 2000 4.0-STABLE nach dem Einpflegen des libxpg4-Quelltextes in die libc. 400021 8. Juli 2000 4.0-STABLE nach der Aktualisierung von Binutils auf 2.10.0, nderungen der binren 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 &man.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 420001 10. Januar 2001 4.2-STABLE nach Kombinaion von libgcc.a und libgcc_r.a und zugehrigen nderungen der GCC-Bindungen. 430000 6. Mrz 2001 4.3-RELEASE 430001 18. Mai 2001 4.3-STABLE nach der Einfhrung 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 Einfhrung von d_thread_t. 440002 4. November 2001 4.4-STABLE nach den nderungen der mount-Struktur (betrifft Dateisystem-Kernelmodule). 440003 18. Dezember 2001 4.4-STABLE nachdem die Userland-Komponenten von smbfs importiert worden sind. 450000 20. Dezember 2001 4.5-RELEASE 450001 24. Februar 2002 4.5-STABLE nach der Umbenennung von Elementen der USB-Struktur. 450004 16. April 2002 4.5-STABLE nachdem die sendmail_enable &man.rc.conf.5; Variable gendert 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. 450006 1. Mai 2002 4.5-STABLE nach dem Reparieren des Empfangsfilters, welcher anfllig fr einfache DoS-Attacken war. 460000 21. Juni 2002 4.6-RELEASE 460001 21. Juni 2002 4.6-STABLE &man.sendfile.2; repariert, um mit der Dokumentation bereinzustimmen, und 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 Einflieen von `sed -i' aus CURRENT. 460102 1. September 2002 4.6-STABLE nach dem Einflieen von vielen 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 470101 10. November 2002 Beginn von generierten __std{in,out,err}p Referenzen statt __sF. Dies ndert std{in,out,err} von einem Ausdruck whrend des Kompilierens zu einem Laufzeitausdruck. 470102 23. Januar 2003 4.7-STABLE nach dem Einfliessen von mbuf-nderungen, um m_aux mbufs mit denen von m_tag zu ersetzen 470103 14. Februar 2003 4.7-STABLE erhlt OpenSSL 0.9.7 480000 30. Mrz 2003 4.8-RELEASE 480100 5. April 2003 4.8-STABLE 480101 22. Mai 2003 4.8-STABLE nachdem &man.realpath.3; Thread-sicher gemacht wurde. 480102 10. August 2003 4.8-STABLE 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 hinzugefgt wurde. 490102 4. Februar 2004 4.9-STABLE nach dem Einfliessen der libmap-Funktionalitt fr rtld. 491000 25. Mai 2004 4.10-RELEASE 491100 1. Juni 2004 4.10-STABLE 491101 11. August 2004 4.10-STABLE nach dem Einfliessen von Revision 20040629 der Paket-Werkzeuge aus CURRENT. 491102 16. November 2004 4.10-STABLE nach der Fehlerbehebung in der VM, um das Freigeben von fiktiven Speicherseiten korrekt zu handhaben. 492000 17. Dezember 2004 4.11-RELEASE 492100 17. Dezember 2004 4.11-STABLE 492101 18. April 2006 4.11-STABLE nach dem Hinzufgen von libdata/ldconfig Verzeichnissen zu den mtree-Dateien. 500000 13. Mrz 2000 5.0-CURRENT 500001 18. April 2000 5.0-CURRENT nach Hinzufgen von zustzlichen Feldern in den ELF-Headern und ndern der Methode zur ELF-Markierung von Binrdateien. 500002 2. Mai 2000 5.0-CURRENT nach kld-Metadaten nderungen. 500003 18. Mai 2000 5.0-CURRENT nach buf/bio nderungen. 500004 26. Mai 2000 5.0-CURRENT nach binutils Aktualisierung. 500005 3. Juni 2000 5.0-CURRENT nach dem Einfliessen des libxpg4 Quelltextes in die libc und der Einfhrung der TASKQ-Schnittstelle. 500006 10. Juni 2000 5.0-CURRENT nach dem Hinzufgen 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() nderungen. 500010 16. Juli 2000 5.0-CURRENT nachdem die mtree-Standards zurck zur ursprnglichen Variante gendert wurden; -L hinzugefgt, um Symlinks zu folgen. 500011 18. Juli 2000 5.0-CURRENT nachdem die kqueue-API gendert worden ist. 500012 2. September 2000 5.0-CURRENT nachdem &man.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. 500015 10. Januar 2001 5.0-CURRENT nach dem Kombinieren von libgcc.a und libgcc_r.a und damit verbundene nderungen an GCC-Bindungen. 500016 24. Januar 2001 5.0-CURRENT nach der nderung das Zusammenbinden von libc und libc_r zu erlauben, womit die -pthread Option veraltet ist. 500017 18. Februar 2001 5.0-CURRENT nach dem Umschalten von struct ucred zu struct xucred, um die vom Kernel exportierte API fr mount u.a.zu stabilisieren. 500018 24. Februar 2001 5.0-CURRENT nach dem Hinzufgen der 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. 500021 22. Juni 2001 5.0-CURRENT nach dem Bzip2-Import. Kennzeichnet auch, dass S/Key entfernt wurde. 500022 12. Juli 2001 5.0-CURRENT nach SSE Untersttzung. 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. 500025 4. Oktober 2001 5.0-CURRENT nach nderungen in der ABI bei der Weitergabe von Deskriptoren und Berechtigungen auf 64 Bit Plattformen. 500026 9. Oktober 2001 5.0-CURRENT nachdem XFree86 4 als Standard zum Erstellen der Pakete benutzt wird und die neue libc strnstr()-Funktion hinzugefgt wurde. 500027 10. Oktober 2001 5.0-CURRENT nachdem die neue libc strcasestr()-Funktion hinzugefgt wurde. 500028 14. Dezember 2001 5.0-CURRENT nachdem die Userland-Komponenten von smbfs importiert wurden. (nicht gendert) 5.0-CURRENT nachdem die neuen C99-Ganzzahlen mit spezifischer Breite hinzugefgt wurden. 500029 29. Januar 2002 5.0-CURRENT nachdem eine nderung im Rckgabewert von &man.sendfile.2; gemacht wurde. 500030 15. Februar 2002 5.0-CURRENT nach der Einfhrung des Types fflags_t, welches die passende Gre fr Dateiflags hat. 500031 24. Februar 2002 5.0-CURRENT nach der Umbenennung der USB elements-Struktur. 500032 16. Mrz 2002 5.0-CURRENT nach der Einfhrung von Perl 5.6.1. 500033 3. April 2002 5.0-CURRENT nachdem die sendmail_enable &man.rc.conf.5; Variable gendert 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 Hinzufgen von &man.dlfunc.3; 500038 24. Juli 2002 5.0-CURRENT nachdem die Typen von einigen Elementen der sockbuf-Struktur gendert wurden und nachdem die Struktur neu geordnet wurde. 500039 1. September 2002 5.0-CURRENT nach dem GCC 3.2.1 Import. Und auch nachdem die Header nicht mehr _BSD_FOO_T_ sondern _FOO_T_DECLARED benutzen. Dieser Wert kann auch als konservative Schtzung fr den Beginn der Untersttzung des &man.bzip2.1; Pakets verwendet werden. 500040 20. September 2002 5.0-CURRENT nachdem verschiedene nderungen an Plattenfunktionen gemacht wurden, um die Anhngigkeit von Interna der disklabel-Struktur zu entfernen. 500041 1. Oktober 2002 5.0-CURRENT nach dem Hinzufgen von &man.getopt.long.3; zur libc. 500042 15. Oktober 2002 5.0-CURRENT nach der Aktualisierung von Binutils auf 2.13, bei denen die FreeBSD-Emulation, vec und das Ausgabeformat gendert wurden. 500043 1. November 2002 5.0-CURRENT nach dem Hinzufgen schwacher pthread_XXX Stubs zur libc, womit libXThrStub.so veraltet ist. 5.0-RELEASE. 500100 17. Januar 2003 5.0-CURRENT nach dem Erstellen des RELENG_5_0-Zweiges 500101 19. Februar 2003 <sys/dkstat.h> ist leer und sollte nicht inkludiert werden. 500102 25. Februar 2003 5.0-CURRENT nach der nderung in der d_mmap_t-Schnittstelle. 500103 26. Februar 2003 5.0-CURRENT nachdem taskqueue_swi gedert wurde, um ohne Giant zu arbeiten, und taskqueue_swi_giant hinzugefgt wurde, um Giant zu verwenden. 500104 27. Februar 2003 cdevsw_add() und cdevsw_remove() gibt es nicht lnger. Auftauchen der MAJOR_AUTO-Allokationsmglichkeit. 500105 4. Mrz 2003 5.0-CURRENT nach der neuen cdevsw-Initialisierungsmethode. 500106 8. Mrz 2003 devstat_add_entry() wurde durch devstat_new_entry() ersetzt. 500107 15. Mrz 2003 Devstat Schnittstellennderung; siehe sys/sys/param.h 1.149. 500108 15. Mrz 2003 Token-Ring Schnittstellennderungen. 500109 25. Mrz 2003 Hinzufgen von vm_paddr_t. 500110 28. Mrz 2003 5.0-CURRENT nachdem &man.realpath.3; Thread-sicher gemacht wurde. 500111 9. April 2003 5.0-CURRENT nachdem &man.usbhid.3; mit NetBSD synchronisiert wurde. 500112 17. April 2003 5.0-CURRENT nach der neuen NSS Implementierung und Hinzufgen 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. 501101 29. Juni 2003 5.1-CURRENT nachdem die Semantik von sigtimedwait(2) and sigwaitinfo(2) korrigiert wurden. 501102 3. Juli 2003 5.1-CURRENT nach dem Hinzufgen der lockfunc und lockfuncarg-Felder zu &man.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 nderungen in twe. 501105 17. August 2003 5.1-CURRENT Untersttzung von dynamisch gebundenen /bin und /sbin und Verschieben von Bibliotheken nach /lib. 501106 8. September 2003 5.1-CURRENT nachdem im Kernel Untersttzung fr Coda 6.x hinzugefgt wurden. 501107 17. September 2003 5.1-CURRENT nachdem die 16550 UART-Konstanten von <dev/sio/sioreg.h> nach <dev/ic/ns16550.h> verschoben wurden. Und nachdem die libmap Funktionalitt vorbehaltlos vom rtld untersttzt wurde. 501108 23. September 2003 5.1-CURRENT nach Aktualisierung der PFIL_HOOKS API. 501109 27. September 2003 5.1-CURRENT nachdem kiconv(3) hinzugefgt wurde. 501110 28. September 2003 5.1-CURRENT nachdem der standardmige Ablauf von open und close in cdevsw gendert wurde. 501111 16. Oktober 2003 5.1-CURRENT nachdem das Layout von cdevsw gendert wurde. 501112 16. Oktober 2003 5.1-CURRENT nach dem Hinzufgen von Mehrfachvererbung in kobj. 501113 31. Oktober 2003 5.1-CURRENT nach der if_xname nderung in der Struktur ifnet 501114 16. November 2003 5.1-CURRENT nachdem /bin und /sbin gendert 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. 502101 19. Dezember 2003 5.2-CURRENT nachdem die __cxa_atexit/__cxa_finalize Funktionen zur libc hinzugefgt wurden. 502102 30. Januar 2004 5.2-CURRENT nachdem die Standard-Thread Bibliothek von libc_r zu libpthread gendert wurde. 502103 21. Februar 2004 5.2-CURRENT nach dem Gertetreiber API Megapatch. 502104 25. Februar 2004 5.2-CURRENT nachdem getopt_long_only() hinzugefgt wurde. 502105 5. Mrz 2004 5.2-CURRENT nachdem NULL fr C in ((void *)0) gendert wurde, was mehr Warnungen erzeugt. 502106 8. Mrz 2004 5.2-CURRENT nachdem pf beim Bauen und Installieren mit eingebunden wird. 502107 10. Mrz 2004 5.2-CURRENT nachdem time_t auf der sparc64-Plattform in einen 64-bit Wert gendert wurde. 502108 12. Mrz 2004 5.2-CURRENT nachdem sich die Untersttzung fr den Intel C/C++-Compiler in einigen Headern und execve(2) gendert hat, um sich strikter an POSIX zu halten. 502109 22. Mrz 2004 5.2-CURRENT nach der Einfhrung der bus_alloc_resource_any API 502110 27. Mrz 2004 5.2-CURRENT nach dem Hinzufgen 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 Hinzufgen der .warning Directive fr make. 502113 4. Juni 2004 5.2-CURRENT nachdem ttyioctl() zwingend erforderlich fr serielle Treiber gemacht wurde. 502114 13. Juni 2004 5.2-CURRENT nach dem Import des ALTQ-Frameworks. 502115 14. Juni 2004 5.2-CURRENT nachdem sema_timedwait(9) gendert wurde, 0 bei Erfolg und einen von 0 verschiedenen Fehlercode im Falle eines Fehlers zurckzuliefern. 502116 16. Juni 2004 5.2-CURRENT nach dem ndern der Kernel Struktur dev_t, in ein Zeiger auf die Struktur cdev * 502117 17. Juni 2004 5.2-CURRENT nach dem ndern der Kernelstruktur udev_t in dev_t. 502118 17. Juni 2004 5.2-CURRENT nachdem Untersttzung fr CLOCK_VIRTUAL und CLOCK_PROF zu clock_gettime(2) und clock_getres(2) hinzugefgt wurde. 502119 22. Juni 2004 5.2-CURRENT nachdem die berprfung des Klonens von Netzwerk-Schnittstellen gendert 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. 502122 11. Juli 2004 5.2-CURRENT nach der Einfhrung des KDB Debugger Frameworks, der Umwandlung des DDB in ein Backend und der Einfhrung des GDB-Backends. 502123 12. Juli 2004 5.2-CURRENT nachdem VFS_ROOT gendert wurde, eine Struktur thread als Argument zu aktzeptieren, wie vflush. Die Struktur kinfo_proc enthlt nun einen Zeiger auf Benutzer Daten. Der Umstieg auf xorg als standardmige X Implementierung wurde auch zu dieser Zeit durchgefhrt. 502124 24. Juli 2004 5.2-CURRENT nachdem die Art und Weise, wie rc.d-Skripte von Ports und Altlasten gestartet werden, getrennt wurde. 502125 28. Juli 2004 5.2-CURRENT nachdem die vorherige nderung rckgngig gemacht wurde. 502126 31. Juli 2004 5.2-CURRENT nach dem Entfernen von kmem_alloc_pageable() und dem Import von GCC 3.4.2. 502127 2. August 2004 5.2-CURRENT nachdem die UMA Kernel API gendert wurde, um Konstruktoren und Initialisierungsmethoden zu erlauben fehlzuschlagen. 502128 8. August 2004 5.2-CURRENT nach der nderung in der 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 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. 503101 3. Dezember 2004 5.3-STABLE nach dem Hinzufgen von Flloptionen im Stile der libc zu &man.strftime.3;. 503102 13. Februar 2005 5.3-STABLE nachdem OpenBSD's nc(1) von CURRENT importiert wurde. 503103 27. Februar 2005 5.4-PRERELEASE nach dem Einfliessen der Reparaturen aus CURRENT, in <src/include/stdbool.h> und <src/sys/i386/include/_types.h>, um die GCC-Kompatibilitt des Intel C/C++-Compilers zu benutzen. 503104 28. Februar 2005 5.4-PRERELEASE nach dem Einfliessen der nderung aus CURRENT in ifi_epoch statt der lokalen Zeit die Betriebszeit des Systems zu benutzen. 503105 2. Mrz 2005 5.4-PRERELEASE nach dem Einfliessen der Reparaturen von EOVERFLOW in vswprintf(3) aus CURRENT. 504000 3. April 2005 5.4-RELEASE. 504100 3. April 2005 5.4-STABLE nach dem Erstellen des RELENG_5_4-Zweiges. 504101 11. Mai 2005 5.4-STABLE nach dem Vergrern der standardmigen Stackgre fr Threads. 504102 24. Juni 2005 5.4-STABLE nach dem Hinzufgen 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. 504105 17. Januar 2006 5.4-STABLE nach dem Einfliessen der 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. 600002 30. August 2004 6.0-CURRENT nach der anfnglichen Einfhrung von ifi_epoch zur Struktur if_data. Wurde nach ein paar Tagen wieder rckgngig gemacht. Benutzen Sie diesen Wert bitte nicht. 600003 8. September 2004 6.0-CURRENT nach dem erneuten Hinzufgen des Elements ifi_epoch zur Struktur if_data. 600004 29. September 2004 6.0-CURRENT nach dem Hinzufgen der Struktur inpcb als Argument in der pfil API. 600005 5. Oktober 2004 6.0-CURRENT nach dem Hinzufgen des "-d DESTDIR" Schalters zu newsyslog. 600006 4. November 2004 6.0-CURRENT nach dem Hinzufgen von Flloptionen im Style der libc zu &man.strftime.3;. 600007 12. Dezember 2004 6.0-CURRENT nach dem Hinzufgen von 802.11 Framework Neuerungen. 600008 25. Januar 2005 6.0-CURRENT nderung an den VOP_*VOBJECT() Funktionen und Einfhrung des MNTK_MPSAFE Schalters fr Dateisysteme, welche ohne Giant arbeiten. 600009 4. Februar 2005 6.0-CURRENT nach dem Hinzufgen von cpufreq Framework und Treibern. 600010 6. Februar 2005 6.0-CURRENT nachdem OpenBSD's nc(1) importiert wurde. 600011 12. Februar 2005 6.0-CURRENT nachdem der Anschein von matherr() Untersttzung in SVID2 entfernt wurde. 600012 15. Februar 2005 6.0-CURRENT nach dem Vergrern der standardmigen Stackgre fr Threads. 600013 19. Februar 2005 6.0-CURRENT nach dem Einfliessen der Reparaturen in <src/include/stdbool.h> und <src/sys/i386/include/_types.h>, um die GCC-Kompatibilitt des Intel C/C++-Compilers zu benutzen. 600014 21. Februar 2005 6.0-CURRENT nachdem die berprfungen auf EOVERFLOW in vswprintf(3) korrigiert wurden. 600015 25. Februar 2005 6.0-CURRENT nach dem Einfliessen der nderung, in ifi_epoch, statt der lokalen Zeit, die Betriebzeit des Systems zu benutzen. 600016 26. Februar 2005 6.0-CURRENT nachdem das Format von LC_CTYPE auf der Festplatte verndert wurde. 600017 27. Februar 2005 6.0-CURRENT nachdem das Format der NLS-Kataloge auf der Festplatte verndert wurde. 600018 27. Februar 2005 6.0-CURRENT nachdem das Format von LC_COLLATE auf der Festplatte verndert wurde. 600019 28. Februar 2005 Installation der acpica Include-Dateien in /usr/include. 600020 9. Mrz 2005 Hinzufgen des MSG_NOSIGNAL Schalters zur send(2) API. 600021 17. Mrz 2005 Hinzufgen von Feldern zu cdevsw 600022 21. Mrz 2005 gtar wurde aus dem Basissystem entfernt. 600023 13. April 2005 Die Optionen LOCAL_CREDS, LOCAL_CONNWAIT fr Sockets wurde zu unix(4) hinzugefgt. 600024 19. April 2005 &man.hwpmc.4; und zugehrige Werkzeuge wurden zu 6.0-CURRENT hinzugefgt. 600025 26. April 2005 Die Struktur icmphdr wurden zu 6.0-CURRENT hinzugefgt. 600026 3. Mai 2005 pf Aktualisierung auf 3.7. 600027 6. Mai 2005 Kernel libalias und ng_nat wurden eingefhrt. 600028 13. Mai 2005 POSIX ttyname_r(3) wurde ber unistd.h und libc zur Verfgung 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 herausgelst wurde. 600032 11. Juli 2005 6.0-CURRENT nach dem Import von libpcap v0.9.1. 600033 25. Juli 2005 6.0-STABLE nachdem die Versionen aller gemeinsam genutzten Bibliotheken, welche seit RELENG_5 nicht gendert wurden, erhht wurden. 600034 13. August 2005 6.0-STABLE nachdem das Argument credential zu der dev_clone-Ereignisbehandlung hinzugefgt wurde. 6.0-RELEASE. 600100 1. November 2005 6.0-STABLE nach dem Erstellen des 6.0-RELEASE-Zweiges. 600101 21. Dezember 2005 6.0-STABLE nach dem Aufnehmen von Skripten aus den local_startup-Verzeichnissen in &man.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. 600104 17. Januar 2006 6.0-STABLE nach dem Einfliessen der nderung von ldconfig_local_dirs aus CURRENT. 600105 26. Februar 2006 6.0-STABLE nach der NLS-Kataloguntersttzung 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. 601103 17. Juli 2006 6.1-STABLE nach der Aktualisierung der Namensauflsung zu BIND9 und Aufnahme der ablaufinvarianten Versionen der netdb-Funktionen. 601104 8. August 2006 6.1-STABLE nachdem Untersttzung fr DSO (dynamic shared objects - gemeinsam genutzte, dynamische Objekte) in OpenSSL aktiviert wurde. 601105 2. September 2006 6.1-STABLE nachdem 802.11 Reparaturen die API der IEEE80211_IOC_STA_INFO ioctl gendert 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 Hinzufgen der Wi-Spy Eigenart. 602102 28. Dezember 2006 6.2-STABLE nachdem pci_find_extcap() hinzugefgt wurde. 602103 16. Januar 2007 6.2-STABLE nach dem Einpflegen der dlsym nderung aus CURRENT, ein angefordertes Symbol sowohl in der spezifizierten dso, als auch in den impliziten Abhngigkeiten nachzuschlagen. 602104 28. Januar 2007 6.2-STABLE nach dem Einpflegen von ng_deflate(4) und ng_pred1(4) netgraph Knoten und neuen Kompressions- und -Verschlsselungmodi fr den ng_ppp(4) Knoten aus CURRENT. 602105 20. Februar 2007 6.2-STABLE nach dem Einpflegen der BSD lizensierten Version von &man.gzip.1;, welche von NetBSD portiert wurde aus CURRENT. 602106 31. Mrz 2007 6.2-STABLE nach dem Einpflegen der PCI MSI und MSI-X Untersttzung aus CURRENT. 602107 6. April 2007 6.2-STABLE nach dem Einpflegen von ncurses 5.6 und Untersttzung fr Multibyte-Zeichen aus CURRENT. 602108 11. April 2007 6.2-STABLE nach dem Einpflegen des 'SG' Peripheriegertes aus CURRENT in CAM, welches einen Teil der SCSI SG passthrough Gerte API von Linux enthlt. 602109 17. April 2007 6.2-STABLE nach dem Einpflegen von readline 5.2 Patchset 002 aus CURRENT. 602110 2. Mai 2007 6.2-STABLE nach dem Einpflegen von pmap_invalidate_cache(), pmap_change_attr(), pmap_mapbios(), pmap_mapdev_attr(), und pmap_unmapbios() fr amd64 und i386 aus CURRENT. 602111 11. Juni 2007 6.2-STABLE nach dem Einpflegen von 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. 602113 25. Oktober 2007 6.2-STABLE, nach der Trennung in "wide und single byte ctype". Neu kompilierte Binrdateien, die ctype.h referenzieren, erfordern mglicherweise ein neues Symbol, __mb_sb_limit, das auf lteren Systemen nicht verfgbar ist. 602114 30. Oktober 2007 6.2-STABLE, nachdem die ctype ABI-Aufwrtskompatibilitt wiederhergestellt wurde. 602115 21. November 2007 FreeBSD 6.2-STABLE nach der 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. 603101 7. Dezember 2007 6.3-STABLE, nachdem der Support fr den Multibyte-Datentyp im Bit-Makro gefixt wurde. 603102 24. April 2008 6.3-STABLE nach Hinzufgen von l_sysid zu struct flock. 603103 27. Mai 2008 6.3-STABLE nach Einflieen der memrchr-Funktion. 603104 15. Juni 2008 6.3-STABLE nach bernahme der Untersttzung 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. 700001 23. Juli 2005 7.0-CURRENT nachdem die Versionen aller gemeinsam genutzten Bibliotheken, welche seit RELENG_5 nicht gendert wurden, erhht wurden. 700002 13. August 2005 7.0-CURRENT nachdem ein Berechtigungs-Argument zur dev_clone-Ereignisroutine hinzugefgt wurde. 700003 25. August 2005 7.0-CURRENT nachdem memmem(3) zur libc hinzugefgt wurde. 700004 30. Oktober 2005 7.0-CURRENT nachdem die Argumente der Kernelfunktion solisten(9) modifiziert wurden, um einen Backlog-Parameter (Anzahl der maximalen wartenden Verbindungen) zu akzeptieren. 700005 11. November 2005 7.0-CURRENT nachdem IFP2ENADDR() gendert wurde, einen Zeiger auf IF_LLADDR() zurckzugeben. 700006 11. November 2005 7.0-CURRENT nach dem Hinzufgen des if_addr-Elements zur Struktur ifnet und dem Entfernen von IFP2ENADDR(). 700007 2. Dezember 2005 7.0-CURRENT nach dem Aufnehmen von Skripten aus den local_startup Verzeichnissen in &man.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 nderungen und Symbol Versionierung. 700010 20. Dezember 2005 7.0-CURRENT nach Hinzufgen der hostb und vgapci Treiber, Hinzufgen von pci_find_extcap() und nderung der AGP Treiber die Apertur nicht lnger abzubilden. 700011 31. Dezember 2005 7.0-CURRENT nachdem auf allen Plattformen auer Alpha tv_sec in time_t umgewandelt wurde. 700012 8. Januar 2006 7.0-CURRENT nach nderung von ldconfig_local_dirs. 700013 12. Januar 2006 7.0-CURRENT nach nderung in /etc/rc.d/abi um /compat/linux/etc/ld.so.cache als Symlink in ein schreibgeschtztes Dateisystem zu untersttzen. 700014 26. Januar 2006 7.0-CURRENT nach pts Import. 700015 26. Mrz 2006 7.0-CURRENT nach Einfhrung von Version 2 der &man.hwpmc.4;'s ABI. 700016 22. April 2006 7.0-CURRENT nach dem Hinzufgen von &man.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 Hinzufgen 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. 700022 9. September 2006 7.0-CURRENT nach der dlsym nderung, ein angefordertes Symbol sowohl in der spezifizierten dso, als auch in den impliziten Abhngigkeiten nachzuschlagen. 700023 23. September 2006 7.0-CURRENT nach dem Hinzufgen neuer Sound-IOCTLs fr 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 Hinzufgen der libelf. 700026 26. November 2006 7.0-CURRENT nach greren nderungen an den Sound sysctls. 700027 30. November 2006 7.0-CURRENT nach dem Hinzufgen der Wi-Spy-Eigenart. 700028 15. Dezember 2006 7.0-CURRENT nach dem Hinzufgen von sctp-Aufrufen zur libc. 700029 26. Januar 2007 7.0-CURRENT nach dem Ersetzen von GNU &man.gzip.1; durch eine von NetBSD portierte Version, die unter BSD-Lizenz steht. 700030 7. Februar 2007 7.0-CURRENT nach dem Entfernen der IPIP Tunnelkapselung (VIFF_TUNNEL) aus dem IPv4 Multicast-Forwarding-Quelltext. 700031 23. Februar 2007 7.0-CURRENT nach den Modifizierungen an bus_setup_intr() (newbus). 700032 2. Mrz 2007 7.0-CURRENT nach der Aufnahme der Firmware fr ipw(4) und iwi(4). 700033 9. Mrz 2007 7.0-CURRENT nach Untersttzung fr Multibyte-Zeichen. 700034 19. Mrz 2007 7.0-CURRENT nach nderungen, wie insmntque(), getnewvnode() und vfs_hash_insert() arbeiten. 700035 26. Mrz 2007 7.0-CURRENT nach Hinzufgen eines Benachrichtigungsmechanismus fr CPU Frequenznderungen. 700036 6. April 2007 7.0-CURRENT nach dem Import des ZFS Dateisystemes. 700037 8. April 2007 7.0-CURRENT nach dem Einpflegen des 'SG' Peripheriegertes in CAM, welches einen Teil der SCSI SG passthrough Gerte API von Linux enthlt. 700038 30. April 2007 7.0-CURRENT nachdem &man.getenv.3;, &man.putenv.3;, &man.setenv.3; und &man.unsetenv.3; gendert wurden, um POSIX konform zu sein. 700039 1. Mai 2007 7.0-CURRENT nachdem die nderungen von 700038 rckgngig gemacht wurden. 700040 10. Mai 2007 7.0-CURRENT nach dem Hinzufgen von &man.flopen.3; zur libutil. 700041 13. Mai 2007 7.0-CURRENT nachdem Symbol Versionierung aktiviert und die standardmige Thread-Bibliothek zu libthr gendert wurde. 700042 19. Mai 2007 7.0-CURRENT nach dem Import von GCC 4.2.0. 700043 21. Mai 2007 7.0-CURRENT nachdem die Versionen aller Shared-Libraries, welche seit RELENG_6 nicht gendert wurden, erhht worden sind. 700044 7. Juni 2007 7.0-CURRENT nachdem das Argument fr vn_open()/VOP_OPEN() vom Dateideskriptorindex zur Struktur file * gedert wurde. 700045 10. Juni 2007 7.0-CURRENT nachdem &man.pam.nologin.8; gedert wurde, eine Kontoverwaltungs-Funktion statt einer Authentifizierungsfunktion fr das PAM-Framework zur Verfgung zu stellen. 700046 11. Juni 2007 7.0-CURRENT nach aktualisierter 802.11 wireless Untersttzung. 700047 11. Juni 2007 7.0-CURRENT, nachdem TCP-LRO-Schnittstellen-Ressourcen hinzugefgt wurden. 700048 12. Juni 2007 7.0-CURRENT, nachdem die RFC 3678 API-Untersttzung zum IPv4-Stack hinzugefgt wurde. Veraltetes RFC 1724-Verhalten des IP_MULTICAST_IF ioctl wurde entfernt; 0.0.0.0/8 darf nicht lnger als Schnittstellen-Index benutzt werden. Stattdessen sollte die Struktur ipmreqn verwendet werden. 700049 3. Juli 2007 7.0-CURRENT, nachdem pf von OpenBSD 4.1 importiert wurde (nicht gendert) 7.0-CURRENT, nachdem die IPv6-Untersttzung um FAST_IPSEC erweitert, KAME IPSEC entfernt und FAST_IPSEC in IPSEC umbenannt wurde. 700050 4. Juli 2007 7.0-CURRENT, nachdem Aufrufe von 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 Untersttzung fr PCI Domnen hinzugefgt wurde. 700054 25. Oktober 2007 7.0-CURRENT, nach der Trennung in "wide und single byte ctype". 700055 28. Oktober 2007 7.0-RELEASE sowie 7.0-CURRENT, nachdem die ABI-Abwrtskompatibilitt fr die FreeBSD 4/5/6-Versionen der PCIOCGETCONF-, PCIOCREAD- sowie PCIOCWRITE IOCTLs hinzugefgt 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 Einfhrung von m_collapse(). 700102 30. Mrz 2008 7.0-STABLE nach Einflieen von kdb_enter_why(). 700103 10. April 2008 7.0-STABLE nach Hinzufgen von l_sysid zu struct flock. 700104 11. April 2008 7.0-STABLE nach bernahme von procstat(1). 700105 11. April 2008 7.0-STABLE nach Einfhrung von umtx-Features. 700106 15. April 2008 7.0-STABLE nach Hinzufgen der Untersttzung von &man.write.2; zu &man.psm.4;. 700107 20. April 2008 7.0-STABLE nach Hinzufgen des Befehls F_DUP2FD zu &man.fcntl.2;. 700108 5. Mai 2008 7.0-STABLE nach einigen nderungen an &man.lockmgr.9;, welche die Einbindung von sys/lock.h zur Verwendung von &man.lockmgr.9; voraussetzen. 700109 27. Mai 2008 7.0-STABLE nach Einflieen der memrchr-Funktion. 700110 5. August 2008 7.0-STABLE nach Einfhrung eines Clients fr den Kernel NFS lockd. 700111 20. August 2008 7.0-STABLE nach Hinzufgen einer Untersttzung von physisch fortlaufender Jumbo Frames. 700112 27. August 2008 7.0-STABLE nach Einflieen einer Kerneluntersttzung fr 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 bernahme von strndup. 701102 17. Januar 2009 7.1-STABLE nach Hinzufgen einer Untersttzung von cpuctl(4). 701103 7. Februar 2009 7.1-STABLE nach Einflieen der Untersttzung von Jails mit keinen oder mehreren IPv4-/IPv6-Adressen. 701104 14. Februar 2009 7.1-STABLE, nachdem der Besitzer des Suspend in struct mount gespeichert wird und die Funktion vfs_susp_clean in struct vfsops aufgenommen ist. 701105 12. Mrz 2009 7.1-STABLE nach der inkompatiblen nderung am sysctl kern.ipc.shmsegs, um die Anforderung grerer Segmente von gemeinsam genutzten SysV-Speicher auf 64bit-Architekturen zu erlauben. 701106 14. Mrz 2009 7.1-STABLE nach der bernahme einer Fehlerbehebung fr Warteoperationen, die POSIX-Semaphore verwenden. 702000 15. April 2009 7.2-RELEASE 702100 15. April 2009 7.2-STABLE nach 7.2-RELEASE. 702101 15. Mai 2009 7.2-STABLE, nachdem ichsmb(4) dahingehend gendert wurde, dass es links-ausgerichtete Adressierung von Slaves verwendet, um anderen SMBus-Kontrollertreibern zu entsprechen. 702102 28. Mai 2009 7.2-STABLE nach dem Einflieen der Funktion fdopendir. 702103 06. Juni 2009 7.2-STABLE nach dem Einflieen von PmcTools. 702104 14. Juli 2009 7.2-STABLE nach dem Einflieen des Systemaufrufs closefrom. 702105 31. Juli 2009 7.2-STABLE nach dem Einflieen der nderung an der SYSVIPC-ABI. 702106 14. September 2009 7.2-STABLE nach dem Einflieen der PAT-Verbesserungen fr x86-Prozessoren sowie dem Hinzufgen von d_mmap_single() und des VM-Objekttyps fr 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. 800002 21. Oktober 2007 8.0-CURRENT, nachdem kthread_create() und Konsorten in kproc_create() usw. umbenannt wurden. 800003 24. Oktober 2007 8.0-CURRENT, nachdem die ABI-Abwrtskompatibilitt fr die FreeBSD 4/5/6-Versionen der PCIOCGETCONF-, PCIOCREAD- sowie PCIOCWRITE IOCTLs hinzugefgt wurde. Damit verbunden war, dass die ABI der PCIOCGETCONF IOCTL erneut deaktiviert werden musste. 800004 12. November 2007 8.0-CURRENT, nachdem der agp(4) Treiber verschoben wurde von src/sys/pci nach src/sys/dev/agp. 800005 4. Dezember 2007 8.0-CURRENT nach nderungen am Jumbo Frame Allocator. 800006 7. Dezember 2007 8.0-CURRENT, nach dem Hinzufgen der callgraph capture Funktionalitt zu &man.hwpmc.4;. 800007 25. Dezember 2007 8.0-CURRENT nach dem Hinzufgen 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 Einfhrung von &man.lockmgr.disown.9; 800010 10. Januar 2008 8.0-CURRENT nach nderungen am &man.vn.lock.9;-Prototyp. 800011 13. Januar 2008 8.0-CURRENT nach nderungen an den Prototypen von &man.VOP.LOCK.9; und &man.VOP.UNLOCK.9;. 800012 19. Januar 2008 8.0-CURRENT nach Einfhrung von &man.lockmgr.recursed.9;, &man.BUF.RECURSED.9; und &man.BUF.ISLOCKED.9; sowie Entfernung von BUF_REFCNT(). 800013 23. Januar 2008 8.0-CURRENT nach Einfhrung der ASCII-Kodierung. 800014 24. Januar 2008 8.0-CURRENT nach nderungen am &man.lockmgr.9;-Prototyp und Entfernung von lockcount() sowie LOCKMGR_ASSERT(). 800015 26. Januar 2008 8.0-CURRENT nach Erweiterung der Datentypen der &man.fts.3;-Strukturen. 800016 1. Februar 2008 8.0-CURRENT nach Hinzufgen eines neuen Parameters zu MEXTADD(9). 800017 6. Februar 2008 8.0-CURRENT nach Einfhrung der Optionen LK_NODUP und LK_NOWITNESS in die &man.lockmgr.9;-Umgebung. 800018 8. Februar 2008 8.0-CURRENT nach Hinzufgen von m_collapse. 800019 9. Februar 2008 8.0-CURRENT nach Hinzufgen einer Arbeits-, Wurzel- und Jailverzeichnisuntersttzung zur sysctl-Variable kern.proc.filedesc. 800020 13. Februar 2008 8.0-CURRENT nach Einfhrung der Funktionen &man.lockmgr.assert.9; und BUF_ASSERT. 800021 15. Februar 2008 8.0-CURRENT nach Einfhrung von &man.lockmgr.args.9; und Entfernung der Option LK_INTERNAL. 800022 (zurckgezogen) 8.0-CURRENT nach Setzen von BSD &man.ar.1; als Systemstandard. 800023 25. Februar 2008 8.0-CURRENT nach Prototypennderungen an &man.lockstatus.9; und &man.VOP.ISLOCKED.9;, eigens zur Abschaffung des Parameters struct thread. 800024 1. Mrz 2008 8.0-CURRENT nach Beseitigung der Funktionen lockwaiters und BUF_LOCKWAITERS, nderung des Rckgabewerts der Funktion brelvp von void nach int sowie Einfhrung neuer Optionen fr &man.lockinit.9;. 800025 8. Mrz 2008 8.0-CURRENT nach Hinzufgen des Kommandos F_DUP2FD zu &man.fcntl.2;. 800026 12. Mrz 2008 8.0-CURRENT nach nderung des Parameters fr die Prioritt an cv_broadcastpri, sodass 0 fr keine Prioritt steht. 800027 24. Mrz 2008 8.0-CURRENT nach nderung der Monitoring ABI von BPF, als Zero-Copy Puffer hinzugefgt wurden. 800028 26. Mrz 2008 8.0-CURRENT nach Hinzufgen von l_sysid zu struct flock. 800029 28. Mrz 2008 8.0-CURRENT nach Wiedereingliederung der Funktion BUF_LOCKWAITERS und Hinzufgen von &man.lockmgr.waiters.9;. 800030 1. April 2008 8.0-CURRENT nach Einfhrung der Funktionen &man.rw.try.rlock.9; und &man.rw.try.wlock.9;. 800031 6. April 2008 8.0-CURRENT nach Einfhrung der Funktionen lockmgr_rw und lockmgr_args_rw. 800032 8. April 2008 8.0-CURRENT nach Implementierung des Systemaufrufs openat und seiner Verwandten, Einfhrung der Option O_EXEC in &man.open.2; und Bereitstellung der entsprechenden Systemaufrufe innerhalb der &linux;-Kompatibilittsumgebung. 800033 8. April 2008 8.0-CURRENT nach Hinzufgen der Untersttzung von &man.write.2; in der nativen Operationsebene von &man.psm.4;. Es knnen nun beliebig Kommandos nach /dev/psm%d geschrieben und der Status dann von dort gelesen werden. 800034 10. April 2008 8.0-CURRENT nach Einfhrung der Funktion memrchr. 800035 16. April 2008 8.0-CURRENT nach Einfhrung der Funktion fdopendir. 800036 20. April 2008 8.0-CURRENT nach Umstellung des Standards 802.11 auf Untersttzung von Multi-BSS (auch vaps). 800037 9. Mai 2008 8.0-CURRENT nach Hinzufgen einer Untersttzung fr Multi Routing-Tabellen (siehe setfib(1), setfib(2)). 800038 26. Mai 2008 8.0-CURRENT nach Entfernen von netatm und ISDN4BSD sowie dem Hinzufgen 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 Einfhrung eines Clients fr den Kernel NFS lockd. 800041 22. Juli 2008 8.0-CURRENT nach Hinzufgen von arc4random_buf(3) und arc4random_uniform(3). 800042 8. August 2008 8.0-CURRENT nach Hinzufgen von cpuctl(4). 800043 13. August 2008 8.0-CURRENT nach nderung von bpf(4) zur Verwendung einer einzelnen Gertedatei anstatt von Klonierung. 800044 17. August 2008 8.0-CURRENT nach bernahme des ersten Teils aus dem vimage-Projekt durch Erweitern globaler Variablen um den Prfix V_. Zuknftig werden die virtualisierten Variablen dann mit Hilfe von Makros in ihre globalen Namen aufgelst. 800045 20. August 2008 8.0-CURRENT nach Eingliederung des MPSAFE TTY-Layers, einschlielich 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. 800048 16. September 2008 8.0-CURRENT nach Anpassung des Codes fr Kernel NFS mount, sodass einzelne Mountoptionen im Parameter struct iovec an nmount() akzeptiert werden und nicht nur ein groes struct nfs_args. 800049 17. September 2008 8.0-CURRENT nach Entfernen von &man.suser.9; und &man.suser.cred.9;. 800050 20. Oktober 2008 8.0-CURRENT nach API-nderungen im Umgang mit dem Buffer Cache. 800051 23. Oktober 2008 8.0-CURRENT nach Entfernen der Makros &man.MALLOC.9; und &man.FREE.9;. 800052 28. Oktober 2008 8.0-CURRENT nach Einfhrung von accmode_t und Umbennung des Parameters a_mode an VOP_ACCESS nach a_accmode. 800053 2. November 2008 8.0-CURRENT nach nderung des Prototyps von &man.vfs.busy.9; und Einfhrung der Optionen MBF_NOWAIT sowie MBF_MNTLSTLOCK. 800054 22. November 2008 8.0-CURRENT nach Hinzufgen von Funktionen im Bereich buf_ring, Memory Barriers und ifnet, um mehrere Sendeschlangen auf Hardwareebene fr Karten zu ermglichen, die dies untersttzen, sowie einer Ring Buffer-Implementierung ohne Lock, um Treibern zu ermglichen, Paketschlangen effizienter zu verwalten. 800055 27. November 2008 8.0-CURRENT nach Hinzufgen einer Untersttzung fr &intel; Core, Core2 und Atom zu &man.hwpmc.4;. 800056 29. November 2008 8.0-CURRENT nach Einfhrung von Jails mit mehreren oder gar keinen IPv4-/IPv6-Adressen. 800057 1. Dezember 2008 8.0-CURRENT nach Wechsel zum ath_hal Quellcode. 800058 12. Dezember 2008 8.0-CURRENT nach Einfhrung der Funktion VOP_VPTOCNP. 800059 15. Dezember 2008 8.0-CURRENT gliedert das neue ARPv2 ein. 800060 19. Dezember 2008 8.0-CURRENT nach Hinzufgen 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. 800063 18. Februar 2009 8.0-CURRENT nach nderung der GENERIC-Konfiguration zur Verwendung des USB2-Stack und Hinzufgen von fdevname(3). 800064 23. Februar 2009 8.0-CURRENT, nachdem der USB2-Stack nach dev/usb verschoben wurde, um es zu ersetzen. 800065 26. Februar 2009 8.0-CURRENT nach Umbenennen aller Funktionen in libmp(3). 800066 27. Februar 2009 8.0-CURRENT nach Anpassung des devfs-Verhaltens im Zusammenhang mit USB. 800067 28. Februar 2009 8.0-CURRENT nach Hinzufgen von getdelim(), getline(), stpncpy(), strnlen(), wcsnlen(), wcscasecmp() und wcsncasecmp(). 800068 2. Mrz 2009 8.0-CURRENT nach Umbenennen der Gerteklasse ushub in uhub. 800069 9. Mrz 2009 8.0-CURRENT nach Umbenennen von libusb20.so.1 in libusb.so.1. 800070 9. Mrz 2009 8.0-CURRENT nach der Einfhrung von IGMPv3 und Source-Specific-Multicast (SSM) in den IPv4-Stack. 800071 14. Mrz 2009 8.0-CURRENT nach der Anpassung von gcc zur Verwendung der C99-Inline-Semantik in den Modi c99 und gnu99. 800072 15. Mrz 2009 8.0-CURRENT, nachdem die Option IFF_NEEDSGIANT entfernt wurde; Netzwerktreiber, die nicht MPSAFE sind, werden nicht mehr untersttzt. 800073 18. Mrz 2009 8.0-CURRENT, nachdem die dynamische Ersetzung von Zeichenkettenkrzeln fr rpath und bentigte Pfade implementiert wurde. 800074 24. Mrz 2009 8.0-CURRENT nach dem Einflieen von tcpdump 4.0.0 und libpcap 1.0.0. 800075 6. April 2009 8.0-CURRENT, nachdem die Deklarationen von struct vnet_net, struct vnet_inet und struct vnet_ipfw gendert wurden. 800076 9. April 2009 8.0-CURRENT nach dem Hinzufgen von Laufzeitprofilen in dummynet. 800077 14. April 2009 8.0-CURRENT nach dem Entfernen von VOP_LEASE() und vop_vector.vop_lease. 800078 15. April 2009 8.0-CURRENT, nachdem die Felder aus struct rt_weight zu struct rt_metrics und struct rt_metrics_lite hinzugefgt wurden, wobei die Deklaration von struct rt_metrics_lite gendert wurde. RTM_VERSION wurde hochgezhlt (zurckgezogen). 800079 15. April 2009 8.0-CURRENT, nachdem Pointer auf struct llentry zu struct route und struct route_in6 hinzugefgt wurden. 800080 15. April 2009 8.0-CURRENT nach nderung der Deklaration von struct inpcb. 800081 19. April 2009 8.0-CURRENT nach nderung der Deklaration von struct malloc_type. 800082 21. April 2009 8.0-CURRENT nach nderung der Deklaration von struct ifnet und Hinzufgen 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 nderungen an IPv6-SSM und MLDv2. 800085 30. April 2009 8.0-CURRENT, nachdem der Bau von VIMAGE-Kernel mit einem aktiven Image untersttzt wird. 800086 8. Mai 2009 8.0-CURRENT nach Hinzufgen der Untersttzung fr Eingabezeilen mit beliebiger Lnge durch patch(1). 800087 11. Mai 2009 8.0-CURRENT nach einigen nderungen im Zusammenhang mit dem VFS-KPI. Der Thread-Parameter wurde von den FSD-Teilen des VFS entfernt. VFS_*-Funktionen bentigen den Kontext nicht mehr, da er sich immer auf curthread bezieht. In wenigen Sonderfllen ist das bisherige Verhalten nicht gendert worden. 800088 20. Mai 2009 8.0-CURRENT nach nderungen am net80211-Monitormodus. 800089 23. Mai 2009 8.0-CURRENT nach dem Hinzufgen der Untersttzung von UDP-Kontrollblocks. 800090 23. Mai 2009 8.0-CURRENT nach der Virtualisierung der Schnittstellenklonierung. 800091 27. Mai 2009 8.0-CURRENT nach dem Hinzufgen von hierarchischen Jails und dem Entfernen des globalen securelevel. 800092 29. Mai 2009 8.0-CURRENT nach der nderung des sx_init_flags()-KPI. SX_ADAPTIVESPIN wurde zurckgezogen und eine neue Option SX_NOADAPTIVE wurde eingefhrt, um die umgekehrte Logik zu behandeln. 800093 29. Mai 2009 8.0-CURRENT nach dem Hinzufgen von mnt_xflag zu struct mount. 800094 30. Mai 2009 8.0-CURRENT nach dem Hinzufgen von &man.VOP.ACCESSX.9;. 800095 30. Mai 2009 8.0-CURRENT nach der nderung des Polling-KPI. Die Polling-Handler liefern nun die Zahl der verarbeiteten Pakete zurck. Die neue Option IFCAP_POLLING_NOCOUNT wurde weiter eingefhrt, um anzugeben, dass der Rckgabewert nicht von Bedeutung ist und das Zhlen der Pakete ausgelassen werden soll. 800096 1. Juni 2009 8.0-CURRENT nach der Aktualisierung der netisr-Implementierung und nachdem die Weise, wie FIBs gespeichert werden und wie auf sie zugegriffen wird, gendert wurde. 800097 8. Juni 2009 8.0-CURRENT nach Einfhrung der Destruktor-Infrastruktur fr vnet einschlielich Hooks. 800097 11. Juni 2009 8.0-CURRENT nach Einfhrung eines Erkennungssystems fr ausgehende Pakete, die direkt wieder in netgraph gelangen und deswegen eingereiht werden. Dabei wurde auch die Definition von struct thread gendert. 800098 14. Juni 2009 8.0-CURRENT nach dem Einflieen von OpenSSL 0.9.8k. 800099 22. Juni 2009 8.0-CURRENT nach der Aktualisierung von NGROUPS und dem Verschieben der Routing-Virtualisierung in ein eigenes VImage-Modul. 800100 24. Juni 2009 8.0-CURRENT nach nderung der SYSVIPC-ABI. 800101 29. Juni 2009 8.0-CURRENT nach dem Entfernen der zeichenorientierten Gerte aus /dev/net, von denen fr jede Schnittstelle eines existiert. 800102 12. Juli 2009 8.0-CURRENT, nachdem struct sackhint, struct tcpcb und struct tcpstat mit Padding-Bytes aufgefllt wurden. 800103 13. Juli 2009 8.0-CURRENT, nachdem struct tcpopt durch struct toeopt in der Schnittstelle zwischen dem TOE-Treiber und dem TCP-SYN-Cache ersetzt wurde. 800104 19. Juli 2009 8.0-CURRENT nach dem Hinzufgen einer vnet-spezifischen Speicherzuweisung, die auf dem Linker-Set-Verfahren basiert. 800105 19. Juli 2009 8.0-CURRENT nach der Inkrementierung der Versionsnummer aller Shared-Libraries, die Symbol-Versioning nicht aktiviert haben. 800106 24. Juli 2009 8.0-CURRENT nach Einfhrung des VM-Objekttyps OBJT_SG. 800107 2. August 2009 8.0-CURRENT nach Befreiung des Newbus-Subsystems von Giant durch Hinzufgen von sxlock und 8.0-RELEASE. 800108 21. November 2009 8.0-CURRENT nach Implementierung des kevent-Filters EVFILT_USER. 800500 7. Januar 2010 8.0-STABLE nach Erhhung von __FreeBSD_version, damit pkg_add -r packages-8-stable verwendet. 800501 24. Januar 2010 8.0-STABLE, nachdem die Prototypen von scandir(3) und alphasort(3) gendert wurden, um der SUSv4 zu entsprechen. 800502 31. Januar 2010 8.0-STABLE nach Hinzufgen von sigpause(3). 800503 25. Februar 2010 8.0-STABLE nach dem Hinzufgen der ioctls SIOCGIFDESCR und SIOCSIFDESCR fr Netzwerk-Schnittstellen. Diese ioctls knnen, nach dem Vorbild von OpenBSD, dazu verwendet werden, Schnittstellenbeschreibungen zu bearbeiten und auszulesen. 800504 1. Mrz 2010 8.0-STABLE, nachdem x86emu, ein Software-Emulator von OpenBSD fr x86-Prozessoren im Real-Mode, von CURRENT bernommen wurde. 800505 18. Mai 2010 8.0-STABLE nach dem Einflieen von liblzma, xz, xzdec und lzmainfo. 801000 14. Juni 2010 8.1-RELEASE 801500 14. Juni 2010 8.1-STABLE nach 8.1-RELEASE. 801501 November 3, 2010 8.1-STABLE nach der KBI-nderung in struct sysentve und der Implementierung von PL_FLAG_SCE/SCX/EXEC/SI und pl_siginfo fr ptrace(PT_LWPINFO) . 802000 22. Dezember 2010 8.2-RELEASE 802500 22. Dezember 2010 8.2-STABLE, nachdem 8.2-RELEASE erzeugt wurde. 802501 28. Februar 2011 8.2-STABLE, nachdem DTrace aktualisiert wurde (so wird nun auch Userland-Tracing untersttzt). 802502 6. Mrz 2011 8.2-STABLE, nachdem log2 und log2f in libm aufgenommen wurden. 802503 1. Mai 2011 8.2-STABLE, nachdem gcc auf die letzte unter der GPLv2 stehenden Version (aus dem FSF gcc-4_2-Zweig) aktualisiert wurde. 802504 28. Mai 2011 8.2-STABLE, nachdem KPI sowie die Infrastruktur zur Untersttzung 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-Untersttzung erweitert wurden. 802510 19. Juli 2011 8.2-STABLE, nach dem Hinzufgen des Flags RFTSIGZMB zu rfork(2). 900000 22. August 2009 9.0-CURRENT. 900001 8. September 2009 9.0-CURRENT nach dem Import von x86emu, einem Software-Emulator von OpenBSD fr x86-Prozessoren im Real-Mode. 900002 23. September 2009 9.0-CURRENT nach Implementierung des kevent-Filters EVFILT_USER. 900003 2. Dezember 2009 9.0-CURRENT nach Hinzufgen von sigpause(3) und der PIE-Untersttzung zu csu. 900004 6. Dezember 2009 9.0-CURRENT nach Hinzufgen von libulog und dessen libutempter-Kompatibilittsschnittstelle. 900005 12. Dezember 2009 9.0-CURRENT nach Hinzufgen von sleepq_sleepcnt(), das dazu verwendet werden kann, die Anzahl der in einer bestimmten Warteschlange eingereihten Threads abzufragen. 900006 4. Januar 2010 9.0-CURRENT, nachdem die Prototypen von scandir(3) und alphasort(3) gendert wurden, um der SUSv4 zu entsprechen. 900007 13. Januar 2010 9.0-CURRENT nach dem Entfernen von utmp(5) und dem Hinzufgen von utmpx (siehe getutxent(3)) zur besseren Erfassung von Benutzeranmeldungen und Systemereignissen. 900008 20. Januar 2010 9.0-CURRENT nach der Einfhrung von BSDL bc/dc zur Ersetzung von GNU bc/dc. 900009 26. Januar 2010 9.0-CURRENT nach dem Hinzufgen der ioctls SIOCGIFDESCR und SIOCSIFDESCR fr Netzwerk-Schnittstellen. Diese ioctls knnen, nach dem Vorbild von OpenBSD, dazu verwendet werden, Schnittstellenbeschreibungen zu bearbeiten und auszulesen. 900010 22. Mrz 2010 9.0-CURRENT nach dem Import von zlib 1.2.4. 900011 24. April 2010 9.0-CURRENT nach Hinzufgen von Soft Updates Journaling. 900012 10. Mai 2010 9.0-CURRENT nach Hinzufgen 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 Hinzufgen 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 hinzugefgt wurde. 900017 23. August 2010 9.0-CURRENT nach dem Zurckkehren zu GNU grep als Standard und Hinzufgen der Option WITH_BSD_GREP. 900018 24. August 2010 9.0-CURRENT, nachdem das von 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 Hinzufgen des Schalters MAP_PREFAULT_READ zu mmap(2). 900020 9. September 2010 9.0-CURRENT, nachdem drain-Funktionalitt in sbufs integriert wurde (wodurch sich auch das Layout von struct sbuf gendert hat). 900021 13. September 2010 9.0-CURRENT, nachdem Userland tracing in DTrace eingefhrt wurde. 900022 2. Oktober 2010 9.0-CURRENT nach Hinzufgen der BSDL 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 Einfhrung von modularised congestion control. 900026 30. November 2010 9.0-CURRENT nach der Einfhrung von 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 hinzugefgt wurde. 900028 21. Dezember 2010 9.0-CURRENT, nach dem HInzufgen von Hhook (Helper Hook), Khelp (Kernel Helpers) und Object Specific Data (OSD) KPIs. 900029 28. Dezember 2010 9.0-CURRENT, nach der TCP-Stack modifiziert wurde, um es den Khelp-Modulen zu erlauben, mit ihm 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 Hinzufgen von pthread_getthreadid_np(3). 900032 8. Februar 2011 9.0-CURRENT, nachdem Prototyp und Symbol fr uio_yield entfernt wurden. 900033 18. Februar 2011 9.0-CURRENT, nachdem die binutils auf Version 2.17.50 aktualisiert wurden. 900034 8. Mrz 2011 9.0-CURRENT, nachdem die Struktur sysvec (sv_schedtail) modifiziert wurde. 900035 29. Mrz 20111 9.0-CURRENT, nach dem Update des im Basissystem enthaltenen gcc sowie von libstdc++ auf die letzten unter GPLv2 lizenzierten Versionen. 900036 18. April 2011 9.0-CURRENT, nachdem libobjc und die Untersttzung fr Objective-C aus dem Basissystem entfernt wurden. 900037 13. Mai 2011 9.0-CURRENT, nach dem Import der 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) hinzugefgt wurde. 900039 28. Juni 2011 9.0-CURRENT, nachdem pf von OpenBSD 4.5 importiert wurde. 900040 19. Juli 2011 Standardmige Erhhung von MAXCPU fr &os; auf 64 fr amd64 und ia64 und auf 128 fr XLP (mips). 900041 13. August 2011 9.0-CURRENT, nachdem Capsicum-Funktionalitten implementiert wurden. Zustzlich wurde fget(9) um ein Rechte-Argument erweitert. 900042 28. August 2011 Versionssprnge fr Shared-Libraries deren ABI sich gendert hat, in Vorbereitung fr 9.0. 900043 2. September 2011 Automatische Erkennung von USB-Massenspeicher Gerten, die das no synchronize cache SCSI Kommando nicht untersttzen. 900044 10. September 2011 Re-factor auto-quirk. 900045 13. Oktober 2011 Allen nicht-kompatiblen Systemaufruf-Einstiegspunkten wurde ein sys_ vorangestellt.
Beachten Sie, dass 2.2-STABLE sich nach dem 2.2.5-RELEASE manchmal als 2.2.5-STABLE identifiziert. Das Muster war frher 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 unmglich 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 kmmern; diese sind hier nur als Referenz augefhrt. Etwas hinter die <filename>bsd.port.mk</filename>-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 einfgen. Sie drfen entweder nur das bsd.port.pre.mk/bsd.port.post.mk-Paar oder bsd.port.mk alleine hinzufgen; vermischen Sie diese Verwendungen nicht! bsd.port.pre.mk definiert nur einige Variablen, welche in Tests im Makefile benutzt werden knnen, bsd.port.post.mk definiert den Rest. Hier sind einige wichtige Variablen, welche in bsd.port.pre.mk definiert sind (dies ist keine vollstndige Liste, lesen Sie bitte bsd.port.mk fr eine vollstndige Auflistung). Variable Beschreibung ARCH Die Architektur, wie von uname -m zurckgegeben (z.B. i386) OPSYS Der Typ des Betriebsystems, wie von uname -s zurckgegeben (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. PORTOBJFORMAT Das Objektformat des Systems (elf oder aout; beachten Sie, dass fr 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 ber PREFIX). Falls Sie die Variablen USE_IMAKE, USE_X_PREFIX, oder MASTERDIR definieren mssen, sollten Sie dies vor dem Einfgen von bsd.port.pre.mk machen. Hier sind ein paar Beispiele von Dingen, die Sie hinter die Anweisung bsd.port.pre.mk schreiben knnen: # 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 fr 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 Verknpfung f ELF, aber nicht f 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? :-). Benutzen Sie die <function>exec</function>-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 dafr 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 whrend das Programm ausgefhrt wird und verbraucht unntig Systemressourcen. Aufgaben vernnftig lsen Das Makefile sollte die ntigen Schritte einfach und vernnftig durchfhren. Wenn Sie ein einige Zeilen einsparen oder die Lesbarkeit verbessern knnen, 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 mssen, um etwas zu testen, sollten Sie zuerst bsd.port.mk erneut konsultieren und nachprfen ob es nicht bereits eine Lsung fr Ihr Problem enthlt. Es ist zwar schwer zu lesen, beinhaltet jedoch eine Menge kurzer Lsungen fr viele scheinbar schwierige Probleme. Bercksichtigen Sie sowohl <varname>CC</varname> als auch <varname>CXX</varname> Der Port sollte sowohl die CC- wie auch die CXX-Variable bercksichtigen. Damit ist gemeint, dass der Port diese Variablen nicht ohne Rcksicht auf eventuell schon gesetzte Werte einfach berschreiben sollte; stattdessen sollten neue Werte an schon existierende angehngt werden. Dadurch knnen Build-Optionen, die alle Ports betreffen, global definiert werden. Falls der Port diese Variablen nicht bercksichtigt, sollte NO_PACKAGE=ignores either cc or cxx ins Makefile eingefgt werden. Im Folgenden wird ein Beispiel eines Makefiles gezeigt, welches die beiden Variablen CC und CXX bercksichtigt. Beachten Sie das ?=: CC?= gcc CXX?= g++ Nachfolgend ein Beispiel, welches weder CC noch CXX bercksichtigt: CC= gcc CXX= g++ Die Variablen CC und CXX knnen 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 bercksichtigen. Im zweiten Beispiel werden die Variablen ohne Rcksicht berschrieben. Bercksichtigen Sie <varname>CFLAGS</varname> Der Port sollte die Variable CFLAGS bercksichtigen. Damit ist gemeint, dass der Port den Wert dieser Variablen nicht absolut setzen und damit existierende Werte berschreiben sollte; stattdessen sollte er weitere Werte der Variablen durch Anhngen hinzufgen. Dadurch knnen Build-Optionen, die alle Ports betreffen, global definiert werden. Falls der Port diese Variablen nicht bercksichtigt, sollte NO_PACKAGE=ignores cflags ins Makefile eingefgt werden. Im Folgenden wird ein Beispiel eines Makefiles gezeigt, welches die Variable CFLAGS bercksichtigt. Beachten Sie das +=: CFLAGS+= -Wall -Werror Nachfolgend finden Sie ein Beispiel, welches die CFLAGS-Variable nicht bercksichtigt: 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 angehngt und somit der bestehende Wert nicht gelscht. Im zweiten Beispiel wird die Variable ohne Rcksicht berschrieben. Sie sollten Optimierungsflags aus Makefiles Dritter entfernen. Die CFLAGS des Systems beinhalten systemweite Optimierungsflags. Ein Beispiel eines unvernderten Makefiles: CFLAGS= -O3 -funroll-loops -DHAVE_SOUND Werden nun systemweite Optimierungsflags verwendet so wrde das Makefile in etwa folgendermaen aussehen: CFLAGS+= -DHAVE_SOUND Threading-Bibliotheken Die Threading-Bibliothek muss mit Hilfe eines speziellen Linker-Flags -pthread in die Binrdateien unter &os; 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 blicherweise den Wert -pthread, kann aber auf einigen Architekturen und &os;-Versionen abweichende Werte haben und daher sollte nie -pthread direkt in Patches geschrieben werden, sondern immer PTHREAD_LIBS. 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 untersttzt. Rckmeldungen Brauchbare nderungen/Patches sollten an den ursprnglichen Autor/Maintainer der Software geschickt werden, damit diese in der nchsten Version der Software mit aufgenommen werden knnen. Dadurch wird Ihre Aufgabe fr die nchste Version der Software deutlich einfacher. <filename>README.html</filename> Nehmen Sie bitte keine README.html in den Port auf. Diese Datei ist kein Bestandteil der CVS-Sammlung sondern wird durch make readme erzeugt. Einen Port durch <varname>BROKEN</varname>, <varname>FORBIDDEN</varname> oder <varname>IGNORE</varname> als nicht installierbar markieren In manchen Fllen sollten Benutzer davon abgehalten werden einen Port zu installieren. Um einem Benutzer mitzuteilen, dass ein Port nicht installiert werden sollte, gibt es mehrere Variablen fr make, die im Makefile des Ports genutzt werden knnen. Der Wert der folgenden make-Variablen wird dem Benutzer als Grund fr die Ablehnung der Installation des Ports zurckgegeben. Bitte benutzen Sie die richtige make-Variable, denn jede enthlt eine vllig andere Bedeutung fr den Benutzer und das automatische System, das von dem Makefile abhngt, wie der Ports-Build-Custer, FreshPorts und portsmon. Variablen BROKEN ist reserviert fr Ports, welche momentan nicht korrekt kompiliert, installiert oder deinstalliert werden. Es sollte fr Ports benutzt werden, von denen man annimmt, dass dies ein temporres 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 auerhalb von ${LOCALBASE} installiert beim Deinstallieren nicht alle seine Dateien sauber entfernt (jedoch kann es akzeptable und wnschenswert sein, Dateien, die vom Nutzer verndert wurden, nicht zu entfernen) FORBIDDEN wird fr Ports verwendet, die Sicherheitslcken enthalten oder die ernste Sicherheitsbedenken fr das FreeBSD-System aufwerfen, wenn sie installiert sind (z.B. ein als unsicher bekanntes Programm, oder ein Programm, das einen Dienst zur Verfgung stellt, der leicht kompromittiert werden kann). Ports sollten als FORBIDDEN gekennzeichnet werden, sobald ein Programm eine Schwachstelle hat und kein Update verffentlicht wurde. Idealerweise sollten Ports so bald wie mglich aktualisiert werden wenn eine Sicherheitslcke entdeckt wurde, um die Zahl verwundbarer FreeBSD-Hosts zu verringern (wir schtzen es fr 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 auer Sicherheit als FORBIDDEN. IGNORE ist fr Ports reserviert, die aus anderen Grnden nicht gebaut werden sollten. Es sollte fr Ports verwendet werden, in denen ein strukturelles Problem vermutet wird. Der Build-Cluster wird unter keinen Umstnden Ports, die mit IGNORE markiert sind, erstellen. Verwenden Sie IGNORE zum Beispiel, wenn ein Port: kompiliert, aber nicht richtig luft nicht auf der installierten Version von &os; luft &os; Kernelquelltext zum Bauen bentigt, aber der Benutzer diese nicht installiert hat ein Distfile bentigt, welches aufgrund von Lizenzbeschrnkungen nicht automatisch abgerufen werden kann nicht korrekt mit einem momentan installiertem Port arbeitet (der Port hngt zum Beispiel von www/apache21 ab, aber www/apache13 ist installiert) 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 selbststndig. Um einen Port nur auf bestimmte Systemarchitekturen mit IGNORE zu markieren, gibt es zwei Variablen, die automatisch IGNORE fr 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. Fr eine bestimmte Architektur sind Angaben durch ONLY_FOR_ARCHS_REASON_ARCH und NOT_FOR_ARCHS_REASON_ARCH mglich. Wenn ein Port i386-Binrdateien herunterldt und installiert, sollte IA32_BINARY_PORT gesetzt werden. Wenn die Variable gesetzt ist, wird berprft, ob das Verzeichnis /usr/lib32 fr IA32-Versionen der Bibliotheken vorhanden ist, und ob der Kernel mit IA32-Kompatibilitt gebaut wurde. Wenn eine dieser zwei Voraussetzungen nicht erfllt ist, wird IGNORE automatisch gesetzt. Anmerkungen zur Implementierung Zeichenketten sollten nicht in Anfhrungszeichen 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. Kennzeichnen eines Ports zur Entfernung durch <varname>DEPRECATED</varname> oder <varname>EXPIRATION_DATE</varname> Denken Sie bitte daran, dass BROKEN und FORBIDDEN nur als temporrer Ausweg verwendet werden sollten, wenn ein Port nicht funktioniert. Dauerhaft defekte Ports sollten komplett aus der Ports-Sammlung entfernt werden. Wenn es sinnvoll ist, knnen 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 mglich 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. Gegenwrtig ist es blich einen Monat fr sicherheitsrelevante Probleme und zwei Monate fr Build-Probleme anzusetzen. Dies gibt allen interessierten Committern ein wenig Zeit die Probleme zu beheben. Vermeiden Sie den Gebrauch des <literal>.error</literal>-Konstruktes Der korrekte Weg eines Makefile anzuzeigen, dass der Port aufgrund eines externen Grundes nicht installiert werden kann (zum Beispiel, weil der Benutzer eine ungltige 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 fr diesem Zweck zu verwenden. Das Problem dabei ist, dass viele automatisierte Werkzeuge, die mit dem Ports-Baum arbeiten, in dieser Situation fehlschlagen. Am Hufigsten tritt das Problem beim Versuch /usr/ports/INDEX zu bauen auf (siehe ). Jedoch schlagen auch trivialere Befehle wie make maintainer in diesem Fall fehl. Dies ist nicht akzeptabel! Wie vermeidet man die Verwendung von <literal>.error</literal> Nehmen Sie an, dass die Zeile USE_POINTYHAT=yes in make.conf enthalten ist. Der erste der folgenden zwei Makefile-Schnipsel lsst make index fehlschlagen, whrend der zweite dies nicht tut. .if USE_POINTYHAT .error "POINTYHAT is not supported" .endif .if USE_POINTYHAT IGNORE=POINTYHAT is not supported .endif Verwendung von <filename>sysctl</filename> Vom Gebrauch von sysctl wird, auer in Targets, abgeraten. Das liegt daran, dass die Auswertung aller makevars, wie sie whrend make index verwendet werden, dann den Befehl ausfhren muss, welches den Prozess weiter verlangsamt. Die Verwendung von &man.sysctl.8; sollte immer durch die Variable SYSCTL erfolgen, da diese den vollstndigen Pfad enthlt und berschrieben werden kann, so dies als notwendig erachtet wird. Erneutes Ausliefern von Distfiles Manchmal ndern die Autoren der Software den Inhalt verffentlichter Distfiles, ohne den Dateinamen zu ndern. Sie mssen berprfen, ob die nderungen offizell sind und vom Autor durchgefhrt wurden. Es ist in der Vergangenheit vorgekommen, dass Distfiles still und heimlich auf dem Download-Server gendert 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 &man.diff.1;. Wenn Sie nichts Verdchtiges sehen knnen Sie distinfo aktualisieren. Stellen Sie sicher, dass die nderungen in Ihrem PR oder Commit-Protokoll zusammengefasst sind, um zu Gewhrleisten, dass nichts Negatives passiert ist. Sie knnen auch mit den Autoren der Software in Verbindung treten und sich die nderungen besttigen lassen. Verschiedenes Die Dateien pkg-descr und pkg-plist sollten beide doppelt kontrolliert werden. Wenn Sie einen Port nachprfen 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 berprfen Sie alle gesetzlichen Punkte grndlich! Lassen Sie uns bitte keine illegale Software verbreiten! Beispiel eines <filename>Makefile</filename> Hier ein Beispiel fr ein Makefile, welches als Vorlage fr einen neuen Port dienen kann. Alle zustzlichen Kommentare in eckigen Klammern mssen entfernt werden! Es wird empfohlen, die hier gezeigte Formatierung zu bernehmen (Reihenfolge der Variablen, Leerzeichen zwischen einzelnen Abschnitten, usw.). Dadurch werden die wichtigen Informationen sofort ersichtlich. Zur berprfung 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> Auf dem Laufenden bleiben Die &os; Ports-Sammlung verndert sich stndig. Hier finden Sie einige Informationen, wie Sie auf dem Laufenden bleiben. FreshPorts Einer der einfachsten Wege, um sich ber Aktualisierungen, die bereits durchgefhrt wurden, zu informieren, ist sich bei FreshPorts anzumelden. Sie knnen dort beliebige Ports auswhlen, die Sie beobachten mchten. Maintainern wird ausdrcklich empfohlen sich anzumelden, da Sie nicht nur ber Ihre eigenen nderungen informiert werden, sondern auch ber die aller anderen Committer (Diese sind oft ntig, um ber nderungen des zugrunde liegenden Frameworks informiert zu bleiben. Obwohl es hflich wre, vorher ber solche nderungen benachrichtigt zu werden, wird es manchmal vergessen oder ist einfach nicht mglich. Auerdem sind die nderungen manchmal nur sehr klein. Wir erwarten von jedem in solchen Fllen nach bestem Gewissen zu urteilen). Wenn Sie Fresh-Ports benutzen mchten, bentigen 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, knnen einfach Ihre E-Mailadresse auf @FreeBSD.org ndern, sich anmelden, und dann die nderung rckgngig machen. FreshPorts bietet auch eine berprfungsfunktion, die automatisch alle Committs zum &os; Ports-Baum testet. Wenn Sie sich fr diesen Dienst anmelden, werden Sie ber alle Fehler, die bei der berprfung Ihres Committs auftreten, informiert. Die Webschnittstelle zum Quelltext-Repository Es ist mglich die Dateien des Quellen-Repositories mit Hilfe einer Webschnittstelle durchzusehen. 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 magebliche Antwort auf alle Fragen liegt zweifellos darin, den Quelltext von bsd.port.mk und dazugehrige Dateien zu lesen. Die &os; Ports-Mailingliste Wenn Sie Maintainer sind, sollten Sie in Erwgung ziehen die &a.ports;-Mailingliste zu verfolgen. Wichtige nderungen an der grundlegenden Funktionsweise von Ports werden dort angekndigt und dann in CHANGES committet. Der Cluster zum Bauen von &os;-Ports auf <systemitem class="fqdomainname">pointyhat.FreeBSD.org</systemitem> Eine der weniger bekannten Strken von &os; ist es, dass ein ganzer Cluster von Maschinen nur dafr reserviert ist, andauernd die Ports-Sammlung zu bauen, und zwar fr jedes groe &os; Release und jede Tier-1-Architektur. Die Ergebnisse knnen 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 gelst wurde (Dies wird erreicht, indem TRYBROKEN an das Makefile des Ports bergeben wird). Der &os; 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 stndig verndert, - knnen Distfiles schnell verloren gehen. Der FreeBSD - Ports-Distfile-Scanner versucht jeden + Da sich das Internet aber stndig verndert, knnen Distfiles + schnell verloren gehen. Der FreeBSD + Ports-Distfile-Scanner versucht jeden Download-Standort fr jeden Port anzufragen, um herauszufinden, ob jedes Distfile noch verfgbar ist. Maintainer werden gebeten diesen Bericht regelmig durchzusehen, nicht nur, um den Build-Prozess fr die Nutzer zu beschleunigen, sondern auch um zu vermeiden, dass auf den Maschinen, die freiwillig zur Verfgung gestellt werden, um all diese Dateien anzubieten, Ressourcen verschwendet werden. Das &os; 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 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-Prfung und weitere Informationsquellen ausgedehnt werden. Als Ausgangspunkt knnen Sie alle Informationen eines Ports mit Hilfe der bersicht eines Ports betrachten. Zum Zeitpunkt des Schreibens ist dies die einzige Quelle, die GNATS PR-Eintrge auf Portnamen abbildet (PR-Einreicher geben den Portnamen nicht immer in der Zusammenfassung an, obwohl wir uns das wnschen wrden). 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. Index: head/zh_CN.UTF-8/books/porters-handbook/book.xml =================================================================== --- head/zh_CN.UTF-8/books/porters-handbook/book.xml (revision 52709) +++ head/zh_CN.UTF-8/books/porters-handbook/book.xml (revision 52710) @@ -1,14227 +1,14227 @@ FreeBSD Porter 手册 The FreeBSD Documentation Project 2000 年 4 月 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 The FreeBSD Documentation Project &cnproj.freebsd.org; 2005 年 11 月 2005 2006 2007 2008 2009 2010 2011 &cnproj.freebsd.org; &trademarks; &legalnotice; $FreeBSD$ 介绍 几乎每个人都是通过 FreeBSD Ports Collection 在 FreeBSD 上面装应用程序 (“ports”)的。 就像FreeBSD的其它部分一样， 它主要来自于志愿者的努力。 所以在阅读这份文档的时候请务必记住这些。 在 FreeBSD 的世界里， 任何人都能提交新的 port， 或志愿地维护一个已有的 port， 如果那个 port 没人维护的话 — 不需要任何特殊的权限来做这件事情。 自行制作新 port 那么， 您有兴趣创建自己的 port 或升级现有的 port？ 太好了。 下面的内容将会提供一些创建FreeBSD port的指导。 如果想升级一个现有的 port， 那么您应该在看完这些内容并阅读 。 因为这份文档不是十分详细， 您还应该再参考一下 /usr/ports/Mk/bsd.port.mk， 所有 port 的 Makefile 文件都会包含它。 即使不是每天都去摆弄 Makefile， 您也会从那个文件里面获得很多知识， 里面的注释非常详细。 还有要补充一下，如果您有其它的问题， 可以给&a.ports; 这个 mailing list 发信。 在这份文档里提到的大部分的变量 (VAR) 是不能修改的。 大多 (但不是全部) 都在 /usr/ports/Mk/bsd.port.mk 的开始部分进行了介绍； 其它一些也应该可以在那里找到。 注意这些文件使用了非标准的制表符： Emacs 和 Vim 应该能在打开文件的时候自动识别它， 而 &man.vi.1; 和 &man.ex.1; 则需要在打开文件的时候通过 :set tabstop=4 来修正默认的设置。 想练练手吗？ 请参阅我们的 希望移植的软件列表 来看看您是否有兴趣完成其中的任务。 简单的 port 这一章将介绍如何快速创建一个全新的 port。 很多时候， 这点内容是不够的， 您需要阅读这份文档中更深入的内容。 首先， 需要取得包含源代码的 tar包， 并把它放到 DISTDIR变量所指的地方。 默认的情况下， 这应该是 /usr/ports/distfiles。 下面的内容假定您不需要修改软件的源代码就能在 FreeBSD 上编译通过。 如果需要修改代码， 就需要参考下一章的内容了。 编写 <filename>Makefile</filename> 最简单的 Makefile 应该是这个样子的： # 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> 看看您是否能够看懂。 不必担心 $FreeBSD$ 那一行， 当这个 port 被导入到 ports 树里的时候， CVS 会自动填写它。 您可以在 示范的 Makefile那章找到更多的细节。 创建描述文件 有 2 个描述文件对于任何一个 port 来说是必须的， 不论它是不是打算成为 package。 它们是 pkg-descr 和 pkg-plist。 这两个文件使用 pkg- 前缀以区别于其它文件。 <filename>pkg-descr</filename> (关于 port 的冗长描述文件) 这是 port 里一个较长的描述文件。 使用一段或几段文件文字来简明的描述这个 ports 是用来做什么的。 这 不是 手册或者对如何 深入使用/编译这个port的说明！ 要是您从 README 或者联机手册里面中复制文字的话， 请务必小心； 通常， 它们不是对这个 port 简明扼要的描述， 或者用了难以使用的格式 (比如， 联机手册里有迫使两端对齐的空格)。 如果要移植的软件有官方的WWW网页， 您应该在这里列出来。 使用 WWW: 作为前缀来表示 一个网站， 这样其它的自动工具就能正常工作了。 下面是一个简单的 pkg-descr 例子： This is a port of oneko, in which a cat chases a poor mouse all over the screen. : (etc.) WWW: http://www.oneko.org/ <filename>pkg-plist</filename> (port 的装箱单) 这份文件列出了 port 所要安装的所有文件。 由于 package 也是据此进行打包， 因此它也被称作 装箱单(packing list). 这个文件中， 路径是相对于安装的路径的 (通常是 /usr/local 或 /usr/X11R6)。 如果您使用 MANn 变量的话， 请不要在这里列出任何联机手册。 假如 port 在安装过程中会创建一些目录， 请务必增加对应的 @dirrm 行， 以便在 package 被卸载时予以自动删除。 下面是一个简单的例子： 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 参考 &man.pkg.create.1; 的联机手册以获得更多有关装箱单的细节 建议您将这个文件里的所有的文件名按字母排序。 这样， 在升级这个port的时候就能够更方便地核实所做的修改。 手工创建这样一份列表可能是一件非常枯燥的事情。 如果您的 port 需要安装大量的文件， 自动创建装箱单 会帮您省下不少时间。 只有一种情况可以不用 pkg-plist文件。 如果这个 port 只安装很少量的一些文件或目录的话， 这些文件和目录就可以分别列在 Makefile 的 PLIST_FILES和PLIST_DIRS 变量里。 举个例子来说， 我们可以在上面那个 oneko port 里面不用 pkg-plist， 而把下面的这几行加到 Makefile 里面： 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 当然， 如果一个 port 不需要给它自己创建目录的话， 就不用设置 PLIST_DIRS 变量了。 不过， 如果用这种方式来列出 port 要安装的文件和目录的话， 也就无法利用在 &man.pkg.create.1; 里介绍的命令来制作 package 了。 因此， 这种方法只适用于那些简单的 port， 使它们更为简化。 同时， 这种做法也有助于减少 ports collection 中的文件数量。 在采用 pkg-plist 之前， 请考虑一下使用这种方法。 稍后我们将看到 pkg-plist 以及 PLIST_FILES 如何处理 更复杂的任务。 创建校验和文件 只要键入 make makesum， port 便会自动创建 distinfo文件。 如果下载的文件的校验和经常变化， 而您又能确保它们的来源可靠 (比如， 来自于CD制造商， 或每天联编生成的文档文件)， 就应该在 IGNOREFILES 里面标明这些文件。 这样， 再运行 make makesum 的时候便不会把这些标记 IGNORE 的文件计算在内了。 测试 port 应当确定您的 port 确实做了您希望它们做的事情， 包括打包。下面是需要重点检查的一些重要的工作。 pkg-plist 中没有包括任何不想安装的文件 pkg-plist 包含了所有应该安装的文件 您的 port 能够使用 reinstall 多次安装。 您的 port 能在卸载 (deinstall) 时， 自动完成 清理 推荐的测试顺序 make install make package make deinstall pkg_add package-name make deinstall make reinstall make package 确信在 package 和 deinstall 阶段没有任何警告。 第三步以后， 检查是否所有新建的目录都被正确删除了。 在第四步以后， 试着运行一下所装的软件， 确保当它以 package 方式安装的时候也能正常工作。 自动化这些步骤最简单的方法是通过 ports tinderbox 来进行测试。 它可以维护 jails 并在其中完成全部测试工作， 而不会破坏正在运行的系统的状态。 请参见 ports/ports-mgmt/tinderbox 以了解更多的信息。 用 <command>portlint</command> 来检查 port 请使用 portlint 命令来检查您的 port 是否符合我们的规范。 ports-mgmt/portlint 程序是 ports 套件的一部分。 这个程序的主要功能是帮助您检查 Makefile 的样式是否符合规范， 以及 package 的命名是否得体。 提交新 port 在提交新 port 之前， 应先阅读 该做什么和不该做什么 一节。 既然已经对所制作的 port 相当满意了， 剩下的工作， 便是将它放进 &os; 的主 ports 树， 以便让更多的人从中受益。 我们并不需要您的 work 目录以及 pkgname.tgz 包， 因此现在可以删除它们了。 假定您的 port 的名字是 oneko， 接下来要做的是 cd 到 oneko 所在的目录， 然后输入命令： shar `find oneko` > oneko.shar 将这个 oneko.shar 文件作为附件， 使用 &man.send-pr.1; 程序提交 (请参阅 Bug Reports and General Commentary 以了解关于 &man.send-pr.1; 的进一步详情) 将其送出。 请务必将您的 bug 报告分类 (category) 为 ports 并把子分类 (class) 设置为 change-request (不要把报告表及为机密的， 即 confidential！)。 此外， 在 PR 的描述 (Description) 一栏中的内容应该是 port 的简要介绍 (例如 COMMENT 内容的简化版本)， 而 shar 文件则应填入修正 (Fix) 栏中。 在问题报告里面使用了一段好的描述， 能使我们的工作变得更容易。 习惯上， 我们会使用类似： New port: <category>/<portname> <short description of the port> 这样的标题来说明这是新的 port。 如果您也使用这样的习惯， 那么我们将更容易更方便地阅读您的 PR， 从而加快处理速度。 再次声明， 不要包含原始的distfile， work目录， 或者您用 make package 制作的包； 此外， 对于新的 port 请务必使用 &man.shar.1; 而不是 &man.diff.1;。 在您提交的您的 port 以后请耐心等待。 有时在一个 port 正式加入 &os; 之前需要花费好几个月， 尽管也有可能是几天。 您可以查看 正等待被 commit 到 &os; 的 port PR。 一旦我们看过了您的报告， 有必要的话我们会联系您， 并把它放到 ports 树里。 您的名字也会出现在 Additional FreeBSD Contributors 和其它的文件。 不是很棒吗!? :-) 复杂的 Porting 好了， 也许工作没那么简单， port 需要做些修改才能够在 FreeBSD 上跑起来。 在这一章里， 我们将会一步步举例来介绍应该如何修改来使您的 port 能在 FreeBSD 上面运行。 整个系统是如何运转的? 首先， 这一系列的动作是由用户在您的 port 目录里敲入 make 后发生的。 您也许会发现在另外的一个窗口里阅读一下 bsd.port.mk 将会有助于您的理解。 要是您不是非常明白 bsd.port.mk 是做什么的话， 也不用太担心， 很多人都不知道的... :-> fetch 会首先被执行。 fetch 将检查在本地的 DISTDIR 目录里是否存在 tar 包。 如果 fetch 没有找到就会查找 Makefile 中定义的 MASTER_SITES URL， 还有我们的主 FTP 站点 ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/， 在那里我们备份了所有被认可的 distfile。 假设那个 MASTER_SITES 站点是直接连在 Internet 上的， 就会试着用 FETCH 指定的程序取回 distfile。 如果成功的话， 文件会被保存在DISTDIR 所指定的目录以备稍后使用。 接下来会执行 extract。 它会在 DISTDIR 中寻找您的 tar 包 (通常是用 gzip 压缩的 tar 包)，然后解压缩到由 WRKDIR 所指定的临时目录里 (默认为work目录)。 下一步是执行 patch。 首先任何在 PATCHFILES 中定义的补丁都会被打上。 然后， 在由 PATCHDIR 指定的目录 (默认为 files目录) 中发现的patch-*， 它们将会以文件名的字母顺序被先后打上。 configure会被执行。 这一步骤可能会有以下几种情形。 如果存在 scripts/configure， 就会执行它 如果定义了 HAS_CONFIGURE 或者 GNU_CONFIGURE， 就会执行 WRKSRC/configure。 如果定义了USE_IMAGE， 就会执行 XMKMF (默认为: xmkmf -a)。 build会被执行。 这一步将会进入ports的工作目录 (WRKSRC) 然后进行编译。如果定义了USE_GMAKE， 就会使用 GNU make， 反之， 则会使用系统默认的 make。 以上都是系统默认的步骤。 您也可以定义 pre-something 或者 post-something， 或者把以此命名的脚本放到 scripts 目录， 它们会在默认的动作之前或之后被执行。 举个例子， 如果您在您的 Makefile 里定义了post-extract， 并在 script 目录里放了一个 pre-build 脚本， 那么在 tar 包解开之后 post-extract 将被调用， pre-build 脚本会在默认的编译之前被执行。 我们推荐您在 Makefile 定义所有的动作， 如果不是十分复杂的话， 这样， 别人能更容易明白您的 port 需要执行哪些非默认的动作。 默认的行为都是由 bsd.port.mk 定义的 do-something 来表示的。 例如， port 中用来解压缩的命令是由 do-extract 来定义的。 如果您对默认的设置不满意， 可以通过在 Makefile 重新定义 do-someting 来做些改变。 主 动作 (例如 extract、 configure， 等等) 仅仅是用来确定所有相应的阶段都完成了， 以及调用真实的动作或脚本， 它们不应被修改。 如果您想要修改解压缩这个动作， 可以修改 do-extract， 但永远都不要改变 extract 的操作！ 我们已经介绍了在用户敲入 make 之后会发生哪些事情了。 接下来我们将进行进一步的学习， 来看一看如何创建一个理想的 port。 获取源代码 获取源代码的 tar 包 (通常是 foo.tar.gz 或者 foo.tar.Z) 并把它们放进 DISTDIR。 最好使用 主流 的版本。 您需要设置变量 MASTER_SITES 来指向原始 tar 包的获取位置。 您可以在 bsd.sites.mk 里找到一些速度较快的主流站点。 请使用这些站点 — 和相关的定义 — 如果可能的话， 应尽量避免在同一个源代码树里出现大量重复的信息。 这些站点会随着时间而变化， 如果每个人都随意加入的话会使维护变得非常困难。 如果您找不到一个有很好网络连接的 FTP/HTTP 站点， 或者它们使用了非标准的格式， 您也许就会想在您自己的 FTP 或 HTTP 服务器上放上一份副本。 如果您找不到可靠的地方放置 distfiles， 我们也可以提供给您一些空间来保存它。 我们自己的 ftp.FreeBSD.org； 然而这只是一个折衷的办法。 distfile 必须放进某人在 freefall 上的 ~/public_distfiles/ 目录中。 可以要求帮助您 commit port 的人来放这个 distfile， 而这个人也需要把 MASTER_SITES、 MASTER_SITE_LOCAL 以及 MASTER_SITE_SUBDIR 的设置， 改为在 freefall 上的用户名。 如果您的 port 的 distfile 一直在变化， 而作者拒绝改变其版本号， 您可以考虑把 distfiles 放在自己的主页， 并在 MASTER_SITES 里把原作者的列为首选位置。 如果可能， 试着与 port 的作者沟通一下让他不要这么做， 这将有助于建立对源代码的控制。 在您的主页上放置您自己的 distfile 会避免用户得到 checksum mismatch 的错误， 而且能减轻我们 FTP 站点维护人员的工作量。 如果您的port只有一个主站点的话， 我们建议您在自己的网站上做一份备份， 并他列为 MASTER_SITES的第2项。 如果您的 port 需要来自网络上的一些补丁， 请把它们放到 DISTDIR里。 不用担心它们跟源代码不是来自同一站点。 我们有办法处理 (参阅下面的 补丁文件)。 修改 port 解开 tar 包， 对源代码做出合理的修改使得这个 port 能在最新版本的 &os; 上面运行。 一定要 仔细记录 您所做的每处改动， 包括删除、添加、修改的文件等等， 这些修改以后会在您的 port 中以脚本或补丁的方式出现， 并且能通过运行它们来自动完成您对 port 的改动要求。 如果您的 port 要求用与用户交互/配置来完成编译或安装的话， 您可以看一下 Larry Wall 的经典的 Configure 脚本， 适当地模仿一下。 Port collection 的目的， 就是使每个 port 占用最少的空间， 并做到软件的 即插即用。 除非明确地声明， 否则您提交给 &os; ports collection 的补丁， 脚本和其它的文件都将以标准的 BSD 版权发布。 打补丁 在您准备制作 port 的过程中， 增加或修改的文件， 都可以通过 &man.diff.1; 来做成补丁。 希望应用到源代码上的每个补丁， 都应保存为单独的文件， 并命名为 patch-*， 其中 * 表示将要修改的文件的完整路径名， 例如 patch-Imakefile 或 patch-src-config.h。 这些文件， 都应保存在 PATCHDIR (通常是 files/)， 这里的补丁都会自动应用到源代码上。 所有的补丁必须是相对于 WRKSRC 的 (一般而言， 您的 port 会将其 tarball 解压缩在那里， 并完成余下的工作)。 为了让修正和升级更容易， 您应避免使用多个 patch 去修改同一个文件 (例如， patch-file 以及 patch-file2 都修改 WRKSRC/foobar.c) 这种情况。 需要注意的是， 如果修改的文件的路径中包含下划线 (_) 字符， 则在补丁文件名中应使用两个下划线来代替。 例如， 如果需要修改名为 src/freeglut_joystick.c 的文件， 补丁文件的名字应为 patch-src-freeglut__joystick.c。 只有 [-+._a-zA-Z0-9] 这些字符， 可以出现在补丁的文件名中， 请务必不要使用除这些字符以外的其它字符。 不要把您的补丁命名成 patch-aa 或 patch-ab 等这样的名字， 最好能在补丁名中提到路径和文件名。 不要把 RCS 字符串放进补丁。 我们把文件放进 ports 树的时候， CVS 会损坏它们， 当我们再 check out 出来的时候， 它们就会和原来的不一样， 从而导致打补丁失败。 RCS 字符串 是由美元符号 ($) 围绕的， 通常由 $Id 或 $RCS 开头。 使用 &man.diff.1; 的递归选项() 很好， 但是请检查一下最后输出的 patch， 确保没有任何的垃圾信息。 特别地， 有 2 种文件不需要 diff， 并且应该删除： 一种是 Makefile， 当您的port使用了Imake， 或者 GNU configure 等等的话。 如果您不得不编辑configure.in 以使 autoconf 去生成 configure， 不要使用 configure 来做 diff (这常常会有好几千行长!)； 请定义 USE_AUTOTOOLS=autoconf:261 并对应 configure.in 来制作 diff。 另外， 您还应尽量减少补丁中非功能性的空格及空白变动。 在开源世界中， 遵循不同的编码规范的项目共享大量代码是很常见的事情。 如果您从某个项目中提取一部分功能用来修正另一个程序中的问题时， 请务必小心： 补丁中很可能到处都是非功能性的变动行。 这不仅会导致 CVS 库的膨胀， 而且也会让导致问题的故障点， 以及您到底修改了什么变得不甚清晰。 假如需要删除文件， 则应在 post-extract target， 而不是作为补丁的一部分来完成。 除此之外， port 的 Makefile 还可以通过 in-place 模式的 &man.sed.1; 来直接进行简单的替换操作。 如果补丁需要使用变量值， 这就非常有用了。 例如： post-patch: @${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g' ${WRKSRC}/README @${REINPLACE_CMD} -e 's|-pthread|${PTHREAD_LIBS}|' ${WRKSRC}/configure 往往在移植某些软件的时候会遇到这样一种情况， 特别是这个软件是在 &windows; 上开发的时候， 大多数的源代码都需要进行CR/LF的转换。 这很可能会给以后打补丁带来问题， 还可能触发编译警告， 并给脚本的执行带来麻烦 (/bin/sh^M not found)， 等等。 要迅速将所有文件中的 CR/LF 改为只用 LF， 可以在 port 的 Makefile 中加入 USE_DOS2UNIX=yes。 除此之外， 还可以指定一个需要执行这种转换操作的文件列表： USE_DOS2UNIX= util.c util.h 如果希望转换一系列目录中的一组文件， 也可以使用 DOS2UNIX_REGEX。 它的参数是与 find 兼容的正则表达式。 关于这种格式的说明， 请参阅 &man.re.format.7;。 这个选项对转换所有指定扩展名的文件， 例如只转换源代码文件这样的应用非常有用： USE_DOS2UNIX= yes DOS2UNIX_REGEX= .*\.(c|cpp|h) 如果您希望基于现存的文件创建补丁， 可以把文件复制为带 .orig 扩展名的名字， 然后修改原文件。 然后使用 makepatch 目标根据修改在 port 的 files 目录中生成补丁文件。 配置 把任何附加的配置命令加进您的 configure 脚本并把它保存到 scripts 子目录。 如前面提到的那样， 您也能在 Makefile 和/或 使用 pre-configure 或 post-configure 的脚本来做同样的事情。 处理用户输入 如果您的 port 要求用户的输入以便配置编译、 或安装配置过程， 就必须在 Makefile 里设置 IS_INTERACTIVE 变量。 如果用户设置了 BATCH 的话， 这将让用户能跳过您的 port 来完成 通宵编译 (如果用户设置了 INTERACTIVE的话， 那么 只有 那些要求互动的 port 才会被编译) 这将给那些不停编译 ports 的机器省下很多时间。 通常我们还建议， 如果对于那些问题能有合理的缺省答案的话， 应检查一下 PACKAGE_BUILDING 变量， 并根据其设置决定是否执行关闭交互脚本。 这将允许我们为 CDROM 和 FTP 来编译 package。 配置 Makefile 配置 Makefile 是相当简单的， 我们在此建议您在开始之前看一下现有的例子。 在这份手册里也有一个 Makefile例子， 照着里面变量的顺序来写能使得您的 port 更容易地被其它人看懂。 现在， 当您开始编写您新的Makefile 的时候， 可以依次思考一下以下的问题： 作者发布的代码 放在 DISTDIR 中的是不是标准的用 gzip 压缩的 tar 包， 例如 foozolix-1.2.tar.gz？ 如果是， 可以先略过这一节。 如果不是， 您应当看看是不是要覆盖这些变量： DISTVERSION、 DISTNAME、 EXTRACT_CMD、 EXTRACT_BEFORE_ARGS、 EXTRACT_AFTER_ARGS、 EXTRACT_SUFX， DISTFILES，取决于您 port 的 distfile 格式有多么怪异。 (最常见的一个例子便是 EXTRACT_SUFX=.tar.Z， 一般这是因为 tar 包是用 compress 而不是 gzip 压缩的时候。) 最糟的情况是， 您需要自己编写 do-extract 来覆盖默认的定义， 尽管这不常见， 但如果遇到了， 还是需要这么做。 命名 Makefile 的第一部分便是 port 的名字、 版本号， 以及它所属的分类。 <varname>PORTNAME</varname> 和 <varname>PORTVERSION</varname> 您应该把 PORTNAME 设置为您 port 的名字， PORTVERSION 则是 port 的版本号。 <varname>PORTREVISION</varname> 和 <varname>PORTEPOCH</varname> <varname>PORTREVISION</varname> (port 的修订版本号) PORTEREVISION 变量是一个单调递增的值， 如果不为 0， 就会被加到包名的后面， 当 PORTVERSION 增加 的时候应被置 0 (也就是当官方有新版本发布的时候)。 PORTREVISION 会被自动化工具 (比如 &man.pkg.version.1;) 用来检测是否存在可用的新版本。 每当 port 发生变化并对生成的 package 的内容或结构有显著影响时， 都应增加 PORTREVISION 值。 下面是一些应当修改 PORTREVISION 的情况： 有新的补丁用来修正安全漏洞、 错误， 或给 port 添加了新的功能。 修改了 Makefile 里编译时开启或禁用的选项。 修改了要安装文件的列表或安装时的行为 (例如， 修改了一个用来给 package 初始化数据的脚本， 如 ssh host keys)。 一个port依赖的共享库版本改变 (在这种情况下， 当安装了新版本的共享库， 后再去安装较早的软件就会出错， 因为它们要依赖老的 libfoo.x 而不是libfoo.(x+1))。 原作者修改了 port distfile， 并且 distfile 的新老版本之间用 diff -ru 只能发现一些细微的变化， 这时我们只需要对 distinfo 做相应的修正， 而不需要修改 PORTVERSION。 不需要修改 PORTREVISION 的例子： port 结构风格的改变， 但对于打成的包没有功能的上的变化。 MASTER_SITES 发生变化， 或进行了对 port 功能的修改， 但不致影响最后打成的包。 对 distfiles 诸如修正拼写错误之类的补丁， 对用户而言没有升级上的麻烦。 对一个原本编译失败的包的修改， 使其可编译， 而没有加入新功能。 因为 PORTREVISION 表示包的内容发生了变化， 如果先前没有可编译的包， 也就不需要修改 PORTREVISION 来表示变化。 一个修改并提交 port 的原则是： 使得别人能从中受益 (改进、 修改已有错误， 或使新的 package 能够运行)， 您还要权衡一下这是否应让那些经常更新 ports 树的人升级， 如果回答是 是 的话， PORTREVISION 就应该修改了。 <varname>PORTEPOCH</varname> (port 的加权版本号) 有时软件商或 FreeBSD 的 porter 会使用比旧版的版本号小的数字做为新版本号的情况。 举例来说， 从 foo-20000801 到 foo-1.0 (从形式上来说这是不对的， 因为 20000801 在数值上比1大很多)。 在这种情况下， PORTEPOCH 应当增加。 如果 PORTEPOCH 非 0， 就应当加到包名字的后面。 PORTEPOCH 永远不能被减少或清零， 因为那样会导致与前一时期的 package 比较版本时产生不正确的结果。 (就是说， 那个 package 就不会被检测到已经过时了。) 新的版本号 (比如前面在前面那个例子中的 1.0,1) 在数值上比前一个版本 (20000801) 小， 但多数自动化的工具会认为 ,1 后缀意味着比前一个包的后缀 ,0 大。 错误的去除或重置 PORTEPOCH 会导致很多不幸发生； 如果您还不明白前面的讨论， 请多阅读几次直至明白为止， 或到邮件列表上来提问。 大多数 port 都不会用到 PORTEPOCH， 并且如果某个软件的下一个版本改变了版本号结构的话， 用巧妙的方法来设定 PORTVERSION 也能避免使用 PORTEPOCH。 然而， FreeBSD porter 也需要注意， 当有新版本的软件发布， 但并非正式版本时 — 比如 snapshot 版本， 原作者可能会使用当时的日期来命名， 这在新的 官方 版本发布的时候， 就很容易引起前面提到的问题。 举个例子， 如果 snapshot 版本的发布日期是 20000917， 这个软件的上一个版本是1.2， 那么这个版本的 PORTVERSIN 应该设为 1.2.20000917 或类似的样子， 而不是20000917， 这样在 1.3 发布以后， 新版本就可以在数值上大于旧的版本了。 关于 <varname>PORTREVISION</varname> 和 <varname>PORTEPOCH</varname> 的用例 gtkmumble port，版本号 0.10， 被提交到 ports collection: PORTNAME= gtkmumble PORTVERSION= 0.10 PKGNAME 变成 gtkmumble-0.10。 然后有人发现了一个安全漏洞， 需要用一个FreeBSD的补丁。 PORTREVISION 就要相应的增加。 PORTNAME= gtkmumble PORTVERSION= 0.10 PORTREVISION= 1 PKGNAME变成了 gtkmumble-0.10_1 软件的作者发布了新的版本， 版本为 0.2 (作者本来的意思是， 用 0.10 表示 0.1.0，而不是指 0.9 之后的那个版本 - 但是现在太迟了)。 因为现在的次版本号 2 在数值上比上一个版本 10 小， PORTEPOCH 必须增加， 以使新的 package 被认为是 更新的。 由于那是作者发布的一个新版本， 因此 PORTREVISION 应被置0 (或者从 Makefile 里面删除它)。 PORTNAME= gtkmumble PORTVERSION= 0.2 PORTEPOCH= 1 PKGNAME 变成了 gtkmumble-0.2,1 下一个版本将会是 0.3。 由于 PORTEPOCH 从不减少， 那么就无须改动： PORTNAME= gtkmumble PORTVERSION= 0.3 PORTEPOCH= 1 PKGNAME 变成 gtkmumble-0.3,1 如果在这次升级中 PORTEPOCH 被置为了0， 那么在装了 gtkmumble-0.10_1 包的机器上就无法检测到 gtkmumble-0.3 包的更新， 因为 3 在数值上比 10 小。 记住， 这是 PORTEPOCH 最重要的地方。 <varname>PKGNAMEPREFIX</varname> 和 <varname>PKGNAMESUFFIX</varname> 2 个可选的变量， PKGNAMEPREFIX 和 PKGNAMESUFFIX 可以和 PORTNAME 还有 PORTVERSION 配合使用， 形成像这样的 PKGNAME： ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}。 请确定符合我们的 包命名规则。 当然， 不 允许在 PORTVERSION 中使用连字符 (-)。 如果包名有 language- 或 -compiled.specifics 部分 (见下文)， 请分别用 PKGNAMEPREFIX 和 PKGNAMESUFFIX， 不要直接加到 PORTNAME 中。 <varname>LATEST_LINK</varname> LATEST_LINK 在编译包的过程中用于确定可以为 pkg_add -r 使用的缩短的名字。 举例来说， 在安装最新版本的 perl 的时候， 只需指定 pkg_add -r perl 而无需知道具体的版本号。 这个名字应该是独一无二的， 并且对用户而言应该是显而易见的名字。 有时， 在 ports 套件中可能会存在同一程序的多个版本。 索引和预编译包的联编系统都需要能够将它们视为不同的软件包， 尽管其 PORTNAME、 PKGNAMEPREFIX， 甚至 PKGNAMESUFFIX 可能是一模一样的。 遇到这种情况时， 就需要将除了 主 port 之外的其他 port 中的 LATEST_LINK 变量设为不同的值 — 请参见 lang/gcc46 和 lang/gcc port， 以及 www/apache* 系列， 以了解它的用法。 如果设置了 NO_LATEST_LINK， 则系统便不会生成对应的连接， 对于非 主 port 来说是一个可行的选择。 需要注意的是， 如何确定 主 版本 — 最流行、 受支持最好， 变动最少， 等等 — 已经超过了本书能够给出的建议范围； 这里只是向您介绍在选定了一个 主 port 之后如何指定其他 port 的版本。 包命名规则 以下是您在命名您的包时应当遵守的规则。 这将使得我们放包的目录更利于浏览， 因为我们已经有数以万计的包了， 如果用户觉得查看包名很困难的话， 他们会很快走开的。 一个包的名字应该看起来像这样： language_region-name-compiled.specifics-version.numbers。 要像这样来定义包的名字： ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}。 确保所有的变量符合上面的格式。 FreeBSD 会尽力去支持用户当地的语言。 如果这个 port 是某种语言专用的， 那么 language- 部分应该是 由 ISO-639 定义的自然语言的 2 个字母缩写。 比如， ja是表示日本， ru 是表示俄罗斯， vi 表示越南， zh 表示中国， ko 表示韩国， de 表示德国。 如果是针对某种语言的某一地区的话， 再要加上2个字母的国家代码。 例如， en_US 表示美国英语， fr_CH 表示瑞士法语。 language- 部分应该在 PKGNAMEPREFIX 变量里设置。 name 部分的首字母应该 小写。 (余下的部分可以包含大写字母， 所以当您 要转换一个包含大写字母软件的名字时， 您需要 自己做出判断。) 对于 Perl 5 模块的命名， 有个传统的规则是， 在前面 加上 p5- 并把两个冒号的部分改为连字号， 如： Data::Dumper 模块对应的名字， 就应该是 p5-Data-Dumper。 确认 port 的名字和版本之间有清晰的分隔， 并放入 PORTNAME 和 PORTVERSION 变量。 在 PORTNAME 中包含版本部分的唯一理由是上游软件包真的采用这样的命名方式， 类似 textproc/libxml2 或 japanese/kinput2-freewnn port 这样。 否则， 在 PORTNAME 中就不应包含任何版本信息。 许多 port 采用同样的 PORTNAME 名字是很正常的， www/apache* port 便是如此； 在这种情况下， 不同的版本 (以及不同的索引项) 是由 PKGNAMEPREFIX、 PKGNAMESUFFIX， 以及 LATEST_LINK 的值的不同而有所区别的。 如果 port 可以使用不同的 硬编码默认配置 进行联编 (通常是一系列 port 的一部分目录名)， 则 -compiled.specifics 部分就应该明示编译进去的默认值 (此处连字号是可选的)。 通常的用例包括纸型和不同的字体尺寸。 -compiled.specifics 部分应该通过 PKGNAMESUFFIX 变量来设置。 版本号应该紧随在连字号 (-) 后面并由数字和字母组成。 特别指出， 另外的连字号是不允许出现在版本号里的。 唯一例外的是字符串 pl (表示 patchlevel)， 只能 用在软件没有主版本号和次版本号的情况下。 如果软件的版本号里出现了像 alpha， beta， rc， pre， 取第一个字母把它放在小数点的后面。 如果在版本号里一直出现那些名字， 那么在数字和字母之间不应有多余的小数点。 这个方法是为了更容易得凭版本号来排序 port。 特别注意的是， 确保版本号之间的每部分都由小数点来分隔， 如果日期也是版本号的一部分， 就用这样的格式， 0.0.yyyy.mm.dd 这样的格式， 而非 dd.mm.yyyy 甚至 yy.mm.dd 这种不适合表示千年的格式。 在版本号上使用 0.0. 前缀十分重要， 因为当软件发行正式的版本时， 其版本号数字很可能会小于表示年份的 yyyy 数字。 这里是一些真实的例子， 我们藉此说明如何把软件作者对软件的命名， 转换为适合我们包的命名方式： 发行版的名字 PKGNAMEPREFIX PORTNAME PKGNAMESUFFIX PORTVERSION 说明 mule-2.2.2 (空) mule (空) 2.2.2 没什么需要修改的 EmiClock-1.0.2 (空) emiclock (空) 1.0.2 程序的名字不能使用大写字母 rdist-1.3alpha (空) rdist (空) 1.3.a 像 alpha 这样的字符串是不允许出现的 es-0.9-beta1 (空) es (空) 0.9.b1 像 beta 这样的字符串是不允许出现的 mailman-2.0rc3 (空) mailman (空) 2.0.r3 像 rc 这样的字符串是不允许出现的 v3.3beta021.src (空) tiff (空) 3.3 那个是啥鬼东西？ tvtwm (空) tvtwm (空) pl11 总需要有个版本号吧 piewm (空) piewm (空) 1.0 总需要有个版本号吧 xvgr-2.10pl1 (空) xvgr (空) 2.10.1 pl 只允许在没有 主/次 版本号的情况下才能出现 gawk-2.15.6 ja- gawk (空) 2.15.6 日文版 psutils-1.13 (空) psutils -letter 1.13 纸张大小已经在编译的时候被硬编码到程序里了 pkfonts (空) pkfonts 300 1.0 300dpi 字体的包 如果在原始的代码里没有版本号， 或者原作者并不打算开发另外的版本， 就应把版本号设成 1.0 (就像前面 piewm 的例子那样)。 否则， 要求原始的作者加上版本号或使用日期 (0.0.yyyy.mm.dd) 来作为版本号。 分类 <varname>CATEGORIES</varname> (所属分类) 在包制作完成之后， 它会被放在 /usr/ports/packages/All， 并建立一系列来自 /usr/ports/packages 下子目录的符号连接。 这些子目录的名称是由 CATEGORIES 指定的。 这将方便于那些用户在 FTP 站点或 CDROM 的一大堆包里面寻找自己想要的包。 请查看一下 目前的分类表， 并找出一个适合您 port 的分类。 此列表也会决定您的 port 在 port 目录中的位置。 如果您在这里设定了 1 个以上的分类， 则认为您 port 文件应放到以第一个分类命名的子目录中。 请参阅 后面 关于如何选择正确分类的更多讨论。 目前的分类表 这是目前 port 中的分类。 那些用星号 (*) 标记的是 虚拟分类 — 它们在ports树里没有相应的子目录， 因而只用来做为次要的分类， 用以方便搜索。 对于非虚拟的分类来说， 您会看到在相对应子目录中的 Makefile 里有写在 COMMENT 里的单行描述。 分类 描述 注意事项 accessibility 帮助残障人士的 port。 afterstep* 对于 AfterStep 窗口管理器的支持。 arabic 阿拉伯语言支持。 archivers 压缩与备份工具。 astro 有关天文学的 port。 audio 声音支持。 benchmarks 测评程序。 biology 生物学相关的软件。 cad 计算机辅助设计工具。 chinese 中文语言支持。 comms 通讯软件。 大部分是用于串口通讯的。 converters 字符编码转换。 databases 数据库。 deskutils 在发明计算机以前就已经在桌面上使用的东西。 devel 程序开发工具。 不要把开发库放在这里 — 除非您再也找不到更合适的分类， 否则就不该放在这个分类里。 dns DNS 相关的软件。 docs* 有关 FreeBSD 文档的 Meta-ports。 editors 通用编辑器。 有特殊用途的编辑器应该被置于相应的分类中 (比如， 数学-方程式 编辑器应该放在 math 分类里。 elisp* Emacs-lisp相关的port。 emulators 其它操作系统的模拟器。 终端模拟器 不应该 属于这个分类 — 基于 X 的应该放在 x11 而基于文本模式的应该放到 comms 或 misc 中去， 取决于具体的功能。 finance 货币、 金融以及相关的应用程序。 french 法语语言支持。 ftp FTP 客户端和服务器端的程序。 如果您的 port 同时支持 FTP 和 HTTP 的话， 把它放进 ftp 并把 www 做为第二分类。 games 游戏。 geography* 与地理学有关的软件。 german 德语语言支持。 gnome* 关于 GNOME 项目的支持。 gnustep* 与 GNUstep 桌面环境有关的软件。 graphics 图形图象程序。 hamradio* 业余无线电爱好者使用的软件。 haskell* 有关 Haskell 编程语言的软件。 hebrew 希伯来语语言支持。 hungarian 匈牙利语语言支持。 ipv6* IPv6 相关软件。 irc IRC 相关程序 japanese 日语语言支持。 java 与 Java™ 编程语言有关的软件。 java 分类对 port 而言不应是其唯一的分类。 除了直接与 Java 语言相关的 port 之外， 开发人员应尽量避免使用 java 作为 port 的主分类。 kde* K 桌面环境 (KDE) 相关的软件。 kld* 可加载内核模块。 korean 韩语语言支持。 lang 编程语言。 linux* Linux 相关的应用程序。 lisp* 和 Lisp 编程语言有关的软件。 mail 电子邮件软件。 math 数值计算和其它数学相关的软件。 mbone* MBone 应用程序。 misc 各式各样的实用程序。 通常不属于其它的任何分类， 如果可能的话， 尽量为您的 port 选择 misc 以外的分类， 因为在这里的 port 比较容易被人忽略。 multimedia 多媒体软件。 net 各种网络相关的软件。 net-im 即时消息软件。 net-mgmt 网络管理软件。 net-p2p 对等网 (Peer to peer network) 应用程序。 news USENET新闻组相关软件。 palm Palm™ 系列相关软件。 parallel* 并行计算相关软件。 pear* Pear PHP 架构相关软件。 perl5* Perl5 相关的软件。 plan9* Plan9 相关程序。 polish 波兰语语言语言支持。 ports-mgmt 用于管理、 安装和开发 FreeBSD ports 和预编译包的 port。 portuguese 葡萄牙语语言支持。 print 打印相关的软件。 桌面出版工具 (打印预览工具等等) 也可以放在此分类里。 python* Python 编程语言相关的软件。 ruby* Ruby 编程语言相关的软件。 rubygems* 移植版本的 RubyGems 软件包。 russian 俄语语言支持。 scheme* 与 Scheme 语言有关的 port。 science 科学相关但不适合放在 astro、 biology， 以及 math 分类的 port。 security 安全相关的实用程序。 shells 命令行 shell。 spanish* 西班牙语支持 sysutils 系统相关的实用程序。 tcl* 依赖于 Tcl 运行的 port。 textproc 文本处理的实用程序。 这个分类并不适合于那些应该放到 print 的桌面出版工具。 tk* 依赖于 Tk 运行的 port。 ukrainian 乌克兰语语言支持。 vietnamese 越南语语言支持。 windowmaker* WindowMaker 窗口管理器的相关支持。 www Word Wide Web的相关软件。 HTML语言相关的支持也可以放在这个分类里。 x11 X Window System以及相关软件。 这个分类是给那些直接支持X Window System 的软件的。 不要把常规的 X 应用程序也放进这里； 它们中的大多数都应被归类到 x11-* (参见下文)。 如果您的 port 是 X 应用程序， 应定义 USE_XLIB (使用 USER_IMAKE 隐含包括它)， 然后把它放到合适的分类里。 x11-clocks X11 下的时钟程序。 x11-drivers X11 驱动程序。 x11-fm X11 下的文件管理器。 x11-fonts X11 下的字体以及相关工具。 x11-servers X11 服务器。 x11-themes X11 主题。 x11-toolkits X11 工具包。 x11-wm X11 窗口管理器。 xfce* 与 Xfce 桌面环境有关的 port。 zope* Zope 相关的支持。 选择正确的分类 由于不少分类是重复的， 您通常在用哪个分类作为您 port 的主分类上做出选择。 下面有几条规则能帮您解决这个问题。 这是一个带优先级的表， 按优先级降序罗列： 第一个分类必须是个物理的分类 (参阅 前面)。 这对于制作包是必要的。 虚拟分类和物理分类可能在包制作完成后混合在一起。 对于特定语言的分类通常放在第一位。 例如， 如果您的 port 会安装一些 X11 的日文字体， 那么 CATEGORIES那行 就应该是 japanese x11-fonts。 有特定意义的分类应当被列在无特定意义的前面。 例如， HTML 编辑器应该是这样的 www editors， 而不是其它的什么。 同样地， 您不应该列出 net， 如果 port 属于 irc、 mail、 news、 security， 或是 www， 因为 net 可以表示它们的超集。 只有当主要的分类是一门自然语言的时候， x11 能被做为第二分类。 需要特别指出的是， 您不应把 X 的应用程序也归类为 x11。 Emacs 模式应当于相应的应用程序放在同一个分类里， 而不是 editors 分类。 举例来说， 一个用于编辑某种编程语言源代码的 Emacs 模式应该被归为 lang 一类。 需要安装可加载内核模块的 port 应在其 CATEGORIES 中归入虚拟分类 kld。 misc 分类的 port 不能有其它非虚拟的分类。 如果您在您的 CATEGORIES 里设了 misc 和另外的分类， 那意味着可以安全地删除 misc 并把 port 放到其它的子目录中了！ 如果您的 port 确实不属于现有的分类， 才把它放到 misc。 如果您不能确定使用哪个分类， 请在您提交的 &man.send-pr.1; 里加上一行注释， 这样我们就能在导入进 port 树之前讨论一下。 如果您是 committer， 发一份备忘到 &a.ports; 先讨论一下。 很多情况是新的 port 被加到错误的分类里， 然后又立即被移走。这会造成源代码库不必要和不良的膨胀。 如何提议建立新的分类 由于 Ports Collection 在持续增长， 已经引入了许多新的分类。 新的分类既可以是 虚拟的 分类 — 这些分类在整个 ports 目录中没有属于自己的子目录 — 或 物理的 分类 — 它们有自己的子目录。 接下来我们将讨论与建立新的物理分类有关的事项， 以便帮助您理解如何提议建立新的分类。 我们目前的做法是避免建立新的物理分类， 除非有非常多的 port 应被归入这一分类， 或者 port 属于某一特定的小团体 (例如， 与某种人类语言相关)， 或两者皆是。 这样做的原因是这类修改会让 committer 和用户都不得不进行 许多工作 来在 Ports Collection 进行或追踪修改。 此外， 提议新的分类通常都会引起争论。 (可能这是因为关于某个分类是否 太大 一直没有非常一致的意见的缘故， 另一方面， 分类是否能够能够有助于浏览 (以及多少个分类是合适的)， 等等， 也都是问题。) 下面是具体的步骤： 在 &a.ports; 提议新的分类。 您应提供建立新分类的详细依据， 包括为什么认为现有的分类不够， 以及希望移动位置的一系列 port 的名字。 (如果有尚在 GNATS 而未 commit 的 port， 也应一一列出。) 如果您是相关 port 的监护人或提交者， 说明这一情况可能有助于您的提议得到通过。 参与讨论。 如果有人支持您的建议， 应及时提交一个 PR， 其中包括提议 PR 的理由， 以及需要移动的 port 的列表。 理想情况下， 这个 PR 也应包含针对下列文件的补丁： 进行 repocopy 之后对 Makefile 进行的修改 新分类的 Makefile 旧分类的 Makefile 依赖于旧 port 的 port 的 Makefile (此外， 作为一项加分因素， 您还可以按照 Committer 指南所介绍的流程， 提供一些其它需要修改的文件。) 由于这是一项影响 ports 基础设施的变动， 它不仅涉及 repo-copy 的使用， 而且也可能会影响联编集群的回归测试操作， 因此这类 PR 应分派给 &a.portmgr;。 如果这一 PR 得到批准， 某个 committer 将按照在 Committer 指南 中所介绍的步骤来完成余下的工作。 提议新的虚拟分类和上述过程类似， 但会容易许多， 因为不需要实际地移动任何 port。 这种情况下， PR 应附带的补丁， 就只需要修改影响到的 port 的 Makefile， 以便在其中的 CATEGORIES 中加入新的分类了。 如何提议对分类进行重新组织 有些时候会有一些人提议重新将分类组织为 2-层 或某种基于关键字的结构。 目前为止， 还没有进行任何相关的改变， 因为尽管这些修改比较容易完成， 但修改整个 Ports Collection 所需要进行的工作， 至少也是令人生畏的。 在发表您的观点之前， 请阅读在邮件列表存档中历史上所进行过的提议； 此外， 您也会被要求提供一个可用的原形。 源码包文件 在 Makefile 中的第二部分是描述用于联编 port 所必需下载的文件， 以及到什么地方去下载它们。 <varname>DISTVERSION/DISTNAME</varname> (源码包版本号/名称) DISTNAME 是作者称呼您所 port 软件的名字。 DISTNAME 的默认值是 ${PORTNAME}-${PORTVERSION}， 因此只有在需要时才应手工指定。 DISTNAME 只在两个地方用到。 第一处是源码包文件列表 (DISTFILES)， 其默认值是 ${DISTNAME}${EXTRACT_SUFX}。 第二处是源码包应被展开到的目录名， 即 WRKSRC 所指定的目录， 其默认值是 work/${DISTNAME}。 某些软件作者发布源码包的时候并不采取 ${PORTNAME}-${PORTVERSION} 这样的模式， 这可以通过设置 DISTVERSION 来自动处理。 PORTVERSION 和 DISTNAME 会自动地展开， 当然， 也可以改掉它。 下表给出了一些例子： DISTVERSION PORTVERSION 0.7.1d 0.7.1.d 10Alpha3 10.a3 3Beta7-pre2 3.b7.p2 8:f_17 8f.17 PKGNAMEPREFIX 和 PKGNAMESUFFIX 并不影响 DISTNAME。 此外还应注意 WRKSRC 等于 work/${PORTNAME}-${PORTVERSION}， 而源代码的压缩包则可能是 ${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX} 以外的其它名字。 一般情况下应该保持 DISTNAME 不变 — 更好的方法是定义 DISTFILES 而不是同时设置 DISTNAME 和 WRKSRC (可能还有 EXTRACT_SUFX)。 <varname>MASTER_SITES</varname> (主流下载站点) 记录 FTP/HTTP-URL 指向 MASTER_SITES 中原始压缩档的目录部分。 不要忘了结尾的斜线 (/)！ make 宏将尝试使用 FETCH 来抓取所指定的源码包文件， 如果无法在本地系统中找到这些文件的话。 建议您指定多个镜像站点， 最好是在不同的大洲上的。 这样将有效地防止由于大范围网络问题所导致无法下载的问题。 我们甚至打算增加自动检测距离最近的站点并从那里下载的功能； 使用多个站点是这样做的重要一步。 如果原始的源码包可以从比较流行的软件下载站点， 例如 SourceForge、 GNU 或是 Perl CPAN 等等来获得， 您可能会希望使用类似 MASTER_SITE_* 这样的缩写来表示它们 (例如 MASTER_SITE_SOURCEFORGE、 MASTER_SITE_GNU 以及 MASTER_SITE_PERL_CPAN)。 只需将 MASTER_SITES 设为这些变量， 并使用 MASTER_SITE_SUBDIR 来指定路径就可以了。 下面是一个例子： MASTER_SITES= ${MASTER_SITE_GNU} MASTER_SITE_SUBDIR= make 此外， 您还可以用更为简略的格式： MASTER_SITES= GNU/make 这些变量是在 /usr/ports/Mk/bsd.sites.mk 中定义的。 新项目会随时增加， 因此在您提交 port 之前， 应先看一看这个文件的最新版本。 针对常用软件下载站的许多 暗黑魔法 宏， 还能够自动判断目录的结构。 对于这些站点， 只要使用与之对应的缩写， 系统便会自动为您生成相关的子目录配置。 MASTER_SITES= SF 如果系统猜测的路径不对， 则可以使用下面这样的配置来替换。 MASTER_SITES= SF/stardict/WyabdcRealPeopleTTS/${PORTVERSION} 常用的魔术 <varname>MASTER_SITES</varname> 宏 宏 自动猜测的子目录 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}
<varname>EXTRACT_SUFX</varname> (压缩包所用的扩展名) 如果您有一个源码包文件， 而它使用了某种怪异的扩展名来表达压缩方法， 应设置 EXTRACT_SUFX。 例如， 如果源码包文件的名字是 foo.tgz 而非更为一般的 foo.tar.gz， 您应写上： DISTNAME= foo EXTRACT_SUFX= .tgz USE_BZIP2 和 USE_ZIP 变量会自动根据需要将 EXTRACT_SUFX 设置为 .tar.bz2 或 .zip。 如果这两个都没设置， 则 EXTRACT_SUFX 的 默认值将是 .tar.gz。 任何时候都不需要同时设置 EXTRACT_SUFX 和 DISTFILES. <varname>DISTFILES</varname> (全部源代码包) 有些时候所下载的文件名字和 port 的名字没有任何联系。 例如， 可能是 source.tar.gz， 或者与此类似的其它名字。 也有一些其它的应用软件， 它们的源代码可能被存放到了不同的压缩包中， 而且全都需要下载。 如果遇到这种情况， 可以将 DISTFILES 设置为以空格分隔的一组需要下载的文件列表。 DISTFILES= source1.tar.gz source2.tar.gz 如果没有予以明确的设置， DISTFILES 的默认值将是 ${DISTNAME}${EXTRACT_SUFX}。 <varname>EXTRACT_ONLY</varname> (只解压缩部分源文件) 如果只有一部分 DISTFILES 需要解压缩 — 例如， 其中的一个是源代码， 而其它则是未压缩的文档 — 此时应把那些需要解压缩的文件加到 EXTRACT_ONLY 中。 DISTFILES= source.tar.gz manual.html EXTRACT_ONLY= source.tar.gz 如果 DISTFILES 中 没有 需要解压缩的文件， 则应将 EXTRACT_ONLY 设为空串。 EXTRACT_ONLY= <varname>PATCHFILES</varname> (通过下载得到的补丁文件) 如果您的 port 需要来自 FTP 或 HTTP 的一些额外的补丁， 应将 PATCHFILES 设置为这些文件的名字， 并将 PATCH_SITES 指向包含这些文件的目录的 URL (格式与 MASTER_SITES 相同)。 如果这些补丁， 由于包含了其它的目录名， 而导致它们不是相对于源代码目录的顶级目录 (也就是 WRKSRC) 的话， 就需要相应地设置 PATCH_DIST_STRIP 了。 例如， 如果补丁中所有的目录名前面都有一个多余的 foozolix-1.0/， 就应设置 PATCH_DIST_STRIP=-p1。 不需要担心补丁文件本身是否是压缩的； 如果文件名以 .gz or .Z 结尾， 系统会自动解压缩。 如果补丁是同某些其它文件， 例如文档， 一同以 gzip 压缩的 tar 格式发布的， 就不能简单地使用 PATCHFILES 了。 这种情况下， 您应将这些补丁包的文件和位置加入到 DISTFILES 和 MASTER_SITES 中。 然后， 用 EXTRA_PATCHES 变量来指出这些文件， 这样 bsd.port.mk 就会自动地为您应用这些补丁了。 需要特别注意的是， 不要 将补丁文件复制到 PATCHDIR 目录中 — 这个目录可能是不可写的。 压缩包会以同源代码一样的方式解压缩， 因此不需要自行完成解压缩操作， 并复制补丁文件。 如果您一定要这样做， 就要注意， 不要让解压缩出来的文件覆盖先前已经存在的文件。 此外， 这么做还需要手工增加命令， 以便在 pre-clean target 中删除这些复制出来的文件。 来自不同站点的多个源代码包或补丁文件 (<literal>MASTER_SITES:n</literal>) (这一节在某种程度上应被视作 进阶话题； 刚开始阅读这份文档的读者可能会希望先跳过这一部分)。 这一节提供了被称作 MASTER_SITES:n 和 MASTER_SITES_NN 的下载控制机制。 这里我们把它们称为 MASTER_SITES:n。 首先给出一些背景。 OpenBSD 在其 DISTFILES 和 PATCHFILES 变量中提供了一个很棒的功能， 即， 允许这些文件和补丁拥有 :n 后缀， 其中 n 可以使用 [0-9]， 来表达组。 例如： DISTFILES= alpha:0 beta:1 在 OpenBSD 中， 源码包文件 alpha 应被关联到变量 MASTER_SITES0 而不是公共的 MASTER_SITES 变量上； 而 beta 则应关联到 MASTER_SITES1 上。 这是一个很有意思的功能， 它可以避免无休止地搜索正确的下载站点的过程。 想象 DISTFILES 中指定了 2 个文件， 而 MASTER_SITES 包含了 20 个站点的情形， 这其中许多站点慢如蜗牛， 而 beta 可以在 MASTER_SITES 的所有站点找到， 而 alpha 只能在第 20 个上面找到。 如果监护人了解这一点， 那么检查所有的站点无疑是在浪费时间， 不是吗？ 这显然不是开始一个愉快周末的好办法！ 现在您有了一个感性的认识了， 想象一下 DISTFILES 和更多的 MASTER_SITES。 显然， 我们的 distfiles 调查员先生 会感谢您减少他浪费在等待下载上所耗费的时间。 下一节中， 将按照 FreeBSD 对上述想法的实现来加以阐释。 我们对 OpenBSD 所提出的概念进行了一些改进。 简化信息 这一节将介绍如何迅速地对从不同的站点以及子目录下载多个源码包和补丁进行精确的控制。 这里， 我们将描述 MASTER_SITES:n 的一种简化用法。 对于多数情况而言这样做是足够的。 然而， 如果您需要更多信息， 还需要参考下面的几节。 一些应用程序需要从多个站点下载不同的源码包。 例如， Ghostscript 包括了程序核心本身， 以及大量的驱动文件， 以及则取决于用户的打印机品牌和型号的驱动程序。 某些驱动文件已经随程序核心附带， 但也有很多需要从其它站点下载。 为了适应这种需要， 每一个 DISTFILES 项应跟随一个冒号， 以及一个 标签名。 在 MASTER_SITES 的每个站点也应跟随冒号和标签名， 以便指定从哪个网站下载源码包文件。 例如， 考虑一个将源代码包分为两部分， 即 source1.tar.gz 和 source2.tar.gz 的软件， 它必须从两个不同的站点下载。 port 的 Makefile 应包括类似 的配置。 简化的 <literal>MASTER_SITES:n</literal> 用法， 每个文件来自一个站点 MASTER_SITES= ftp://ftp.example1.com/:source1 \ ftp://ftp.example2.com/:source2 DISTFILES= source1.tar.gz:source1 \ source2.tar.gz:source2 多个源码包可以使用同一个标签。 继续前面的例子， 假定增加了第三个源码包， source3.tar.gz， 应从 ftp.example2.com 下载。 Makefile 的这部分应写成 的样子。 简化的 <literal>MASTER_SITES:n</literal> 用法， 其中同一个站点上提供了不止一个文件 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 深入介绍 前面的例子无法满足您的需求？ 这一节， 我们将详细介绍 MASTER_SITES:n 的精细控制是如何工作的， 以及如何修改您的 port 来使用它们。 元素可以包含 :n 这样的后缀， 其中 n 是 [^:,]+， 概念上即 n 可以取任意数字或字母， 但我们目前将其限定为 [a-zA-Z_][0-9a-zA-Z_]+。 此外， 字符串匹配时对大小写是敏感的； 换言之， n 与 N 不同。 但是， 由于表达特殊的意义， 下列单词不能用于后缀： default、 all 和 ALL (它们会在 中介绍的部分用到)。 此外， DEFAULT 是一个有特殊用途的词 (请参见 )。 后缀为 :n 的项目属于 n 组， 而 :m 属于 m 组， 依此类推。 没有后缀的元素是无组的， 也就是它们都属于那个特殊的 DEFAULT 组。 给元素加入 DEFAULT 后缀通常是多余的， 除非您有同时属于 DEFAULT 和其它组的元素 (参见 )。 下面的例子是等价的， 但通常应适用第一个： MASTER_SITES= alpha MASTER_SITES= alpha:DEFAULT 组之间不是互斥的， 同一元素可以同时隶属于多个组， 而组则可以为空或者有任意多个元素。 同一组中的重复元素， 并不会被自动消去。 如果希望同一元素同时属于多个组， 可以用逗号 (,) 分开。 这种办法可以避免仅为指定不同的组而多次重复同一元素。 例如 :m,n,o 表示这个元素同时属于 m、 n 和 o 这三组。 下面这些写法都是等价的， 但只推荐使用最后一种： 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 同一组中的所有站点， 会根据 MASTER_SORT_AWK 排序。 在 MASTER_SITES 和 PATCH_SITES 中的组也会进行排序。 在 MASTER_SITES、 PATCH_SITES、 MASTER_SITE_SUBDIR、 PATCH_SITE_SUBDIR、 DISTFILES， 以及 PATCHFILES 中， 都可以使用组， 其语法为： 所有 MASTER_SITES、 PATCH_SITES、 MASTER_SITE_SUBDIR 以及 PATCH_SITE_SUBDIR 的元素， 都必须以 / 字符结尾。 如果有元素属于某些组， 则组后缀 :n 必须出现在终结符 / 之后。 MASTER_SITES:n 机制依赖于 / 的存在， 以避免在 :n 是元素一部分， 而 :n 同时又表示组 n 时发生混淆。 为了兼容性的考虑， 因为之前 / 终结符在 MASTER_SITE_SUBDIR 和 PATCH_SITE_SUBDIR 元素中都不是必需的， 如果后缀所紧跟的字符不是 /， 则 :n 将被认为是元素的一部分， 而不被当作组后缀， 即使元素拥有 :n 后缀。 请参见 和 以了解进一步的细节。 在 <varname>MASTER_SITE_SUBDIR</varname> 中 <literal>MASTER_SITES:n</literal> 的详细用法 MASTER_SITE_SUBDIR= old:n new/:NEW 组 DEFAULT 中的目录 -> old:n 组 NEW 中的目录 -> new 用到逗号分隔符、 多个文件， 多个站点和 不同子目录的 <literal>MASTER_SITES:n</literal> 详细用法 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 前述的例子的结果是下述的对于下载行为的精细控制。 站点的列表按照使用的顺序给出。 file1 将从 MASTER_SITE_OVERRIDE http://site1/directory-trial:1/ http://site1/directory-one/ http://site1/directory/ http://site2/ http://site7/ MASTER_SITE_BACKUP 下载。 file2 将和 file1 以同样的方式下载， 因为它们属于同一组 MASTER_SITE_OVERRIDE http://site1/directory-trial:1/ http://site1/directory-one/ http://site1/directory/ http://site2/ http://site7/ MASTER_SITE_BACKUP file3 将从 MASTER_SITE_OVERRIDE http://site3/ MASTER_SITE_BACKUP 下载。 file4 将从 MASTER_SITE_OVERRIDE http://site4/ http://site5/ http://site6/ http://site7/ http://site8/directory-one/ MASTER_SITE_BACKUP 下载。 file5 将从 MASTER_SITE_OVERRIDE MASTER_SITE_BACKUP 下载。 file6 将从 MASTER_SITE_OVERRIDE http://site8/ MASTER_SITE_BACKUP 下载。 如何对来自 bsd.sites.mk 的特殊变量， 例如 MASTER_SITE_SOURCEFORGE 进行分组？ 参见 。 <varname>MASTER_SITE_SOURCEFORGE</varname> 中 <literal>MASTER_SITES:n</literal> 的详细用法 MASTER_SITES= http://site1/ ${MASTER_SITE_SOURCEFORGE:S/$/:sourceforge,TEST/} DISTFILES= something.tar.gz:sourceforge something.tar.gz 将从所有 MASTER_SITE_SOURCEFORGE 中的站点下载。 如何与 PATCH* 变量连用？ 前面的例子介绍的都是 MASTER* 变量， 但对于 PATCH* 也是完全一样的， 它们在 有所介绍。 简化的 <varname>PATCH_SITES</varname> 中的 <literal>MASTER_SITES:n</literal> 用法。 PATCH_SITES= http://site1/ http://site2/:test PATCHFILES= patch1:test 会改变 ports 的哪些行为？ 哪些不会？ 所有普通的 ports 的行为都会保持不变。 MASTER_SITES:n 功能的代码， 只有在某些元素包含了前述， 特别是 中所提及语法的 :n 后缀时， 才会启用。 不受影响的 port target： checksum、 makesum、 patch、 configure、 build， 等等。 显然， do-fetch、 fetch-list、 master-sites 和 patch-sites 的行为会发生变化。 do-fetch： 会按照新的、 带有组后缀的 DISTFILES 和 PATCHFILES 在 MASTER_SITES 和 PATCH_SITES 所匹配的组元素， 以及 MASTER_SITE_SUBDIR 和 PATCH_SITE_SUBDIR 来进行。 请参见 。 fetch-list： 和旧式的 fetch-list 类似， 但以同 do-fetch 相似的方式处理组。 master-sites 和 patch-sites： (与旧版本不兼容) 仅返回组 DEFAULT 的元素； 事实上， 它们会执行 master-sites-default 和 patch-sites-default 这两个 target。 更进一步， 使用 master-sites-all 或 patch-sites-all 这两个 target 之一， 要比直接检查 MASTER_SITES 或 PATCH_SITES 更好。 此外， 未来版本可能不再保证直接检查能够正确工作。 请参见 以了解关于这些新 target 的更多技术细节。 port 中的新 target 一系列 master-sites-n 和 patch-sites-n target 可以分别用来列出 MASTER_SITES 和 PATCH_SITES 中的 n 组的内容。 例如， master-sites-DEFAULT 和 patch-sites-DEFAULT 都会返回 DEFAULT 组的内容， 而 master-sites-test 和 patch-sites-test 则返回 test 组的内容， 等等。 新增的 master-sites-all 和 patch-sites-all 这两个 target， 会完成先前 master-sites 和 patch-sites 所做的工作。 它们会返回所有组的元素， 就像这些元素都属于同一组一样， 并且会列出与 MASTER_SITE_BACKUP 或 MASTER_SITE_OVERRIDE 中在 DISTFILES 或 PATCHFILES 中指定的同样多个； 分别对于 master-sites-all 和 patch-sites-all。 <varname>DIST_SUBDIR</varname> (独立的源码包子目录) 避免让您的 port 使 /usr/ports/distfiles 陷入混乱。 如果您的 port 需要下载很多文件， 或者需要下载可能与其它 port 的源文件名冲突的文件 (例如， Makefile)， 则应将 DIST_SUBDIR 设置为 port 的名字 (通常可以用 ${PORTNAME} 或 ${PKGNAMEPREFIX}${PORTNAME})。 这将把 DISTDIR 从默认的 /usr/ports/distfiles 改为 /usr/ports/distfiles/DIST_SUBDIR， 并将与您的 port 有关的文件放到那个目录中。 此外， 它也会在备份文件主服务器 ftp.FreeBSD.org 上查找同一子目录下的文件 (直接在您的 Makefile 中设置 DISTDIR 则不会有这样的效果， 因此您应使用 DIST_SUBDIR。) 这一设置并不影响您在 Makefile 中定义的 MASTER_SITES。 <varname>ALWAYS_KEEP_DISTFILES</varname> (一直保存源码包) 如果您的 port 采用的是预编译的包， 但却采用了某种要求源代码必须与预编译版本一同提供的授权， 例如 GPL， 则应使用 ALWAYS_KEEP_DISTFILES 来告诉 &os; 联编集群保留一份在 DISTFILES 中文件的副本。 一般来说这些 port 的用户并不需要这些文件， 因此， 只在定义了 PACKAGE_BUILDING 符的时候， 才将源代码包文件加入 DISTFILES 是个好主意。 如何使用 <varname>ALWAYS_KEEP_DISTFILES</varname>。 .if defined(PACKAGE_BUILDING) DISTFILES+= foo.tar.gz ALWAYS_KEEP_DISTFILES= yes .endif 当您在 DISTFILES 加入其它文件时， 请务必确保这些文件也出现在了 distinfo 中。 此外， 这些额外的文件通常也会展开到 WRKDIR 中， 对于某些 ports， 这可能导致一些不希望的副作用， 因而需要进行特别的处理。 <varname>MAINTAINER</varname> (监护人) 请在此处写上您的电子邮件地址。 :-) 需要注意一点， MAINTAINER 变量的值只能是一个不包括注释部分的电子邮件地址， 其格式应为 user@hostname.domain。 请不要在此处写任何说明性的文字， 例如您的真实姓名 — 这会给 bsd.port.mk 带来麻烦。 监护人有责任保持 port 随时更新， 并确保其能够正确地运行。 详细的 port 监护人职责说明， 请参见 port 监护人面临的挑战 一节。 对于 port 的修改， 应被发给 port 的监护人进行复审， 且在 commit 之前需要获得其监护人的同意。 假如某一 port 的监护人没有在两周之内 (不包括主要的公共假日) 响应来自用户的更新请求， 则可视为监护人超时， 在这种情况下可以在没有监护人明确同意的情形下进行更新。 如果监护人在多达三个月的时间内没有进行任何响应， 则可以认为该监护人不辞而别， 允许对出现此类问题的 port 进行监护人变更。 尽管如此， 监护人为 &a.portmgr; 或者 &a.security-officer; 的 port 不受此限。 对监护人为这些小组的 port 进行未经许可的 commit 是不允许的。 我们保留对监护人所提交修正案进行改动的权力， 以便使其更符合现行的 Ports Collection 规范， 而无需提交补丁的人明确批准。 此外， 大规模的基础性修改， 也可能使 port 在没有得到监护人同意的情形下进行修改。 但这类修改都不应影响 port 本身的功能。 &a.portmgr; 保留以任何原因收回或绕过任何人监护权的权力， 而 &a.security-officer; 则保留以安全原因收回或绕过监护权的权力。 <varname>COMMENT</varname> (一句话说明) 这一变量用于指定 port 的一句话说明。 请 勿将 package 的名字 (或软件的版本) 放在说明中。 这一说明的第一个字母应大写， 结尾不用句点。 下面是一个例子： COMMENT= A cat chasing a mouse all over the screen Makefile 中的 COMMENT 变量应该紧接着 MAINTAINER 变量出现。 请务必将 COMMENT 这行限制在不超过 70 个字符之内， 因为这行内容会成为 &man.pkg.info.1; 呈现给用户的 port 的一句话简介。 依赖关系 许多 ports 会依赖其它 port。 这是包括 &os; 在内的多数 类-Unix 系统的很方便的功能。 这项功能， 可以避免在每个 port 或预编译包中都带上重复的依赖的代码， 而可以以依赖关系的方式去共享它们。 有七个变量用于帮助您确保所需的文件都存在于用户的机器上。 此外， 也提供了用于支持常见情形的依赖关系变量， 以及对依赖关系行为的更多控制。 <varname>LIB_DEPENDS</varname> (依赖的函数库/共享库) 这个变量用于指定 port 所依赖的共享库。 其内容是由一系列 lib:dir:target 元组构成的表， 其中 lib 是共享库的名字， 而 dir 则是在找不到时应该从哪里联编和安装， 最后， target 用于指定在那个目录中调用的 target。 例如， LIB_DEPENDS= jpeg.9:${PORTSDIR}/graphics/jpeg 会检测主版本号为 9 的 jpeg 共享库， 如果它不存在， 则会进入到您的 ports 目录中的 graphics/jpeg 子目录， 并联编和安装它。 如果您指定的 target 就是 DEPENDS_TARGET (默认是 install)， 则可以略去不写。 lib 部分是一个正则表达式， 用于在 ldconfig -r 的输出中进行查找。 可以使用类似 intl.[5-7] 和 intl 这样的值。 前一种模式， 即 intl.[5-7]， 能够匹配 intl.5、 intl.6 和 intl.7 中的任意一个。 第二种模式， 即 intl 则可以匹配任意版本的 intl 库。 依赖关系会被检测两次， 一次是在 extract target 中， 而另一次则是在 install target。 另外， 依赖关系的名字会放到 package 中， 以便让 &man.pkg.add.1; 能够自动地在用户系统上安装所需的未安装的其它 package。 <varname>RUN_DEPENDS</varname> (依赖的运行环境) 这个变量可以用来指定 port 在运行时所需要的可执行文件， 以及资源文件。 它是一系列 path:dir:target 元组的列表， 这里， path 时所需的可执行， 或者资源文件的名字， dir 是在无法找到这些文件或目录时， 去什么地方完成联编和安装以便获得这些文件； 而 target 则用来指定在这个目录中所调用的 target 的名字。 假如 path 以斜线 (/) 开始， 则会当作普通文件， 使用 test -e 来测试； 反之， 则系统会假定这是一个可执行文件， 并且用 which -s 来检测程序是否存在于搜索路径中。 例如， RUN_DEPENDS= ${LOCALBASE}/etc/innd:${PORTSDIR}/news/inn \ xmlcatmgr:${PORTSDIR}/textproc/xmlcatmgr 将检查文件， 或者目录 /usr/local/etc/innd 是否存在， 如果找不到， 则将从 port 目录的 news/inn 子目录加以安装。 系统也会检查是否能够在搜索路径中找到名为 xmlcatmgr 的文件， 如果找不到的话， 则会进入 ports 目录中的 textproc/xmlcatmgr 子目录， 并进行联编和安装的操作。 这种情况下， innd 实际上是一个可执行文件； 如果可执行文件不会出现在搜索路径中， 您就需要指定完整路径了。 ports 联编集群上官方的搜索 PATH 是 /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin 这个依赖关系会在 install target 的过程中进行检查。 此外， 依赖关系的名字会被放到 package 中， 以便 &man.pkg.add.1; 能够在用户的系统中尚未安装相关软件时自动地安装那些 package。 如果您希望指定一个的 target 和默认的 DEPENDS_TARGET 相同， 则可以略去不写。 一种比较常见的情形是 RUN_DEPENDS 和 BUILD_DEPENDS 完全一样， 这种情况在移植的软件是采用脚本语言书写， 或联编环境与运行环境需求相同时尤其普遍。 这种情况可以用下面简单明了的方式直接将其中一个变量赋值给另一个变量： RUN_DEPENDS= ${BUILD_DEPENDS} 不过， 这种赋值有可能会令运行环境被某些没有在 port 原本的 BUILD_DEPENDS 明确定义的依赖关系污染。 导致这种情况的原因是 &man.make.1; 计算变量赋值时默认采用的是延后计算 (lazy evaluation)。 例如， 如果在 Makefile 中使用了 USE_* 变量， 这些变量就会由 ports/Mk/bsd.*.mk 处理， 并填写与之对应的联编依赖关系。 例如， USE_GMAKE=yes 会把 devel/gmake 加入到 BUILD_DEPENDS。 如果希望避免这些附加的依赖关系污染 RUN_DEPENDS， 在使用赋值的时候就需要小心考虑这类扩展的情况， 例如， 可以在赋值展开之前复制变量的值： RUN_DEPENDS:= ${BUILD_DEPENDS} <varname>BUILD_DEPENDS</varname> (依赖的联编环境) 此变量用于指定用来联编 port 的可执行文件或资源文件。 与 RUN_DEPENDS 类似， 它是一个 path:dir:target 元组的列表。 例如， BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip 将检测名为 unzip 的可执行文件是否存在， 如果不存在， 则会进入到您的 ports 目录中的 archivers/unzip 并完成联编和安装工作。 这里的 build 表示从解压缩到编译的全部过程。 依赖关系是在 extract target 的过程中检测的。 假如您要指定的 target 和 DEPENDS_TARGET 相同， 则可以略去不写。 <varname>FETCH_DEPENDS</varname> (依赖的下载环境) 这一变量用于指定 port 在下载时所需的可执行文件或资源文件。 和前两个类似， 它是一组 path:dir:target 元组。 例如， FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2 将检测名为 ncftp2 的可执行文件是否存在， 如果找不到， 则将进入到您 ports 目录中的 net/ncftp2 子目录并加以联编和安装。 这个依赖关系是在 fetch target 过程中检查的。 如果与 DEPENDS_TARGET 相同， 则可以省略 target 部分。 <varname>EXTRACT_DEPENDS</varname> (依赖的解压缩环境) 此变量用于指定 port 在解压缩时所需的可执行文件或其它资源文件。 和前一个变量类似， 它是一系列 path:dir:target 元组的列表。 例如， EXTRACT_DEPENDS= unzip:${PORTSDIR}/archivers/unzip 将检查名为 unzip 的可执行文件是否存在， 如果不存在， 则会进入到您的 ports 目录中的 archivers/unzip 子目录， 予以联编和安装。 这个依赖关系是在 extract target 的过程中检查的。 如果与 DEPENDS_TARGET 相同， 则可以略去 target 部分。 只有在其它方式都不可用 (默认是 gzip) 而且无法通过 所介绍的 USE_ZIP 或 USE_BZIP2 都不能达到需要时， 才应使用这个变量。 <varname>PATCH_DEPENDS</varname> (依赖的打补丁环境) 这个变量用于指定 port 在进行 patch 操作时所需的可执行文件或其它资源文件。 和前一个变量类似， 它是一组 path:dir:target 元组的表。 例如， PATCH_DEPENDS= ${NONEXISTENT}:${PORTSDIR}/java/jfc:extract 表示进入到您的 ports 目录中的 java/jfc 子目录， 并将其解压缩。 这个依赖关系是在 patch target 的过程中检查的。 target 部分如果和 DEPENDS_TARGET 相同， 就可略去不写。 <varname>USE_<replaceable>*</replaceable></varname> 提供了一系列变量， 用以封装大量 port 都用到的依赖关系。 虽然使用这些变量是可选的， 但它们能显著减少 port 的 Makefile 复杂性。 这些变量的共同特征在于， 它们的名字都是 USE_* 这样的形式。 这些变量的使用， 应严格限制于 port 的 Makefile 以及 ports/Mk/bsd.*.mk， 而绝不应用于表达用户能够设置的选项 — 这种情况下应采用 WITH_* 和 WITHOUT_* 这样的变量。 在 任何 情况下， 都不应在 /etc/make.conf 中配置任何 USE_*。 例如， 设置 USE_GCC=3.4 将导致每个 port 都依赖 gcc34， 甚至包括 gcc34 本身！ 常用的 <varname>USE_<replaceable>*</replaceable></varname> 变量 变量 含义 USE_BZIP2 此 port 的源码包是使用 bzip2 压缩的。 USE_ZIP 此 port 的源码包是用 zip 压缩的。 USE_BISON 此 port 在联编时使用 bison。 USE_CDRTOOLS 此 port 需要使用 cdrecord， 根据用户的喜好， 可能是 sysutils/cdrtools 或 sysutils/cdrtools-cjk。 USE_GCC 此 port 需要使用某一特定版本的 gcc 才能完成编译。 可以使用类似 3.4 这样的值来精确指定版本。 如果希望使用不低于某一版本的编译器， 则可以用 3.4+ 这样的形式。 如果与所希望的版本吻合， 则将使用基本系统中所提供的 gcc， 反之， 系统会从 ports 中安装所希望版本的 gcc， 并调整 CC 以及 CXX 变量的设置。
与 gmake 和 configure 脚本有关的变量在 中进行了介绍， 而 autoconf、 automake 以及 libtool 的介绍则可以在 找到。 介绍了与 Perl 有关的的变量。 中列出了关于 X11 的变量。 关于 GNOME 的变量在 ， 而关于 KDE 的则在 。 讲述了和 Java 有关的变量， 而 则包含了关于 Apache、 PHP 以及 PEAR 的介绍性信息。 关于 Python， 在 进行了讨论， 而关于 Ruby 的介绍， 则可以在 中找到。 提供了用于 SDL 应用程序的变量介绍， 最后， 包含了关于 Xfce 的信息。 在依赖关系中指定最低版本 在依赖某个其他 port 时， 可以采用下面的句法， 通过除 LIB_DEPENDS 之外的 *_DEPENDS 变量来指定最低版本： p5-Spiffy>=0.26:${PORTSDIR}/devel/p5-Spiffy 第一个字段指明了所依赖 package 的名字， 用以与 package 数据库中的某项匹配， 然后是比较算符， 以及 package 的版本号。 前面的例子中， 如果系统中安装了 p5-Spiffy-0.26 则认为满足了依赖条件。 关于依赖关系的补充说明 如前面所提到的那样， 在需要某一依赖的 port 时， 将调用 DEPENDS_TARGET 所指定的 target。 这一变量的默认值是 install。 这不是一个用户变量， 它不应在 port 的 Makefile 中予以定义。 如果您的 port 需要使用特殊的 target 来处理依赖关系， 应使用 *_DEPENDS 的 :target 部分， 而不是重定义 DEPENDS_TARGET 来完成。 当您输入 make clean 时， 其依赖的 port 也会自动进行清理。 如果您不希望如此， 应定义环境变量 NOCLEANDEPENDS。 如果 port 依赖一些重新联编需要花费很长时间的 port 时， 例如 KDE， GNOME 或 Mozilla 时， 这一方法会非常有用。 要无条件地依赖某个 port， 可以使用 ${NONEXISTENT} 作为 BUILD_DEPENDS 或 RUN_DEPENDS 的第一部分。 只有在您需要使用其它 port 提供的源代码时才应这样做。 通常也可以通过这样指定来缩短编译所需的时间。 例如 BUILD_DEPENDS= ${NONEXISTENT}:${PORTSDIR}/graphics/jpeg:extract 表示依赖 jpeg port 并将其解压缩。 循环的依赖关系是致命的 不要在 ports tree 中引入任何循环依赖关系! ports 联编技术不能够容忍循环依赖关系。 如果您引入了这样的关系， 就一定会有人安装的 FreeBSD 会因此而损坏， 而且这种现象会越来越多。 这些情形很难检测； 如果有疑虑， 在进行这样的修改之前， 务必执行： cd /usr/ports; make index。 这个过程在旧的机器上会很慢， 但能够让大量的用户 — 也包括您自己 — 拯救于由这种问题所造成的困惑之中。 <varname>MASTERDIR</varname> (主 port 所在的目录) 如果 port 需要依某些变量的设置 (举例来说， 分辨率或纸型) 来联编略有不同的预编译包， 则可以为每一个这样的包建立不同的目录， 这样可以让用户更容易地看到他们想要安装的版本， 但又能在这些 port 之间共用尽可能多的文件。 一般情况下， 如果运用得当， 除主目录之外都只需要很短的 Makefile。 这些 Makefile 中， 可以用 MASTERDIR 来指定其它文件所在的目录。 另外， 还应使用一个变量作为 PKGNAMESUFFIX 的一部分， 以便为不同的包给出不同的命名。 用例子来阐述这些会更为明晰。 以下是 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 也提供了全部常规的补丁， 以及打包用到的文件等等内容。 如果您在那里输入 make， 它将使用默认的分辨率值 (300) 并正常地联编 port。 对于其它分辨率而言， 以下是 完整的 xdvi118/Makefile： RESOLUTION= 118 MASTERDIR= ${.CURDIR}/../xdvi300 .include "${MASTERDIR}/Makefile" (xdvi240/Makefile 和 xdvi400/Makefile 是相似的)。 MASTERDIR 定义会告诉 bsd.port.mk 常规的目录， 例如 FILESDIR 以及 SCRIPTDIR 应在 xdvi300 中查找。 RESOLUTION=118 这行将覆盖在 xdvi300/Makefile 中所作的 RESOLUTION=300 设置， 从而 port 将以分辨率为 118 的设置来联编。 联机手册 MAN[1-9LN] 这些变量， 会自动地将联机手册加到 pkg-plist (这也意味着 不能 在 pkg-plist 中列出联机手册 — 参见 PLIST 的生成 来了解更多细节)。 此外， 这也会让安装阶段自动地根据在 /etc/make.conf 中所作的 NO_MANCOMPRESS 设置来自动对联机手册文件执行压缩或解压缩操作。 如果 port 尝试通过使用符号连接或硬连接将联机手册安装为多个名字， 就必须使用 MLINKS 变量来予以明示。 由 port 创建的连接， 将由 bsd.port.mk 删除和重建， 以确认它们指向了正确的文件。 任何在 MLINKS 中列出的文件都不应在 pkg-plist 中再出现。 要指定是否在安装时对联机手册进行压缩， 可以使用 MANCOMPRESSED 变量。 这一变量可以取三种值， yes、 no 和 maybe 之一。 yes 表示联机手册已经以压缩的形式安装， no 表示还没有， 而 maybe 则表示所安装的软件会尊重 NO_MANCOMPRESS 的设置值， 因此 bsd.port.mk 不需要特别做什么事情。 如果设置了 USE_IMAKE 而未定义 NO_INSTALL_MANPAGES， MANCOMPRESSED 会自动设为 yes， 反之则是 no。 除非默认值不合适， 否则就不需要在 port 中明确地加以改变。 如果 port 将联机手册放到了 PREFIX 之外的其它目录， 则应使用 MANPREFIX 来加以设置。 此外， 如果只有某些部分的联机手册会安装到不标准的位置， 例如某些 perl 模块的 port， 还可以使用 MANsectPREFIX (此处 sect 是 1-9、 L 或 N 之一) 来指定。 如果您的联机手册需要装入专用于某一语言专用的子目录， 需要将 MANLANG 设为那种语言的名字。 此变量的默认值是 "" (也就是只有英语)。 下面是一个综合的例子。 MAN1= foo.1 MAN3= bar.3 MAN4= baz.4 MLINKS= foo.1 alt-name.8 MANLANG= "" ja MAN3PREFIX= ${PREFIX}/share/foobar MANCOMPRESSED= yes 这表示 port 会安装六个文件； ${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 可能会通过您的 port 安装， 也可能不会。 无论如何， 都会创建一个符号连接， 把 foo(1) 和 alt-name(8) 联机手册连起来。 假如只有部分联机手册是翻译过的， 则可以使用一些根据 MANLANG 内容动态生成的变量： MANLANG= "" de ja MAN1= foo.1 MAN1_EN= bar.1 MAN3_DE= baz.3 这相当于下列文件： ${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 Info 文件 如果软件包需要安装 GNU info 文件， 则需要在 INFO 变量中一一列出 (不需要指定 .info 后缀)。 系统假定这些文件均会安装到 PREFIX/INFO_PATH 目录中。 如果软件包有需要， 也可以通过修改 INFO_PATH 来指定不同的位置。 不过， 并不推荐这样做。 所有列出的项目均是相对于 PREFIX/INFO_PATH 的文件路径。 例如， lang/gcc34 表示将 info 文件安装到 PREFIX/INFO_PATH/gcc34， 因此 INFO 应写成类似这样： INFO= gcc34/cpp gcc34/cppinternals gcc34/g77 ... 这样安装/卸载代码就会自动地在注册包之前将它们加入到临时的 pkg-plist 中了。 Makefile 选项 某些大型应用程序可以在联编时使用一系列配置选项， 用以在系统中已经安装了某些库或应用程序时增加一些功能。 例如， 选择某种自然 (人类的) 语言， GUI 或命令行界面， 由于并不是所有的用户都希望使用这些库或者应用程序， port 系统提供了一组方便的机制， 来让 port 的作者控制联编时的配置。 支持这些特性可以让用户体验更好， 并达到事半功倍的效果。 开关 (Knobs) <varname>WITH_<replaceable>*</replaceable></varname> 和 <varname>WITHOUT_<replaceable>*</replaceable></varname> 这些变量是为系统管理员准备的。 许多这样的变量被标准化并置于 ports/KNOBS 文件。 在创建一个 port 的时候，不要使用某个应用程序专有的 knob 名称，比如对于 Avahi 这个 port，应该用 WITHOUT_MDNS 而不是 WITHOUT_AVAHI_MDNS。 您不应假定每一个 WITH_* 都会有对应的 WITHOUT_* 变量， 反之亦然。 一般而言， 会使用默认值。 除非另有说明， 这些变量都是测试是否定义， 而不是它们设置了 YES 或 NO。 常见的 <varname>WITH_<replaceable>*</replaceable></varname> 和 <varname>WITHOUT_<replaceable>*</replaceable></varname> 变量 变量 意义 WITHOUT_NLS 表示不需要国际化支持， 这可以节省编译所消耗的时间。 默认情况下， 会启用国际化支持。 WITH_OPENSSL_BASE 使用基本系统中的 OpenSSL 版本。 WITH_OPENSSL_PORT 从 security/openssl 安装 OpenSSL，即使基本系统中的版本是最新的。 WITHOUT_X11 如果 port 能够在是否包含 X 支持的情况下分别联编， 则一般情况应该默认以包含 X 支持的配置来联编。 如果定义了这一变量， 则应联编不包含 X 支持的版本。
开关 (knob) 的命名 我们建议 port 的开发人员使用相似的开关， 以便最终用户使用， 并减少开关名称的总数。 最为常用的开关名字可以在 KNOBS 文件中找到。 开关的名字应反映其功能。 如果 port 的 PORTNAME 包括 lib- 前缀， 则开关名中应删去 lib- 前缀。 <varname>OPTIONS</varname> (菜单式可选项) 背景 OPTIONS 将为正在安装 port 的用户提供一个包含可用选项的对话框， 并将用户的选择保存到 /var/db/ports/portname/options 中。 下次重新联编 port 时， 这些选项将被再次使用。 这样一来， 就不需要劳神去记忆您之前联编 port 时的那几十个 WITH_* 和 WITHOUT_*选项了！ 当用户运行 make config (或首次运行 make build) 时， 框架会首先检查 /var/db/ports/portname/options。 如果这个文件不存在， 则它会使用 OPTIONS 的值来生成一个可以启用或禁用各个选项的对话框。 随后， 用户的选择将保存到 options 文件中， 并被用于联编 port。 如果新版本的 port 新增了 OPTIONS， 则系统会再次给出对话框， 并根据先前的 OPTIONS 配置预设先前存在的配置。 使用 make showconfig 可以查看保存的配置。 此外， make rmconfig 可以删除已经保存的配置。 语法 OPTIONS 变量的语法是： OPTIONS= OPTION "说明性文字" 默认值 ... 默认值必须是 ON 和 OFF 之一。 这种三元组可以使用多次。 定义 OPTIONS 变量的值， 必须在引入 bsd.port.options.mk 之前进行。 而 WITH_* 和 WITHOUT_* 变量则只能在引入了 bsd.port.options.mk 之后才可以进行检测。 使用 bsd.port.pre.mk 也可以达到同样的目的， 在系统开始提供 bsd.port.options.mk 之前的许多 port 都在使用这种用法。 不过， 请注意 bsd.port.pre.mk 会要求某些变量已经进行过定义， 如 USE_* 等。 简单的 <varname>OPTIONS</varname> 用法 OPTIONS= FOO "启用 foo 选项" On \ BAR "支持 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> Old style use of <varname>OPTIONS</varname> 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> 自动激活的特性 在使用 GNU configure 脚本时， 一定要小心有些特性会由其自动检测而激活。 您应通过明确地指定相应的 --without-xxx 或 --disable-xxx 参数到 CONFIGURE_ARGS 来禁用不希望的特性。 处理选项时的错误做法 .if defined(WITH_FOO) LIB_DEPENDS+= foo.0:${PORTSDIR}/devel/foo CONFIGURE_ARGS+= --enable-foo .endif 在前面的例子中， 假设系统中已经安装了 libfoo 库。 用户可能并不希望应用程序使用 libfoo， 因此他在 make config 对话框中关掉了这个选项。 但是， 应用程序的 configure 脚本检测到了系统中存在这个库， 并将其加入到了最终可执行文件支持的功能中。 现在， 如果用户决定从系统中卸载 libfoo 时， ports 系统就无法保护这个应用程序免遭破坏了 (因为没有记录 libfoo 的依赖关系)。 处理选项时的正确做法 .if defined(WITH_FOO) LIB_DEPENDS+= foo.0:${PORTSDIR}/devel/foo CONFIGURE_ARGS+= --enable-foo .else CONFIGURE_ARGS+= --disable-foo .endif 在第二个例子中， libfoo 库被明确禁用。 即使系统中已经安装了这个库， configure 脚本也不会启用相应的功能了。 指定工作临时目录 每个 port 都会被解压缩到一个工作临时目录中， 这个目录必须是可写的。 ports 系统默认情况下会将 DISTFILES 解压缩到一个叫做 ${DISTNAME} 的目录中。 换言之， 如果设了： PORTNAME= foo PORTVERSION= 1.0 则 port 的源码包文件的顶级目录将是 foo-1.0。 如果这不是所希望的情形， 您可以修改一系列变量的设置。 <varname>WRKSRC</varname> (开始联编操作的目录名) 这个变量给出了在应用程序的源代码包解压缩之后所生成的目录的名字。 如果我们之前的例子解压缩生成一个叫做 foo (而不是 foo-1.0) 的目录， 您应： WRKSRC= ${WRKDIR}/foo 或者， 也可能是 WRKSRC= ${WRKDIR}/${PORTNAME} <varname>NO_WRKSUBDIR</varname> (不需要临时的联编目录) 如果 port 完全不需要写入到某个子目录中， 您应设置 NO_WRKSUBDIR 以明示这一点。 NO_WRKSUBDIR= yes 处理冲突 针对不同的 package 或 port 之间的冲突情形， 系统提供了不同的变量来协助开发人员进行表达： CONFLICTS、 CONFLICTS_INSTALL 和 CONFLICTS_BUILD。 这些用于描述冲突的变量会自动地设置 IGNORE， 后者的完整介绍， 可以在 找到。 在删去相互冲突的 port 时， 建议将 CONFLICTS 保留几个月， 以便让那些不经常更新系统的用户能够看到。 <varname>CONFLICTS_INSTALL</varname> 如果您的软件包不能与某些软件包同时安装 (例如由于安装同样的文件到相同的位置、 运行时不兼容等等)， 则应把其它软件包的名字列在 CONFLICTS_INSTALL 变量中。 此处可以使用 shell 通配符， 如 * 和 ?。 列出其它软件包的名字时需要遵循它们在 /var/db/pkg 中出现的样子。 请确保 CONFLICTS_INSTALL 不会匹配到您正制作的这个预编译包的名字， 否则， 使用 FORCE_PKG_REGISTER 来强制安装就没有办法进行了。 对于 CONFLICTS_INSTALL 的检查是在联编过程之后、 安装开始之前进行的。 <varname>CONFLICTS_BUILD</varname> 如果您的软件包在系统中存在某些其它软件包时不能完成联编， 则应把其它软件包的名字列在 CONFLICTS_BUILD 变量中。 此处可以使用 shell 通配符， 如 * 和 ?。 列出其它软件包的名字时需要遵循它们在 /var/db/pkg 中出现的样子。 对于 CONFLICTS_BUILD 的检查是在联编过程开始之前进行的。 联编时的冲突不会在编译好的包中予以记录。 <varname>CONFLICTS</varname> 如果您的 port 在某些其它 port 已经存在的情况下既不能联编， 也不能安装， 则应把其它软件包的名字列在 CONFLICTS 变量中。 此处可以使用 shell 通配符， 如 * 和 ?。 列出其它软件包的名字时需要遵循它们在 /var/db/pkg 中出现的样子。 请确保 CONFLICTS 不会匹配到您正制作的这个预编译包的名字， 否则， 使用 FORCE_PKG_REGISTER 来强制安装就没有办法进行了。 对于 CONFLICTS 的检查是在联编过程之后、 安装开始之前进行的。 安装文件 INSTALL_* 宏 一定要使用由 bsd.port.mk 提供的宏， 以确保在您自己的 *-install target 中能够以正确的属主和权限模式安装文件。 INSTALL_PROGRAM 是安装可执行二进制文件的命令。 INSTALL_SCRIPT 是安装可执行脚本文件的命令。 INSTALL_LIB 是安装动态连接库的命令。 INSTALL_KLD 是用于安装可加载式内核模块的命令。 在某些平台上， 当对内核模块进行 strip 之后会导致一些问题， 因此您应使用这个宏而不是 INSTALL_PROGRAM 来安装内核模块。 INSTALL_DATA 是安装可共享数据的命令。 INSTALL_MAN 是安装联机手册和其他文档的命令 (注意它并不会执行压缩操作)。 这些宏展开后基本上都是包含适当参数的 install 命令。 对可执行文件和动态连接库做脱模 (strip) 操作 除非不得不进行， 否则不要手工对可执行文件作脱模操作。 所有文件在安装时都应脱模， 但 INSTALL_PROGRAM 宏会在安装的同时对其进行脱模 (参见下一节的内容)。 INSTALL_LIB 宏 如果您需要对某一文件进行脱模， 但不希望使用 INSTALL_PROGRAM 及 INSTALL_LIB 宏， 则应使用 ${STRIP_CMD} 来处理程序。 一般而言这应该在 post-install target 中进行。 例如： post-install: ${STRIP_CMD} ${PREFIX}/bin/xdl 可以使用 &man.file.1; 命令来检查所安装的可执行文件是否进行过脱模。 如果它没有给出 not stripped 的提示， 则表示已经做过脱模了。 另外， &man.strip.1; 不会对已经脱模过的文件重新脱模， 它会直接退出的。 安装一个目录下的全部文件 有时， 会有需要安装大量的文件， 并保持其层次结构， 例如， 将整个目录结构从 WRKSRC 复制到 PREFIX 的目标目录。 针对这种情况， 系统提供了两个宏。 使用这些宏， 而不是直接使用 cp 的优势是它们能够确保目标文件的属主和权限正确。 第一个宏， COPYTREE_BIN 将所有安装的文件视为可执行文件， 因而适合安装文件到 PREFIX/bin。 第二个宏， COPYTREE_SHARE， 则不会设置可执行权限， 因此适合于将文件安装到 PREFIX/share 下。 post-install: ${MKDIR} ${EXAMPLESDIR} (cd ${WRKSRC}/examples/ && ${COPYTREE_SHARE} \* ${EXAMPLESDIR}) 这个例子将原作者提供的整个 examples 目录复制到您 port 指定的安装示范文件的位置。 post-install: ${MKDIR} ${DATADIR}/summer (cd ${WRKSRC}/temperatures/ && ${COPYTREE_SHARE} "June July August" ${DATADIR}/summer/) 这个例子将把夏季的三个月的数据， 复制到 DATADIR 中的 summer 子目录。 经由设置 COPYTREE_* 宏的第三个参数， 您还可以为 find 指定额外的参数。 例如， 如果希望安装除了 Makefile 之外的其他所有文件， 可以使用下述命令。 post-install: ${MKDIR} ${EXAMPLESDIR} (cd ${WRKSRC}/examples/ && \ ${COPYTREE_SHARE} \* ${EXAMPLESDIR} "! -name Makefile") 需要注意的是， 这些宏并不能自动将所安装的文件加到 pkg-plist 中， 您还是需要自行列出它们。 安装附加的文档 如果您的软件包含了标准的联机手册和 info 手册以外的文档， 而且您认为它们对用户会有用， 请把这些文档安装到 PREFIX/share/doc 下。 和前面类似， 这也可以在 post-install target 中完成。 为您的 port 建立一个新的目录。 这个目录的名字应该反映它是属于哪个 port 的。 通常建议使用 PORTNAME。 不过， 如果您认为不同版本的 port 可能会同时安装， 也可以用完整的 PKGNAME。 另外， 应该让是否安装取决于变量 NOPORTDOCS 的设置， 这样用户就能够在 /etc/make.conf 中禁止安装它。 例如： post-install: .if !defined(NOPORTDOCS) ${MKDIR} ${DOCSDIR} ${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${DOCSDIR} .endif 这里是一些便于使用的变量， 以及它们在 Makefile 中默认的展开方式： DATADIR 会展开成 PREFIX/share/PORTNAME。 DATADIR_REL 会展开成 share/PORTNAME。 DOCSDIR 会展开成 PREFIX/share/doc/PORTNAME。 DOCSDIR_REL 会展开成 share/doc/PORTNAME。 EXAMPLESDIR 会展开成 PREFIX/share/examples/PORTNAME。 EXAMPLESDIR_REL 会展开成 share/examples/PORTNAME。 NOPORTDOCS 只控制将要安装到 DOCSDIR 的那些文档， 而不应影响标准的联机手册以及 info 手册的安装。 安装到 DATADIR 和 EXAMPLESDIR 的文件则相应地受 NOPORTDATA 和 NOPORTEXAMPLES 控制。 这些变量也会被导出到 PLIST_SUB 中。 只要可能， 它们的值就将在那里以相对于 PREFIX 的路径形式出现。 也就是说， share/doc/PORTNAME 在装箱单中默认情况下会替换掉 %%DOCSDIR%%， 等等。 (更多的 pkg-plist 代换可以在 这里 找到。) 所有非无条件安装的文档文件和目录， 都应在 pkg-plist 出现， 并且使用 %%PORTDOCS%% 前缀， 例如： %%PORTDOCS%%%%DOCSDIR%%/AUTHORS %%PORTDOCS%%%%DOCSDIR%%/CONTACT %%PORTDOCS%%@dirrm %%DOCSDIR%% 如果不希望在 pkg-plist 中逐个列举文档文件， port 也可以将 PORTDOCS 设置为一组文件及其 shell glob 模式， 通过这种方式来加入到最终的装箱单中。 这些名字应是相对于 DOCSDIR 的。 因此， 使用了 PORTDOCS， 并将文档安装到非标准位置的 port， 应相应地设置 DOCSDIR。 如果有在 PORTDOCS 中列出目录， 或者这一变量中的 glob 模式匹配到了目录， 则整个子树中的文件和目录， 都将被注册到最终的装箱单中。 如果定义了 NOPORTDOCS， 则 PORTDOCS 中定义的文件和目录将不被安装或加入装箱单。 是否安装文档到前面所说的 PORTDOCS 仍取决于 port 本身。 下面是一个典型的使用 PORTDOCS 的例子： PORTDOCS= README.* ChangeLog docs/* 与 PORTDOCS 类似， 对应于 DATADIR 和 EXAMPLESDIR 的变量分别是 PORTDATA 和 PORTEXAMPLES。 您也可以使用 pkg-message 这个文件， 来在安装时显示一些信息。 参见 关于使用 pkg-message 的这一节 以了解进一步的详情。 需要说明的是， 并不需要把 pkg-message 加到 pkg-plist 中。 子目录 尽可能让 port 将它创建的文件， 放置到 PREFIX 中正确的位置。 一些 port 会把各式各样的东西混在一起， 并放到一个同名的目录中， 这是不对的。 另外， 许多 port 会把除了可执行文件、 头文件和联机手册之外的所有文件， 全都一股脑地放到 lib 中， 这在和 BSD 配合使用时会有问题。 多数文件， 应被放到下列位置之一： etc (安装/配置文件)、 libexec (由系统内部调用的可执行文件)、 sbin (为超级用户/管理员提供的可执行文件)、 info (用于 info 浏览器的文档) 或 share (平台无关的其它文件)。 请参见 &man.hier.7; 以了解进一步的详情； 针对 /usr 的那些规则， 同样也适用于 /usr/local。 例外情况是那些需要和 USENET news 打交道的 port， 它们可以选择采用 PREFIX/news 作为文件的目的地。 特殊情况 有一些您在创建port时的特殊情况，我们在这里提一下。 共享库 如果您的port安装了一个或多个共享库,那么请定义一个 USE_LDCONFIG make 变量， 在post-install标记把它注册进共享库 缓冲时会调用bsd.port.mk去运行 ${LDCONFIG} -m来指向新库的安装目录。 (通常是 PREFIX/lib) 同样，您也可以适当的在您的 pke-plist文件 中定义一组@exec /sbin/ldconfig -m 和@unexec /sbin/ldconfig -R， 那么用户可以在安装后马上 就能使用，并且在卸载软件包后系统也不会认为这些共享库仍然存在。 USE_LDCONFIG= yes 如果您需要把共享库安装在缺省的位置之外， 可以通过定义 make 变量 USE_LDCONFIG 来改变默认的安装路径， 它包含安装共享库的目录列表 例如： 如果您的共享库安装到 PREFIX/lib/foo 和 PREFIX/lib/bar directories目录，您可以在您的 Makefile中这样设置: USE_LDCONFIG= ${PREFIX}/lib/foo ${PREFIX}/lib/bar 请务必仔细检查， 通常这是完全不必要的， 或者可以通过 -rpath 或在连接时设置 LD_RUN_PATH 来避免 (参见 lang/moscow_ml 给出的例子)， 或者用一个 shell 封装程序来在执行可执行文件之前设置 LD_LIBRARY_PATH， 类似 www/seamonkey 那样。 当在 64-位系统上安装 32-位 的函数库时， 请使用 USE_LDCONFIG32。 尽量将共享库版本号保持为 libfoo.so.0 这样的格式。 我们的运行环境连接器只会检查主 (第一个) 版本数字。 如果在更新 port 时升级了其库的主版本号， 则其它所有连接了受影响的库的 port 的 PORTREVISION 都应递增， 以强制它们采用新版本的库重新编译。 Ports 的发行限制 众多协议，并且其中的一些致力于 限制怎样的应用程序能被打包， 是否能用于销售赢利等等。 做为一名porter您有义务去阅读软件的协议 并且确保FreeBSD 项目不必为通过FTP/HTTP 或CD-ROM重新发布源码或编译的二进制而解释 什么。如果有任何疑问， 请联系 &a.ports;。 处于这种情况，就可以设置以下描述 的变量。 <varname>NO_PACKAGE</varname> (禁止编译结果打包) 这个变量表示我们可能不能生成这个应用 程序的二进制文件。例如，他的协议不允许 二进制文件的再次发行，或者他可能禁止从 补丁过的源代码打包的发行。 不管怎么样，port的 DISTFILES 可以 随意的镜像到FTP/HTTP。除非NO_CDROM 变量也被设置，软件包也可以发行在一张CD-ROM （或类似的媒介上）。 NO_PACKAGE也能用在当二进制包 不是非常有用，并且这个应用软件经常要 从源代码编译。例如：当这个应用软件在 编译的时候要在配置信息中指定特定的硬件 代码时，可以设置NO_PACKAGE。 NO_PACKAGE应该设置成字符串 来描述为什么这个软件 不能打包。 <varname>NO_CDROM</varname> (禁止以 CDROM 发行预编译包) 这个变量仅仅指出虽然我们允许 生成二进制包，但也许我们既不能把这个 软件包也不能把port的DISTFILES 放在光盘（或类似的媒介）上销售。但不管怎么样， 二进制包和port的DISTFILES 可以从FTP/HTTP上获得。 如果这个变量和 NO_PACKAGE一起被设置， 那么这个port的DISTFIELS 将只能从FTP/HTTP上获得。 NO_CDROM 应该被设置成一个字符串 来描述为什么这个port不能重新发布在CD-ROM上。 例如：如果这个port的协议仅仅是用于非商业活动 ,那么这个变量就能设置了。 <varname>NOFETCHFILES</varname> (不自动抓取指定的文件) 在 NOFETCHFILES 变量中定义的文件， 不会自动从 MASTER_SITES 抓取。 一种典型的用例是， 使用来自某个软件供应商提供的 CD-ROM 上的文件。 用于检查在 MASTER_SITES 上是否包含了所需文件的工具， 应忽略这些文件， 而不是报告它们不存在。 <varname>RESTRICTED</varname> (禁止任何形式的再分发) 如果应用程序既不允许镜像其 DISTFILES， 也不允许发布其预编译版本的包， 设置它就可以了。 NO_CDROM 或 NO_PACKAGE 不应与 RESTRICTED 同时设置， 因为它包含了这些情形。 RESTRICTED 应设置为一个说明 port 为何不能发布的串。 典型情况可能是由于 port 包含了专有的软件， 因而用户需要自行下载 DISTFILES， 可能是注册或者同意某一 EULA 的条款。 <varname>RESTRICTED_FILES</varname> (禁止某些文件的再分发) 当设置了 RESTRICTED 或 NO_CDROM 时， 这个变量会默认设置为 ${DISTFILES} ${PATCHFILES}， 否则它会为空。 如果只有某些源码包文件是受限的， 则可以用这个变量来指明它们。 注意， port committer 应该在 /usr/ports/LEGAL 中为每一个源码包文件撰写对应的项目， 并介绍这些限制的原因。 联编机制 Ports 的并行联编 &os; ports 框架支持使用多个 make 子进程来进行并行编译， 在 SMP 上这可以全面地利用系统的 CPU 计算能力， 令 port 的联编过程更快、 更有效率。 目前这是通过向原作者的代码传递 &man.make.1; 参数 -jX 来实现的。 遗憾的是， 并不是所有的 port 都能够很好地处理这个选项。 因此， 必须通过明确地在 Makefile 中指定 MAKE_JOBS_SAFE=yes 来启用这一功能。 从 port 监护人的角度还有一个控制的方法是设置 MAKE_JOBS_UNSAFE=yes 变量。 这个变量主要是用于已知不能与 -jX 配合使用的 port， 即使用户在 /etc/make.conf 中定义了 FORCE_MAKE_JOBS=yes 变量， 系统也不会使用并行编译。 <command>make</command>、 <command>gmake</command>， 以及 <command>imake</command> 如果 port 用到了 GNU make， 应设置 USE_GMAKE=yes。 与 <application>gmake</application> 有关的 port 变量 变量 意义 USE_GMAKE 此 port 需要使用 gmake 来完成联编过程。 GMAKE 不在 PATH 中时， gmake 的完整路径。
对于 X 应用程序的 port， 如果它使用 imake 根据 Imakefile 文件来生成 Makefile， 则应设置 USE_IMAKE=yes。 这会使联编过程中的配置 (configure) 阶段自动执行 xmkmf -a。 如果 标志会给您的 port 带来麻烦， 则需设置 XMKMF=xmkmf。 如果 port 用到了 imake 但并不使用 install.man target， 则应设置 NO_INSTALL_MANPAGES=yes。 如果 port 源文件的 Makefile 的主联编 target 是 all 以外的名字， 应对应地设置 ALL_TARGET。 对于 install 而言， 对应的变量是 INSTALL_TARGET。 <command>configure</command> 脚本 假如 port 使用 configure 脚本来从 Makefile.in 生成 Makefile 文件， 需要设置 GNU_CONFIGURE=yes。 如果希望传额外的参数给 configure 脚本 (默认参数为 --prefix=${PREFIX} --infodir=${PREFIX}/${INFO_PATH} --mandir=${MANPREFIX}/man --build=${CONFIGURE_TARGET})， 应通过 CONFIGURE_ARGS 来指定这些参数。 类似地， 可以通过 CONFIGURE_ENV 变量来传递一些环境变量。 如果您的软件包使用 GNU configure， 而生成的可执行文件命名方式 怪异 如 i386-portbld-freebsd4.7-应用程序名， 则需要更进一步地通过改变 CONFIGURE_TARGET 变量来按照较新版本的 autoconf 生成的脚本所希望的方式指定 target。 其方法是， 紧随 Makefile 中 GNU_CONFIGURE=yes 一行之后加入： CONFIGURE_TARGET=--build=${MACHINE_ARCH}-portbld-freebsd${OSREL} 用于用到了 <command>configure</command> 脚本的 port 的变量 变量 意义 GNU_CONFIGURE 此 port 需要用 configure 脚本来准备联编。 HAS_CONFIGURE 与 GNU_CONFIGURE 类似， 但默认的 configure target 并不加入 CONFIGURE_ARGS。 CONFIGURE_ARGS 希望传给 configure 脚本的额外参数。 CONFIGURE_ENV 希望在执行 configure 脚本时设置的环境变量。 CONFIGURE_TARGET 替换默认的 configure target。 其默认值是 ${MACHINE_ARCH}-portbld-freebsd${OSREL}。
使用 <command>scons</command> 如果您的 port 使用 SCons， 就需要定义 USE_SCONS=yes 了。 使用 <command>scons</command> 的 port 会用到的变量 变量 含义 SCONS_ARGS 当前 port 希望传给 SCons 环境的参数。 SCONS_BUILDENV 希望在系统环境中设置的变量。 SCONS_ENV 希望在 SCons 环境中设置的变量。 SCONS_TARGET 传递给 SCons 的最后一个参数， 类似于 MAKE_TARGET。
如果希望让第三方的 SConstruct 尊重通过 SCONS_ENV (其中最重要的是 CC/CXX/CFLAGS/CXXFLAGS 配置) 传给 Scons 的配置， 则需要对 SConstruct 进行修改， 使联编的 Environment 按下列方式建立： env = Environment(**ARGUMENTS) 其后， 可以通过 env.Append 和 env.Replace 来对它进行修改。 利用 GNU autotools 入门 众多 GNU autotools 提供了一种在多重操作系统和机器架构之上联编软件的抽象机制。 在 Ports Collection 中， port 可以通过简单的方法来使用这些工具： USE_AUTOTOOLS= 工具:版本[:操作] ... 撰写本书时， 工具 可以设置为 libtool、 libltdl、 autoconf、 autoheader、 automake 或 aclocal 之一。 版本 用来指定希望使用的工具的特定版本 (参见 devel/{automake,autoconf,libtool}[0-9]+ 以了解有效的版本号)。 操作 是一个可选的扩展选项， 用于修改如何使用工具。 可以同时指定多个不同的工具， 可以在一行中指定， 也可以用 Makefile 的 += 结构。 最后， 可以使用一个特殊的名为 autotools 的工具， 它会安装全部可用的 autotools 版本， 以适应跨平台开发的需要。 您可以通过安装 devel/autotools port 来达到这一目的。 <command>libtool</command> 使用 GNU 联编框架的共享库通常会使用 libtool 来调整共享库的编译和安装， 以便与所运行的操作系统相匹配。 通常的做法是使用应用程序所附带的 libtool 副本。 如果需要使用外部的 libtool， 则可以使用 Ports 套件提供的版本： USE_AUTOTOOLS= libtool:版本[:env] 如果不使用额外的操作符， libtool:版本 表示希望联编框架使用 configure 脚本来对系统所安装的 libtool 进行修补。 这会暗含地定义 GNU_CONFIGURE。 更进一步， 联编框架还会设置一系列 make 和 shell 变量用于 port 后续的操作。 请参见 bsd.autotools.mk 了解进一步的详情。 如果指定了 :env 操作符， 则表示只设置环境， 而跳过其他的操作。 最后， LIBTOOLFLAGS 和 LIBTOOLFILES 可以用来替换最常修改的参数， 以及将被 libtool 修补的文件。 多数 port 不需要这样做。 请参见 bsd.autotools.mk 以了解进一步的细节。 <command>libltdl</command> 一些 ports 会使用 libltdl 库， 后者是 libtool 软件包的一部分。 使用这个库并不意味着必须使用 libtool 本身， 因此提供了另一组结构。 USE_AUTOTOOLS= libltdl:版本 目前， 这一设置所做的全部工作是将 LIB_DEPENDS 设置为适当的 libltdl port， 并作为一项方便的功能， 协助开发人员消除在 USE_AUTOTOOLS 框架以外的， 对于 autotools port 的依赖。 这个工具并不提供其它的操作符。 <command>autoconf</command> 和 <command>autoheader</command> 某些 port 并没有直接提供 configure 脚本， 但包含了作为 autoconf 模板的 configure.ac 文件。 可以用下列设置来要求 autoconf 创建 configure 脚本， 并使用 autoheader 来为 configure 脚本创建模板头文件。 USE_AUTOTOOLS= autoconf:版本[:env] 以及 USE_AUTOTOOLS= autoheader:版本 上述设置会暗含使用 autoconf:版本。 对于 libtool， 设置与前面类似。 如果指定可选的 :env 操作符， 则表示只设置用于后续工作的环境。 如果不指定， 则会对 port 进行相应的修补和重新配置。 其它的可选变量， 如 AUTOCONF_ARGS 和 AUTOHEADER_ARGS 可以通过 port 的 Makefile 来显式地指定替换。 类似 libtool， 多数 port 并不需要这样做。 <command>automake</command> 和 <command>aclocal</command> 某些软件包只提供了 Makefile.am 文件。 这些文件必须首先用 automake 转换为 Makefile.in 并使用 configure 来生成实际的 Makefile。 类似地， 偶尔会有一些软件包不提供联编所需的 aclocal.m4 文件。 这些文件可以通过使用 aclocal 来扫描 configure.ac 或 configure.in 自动生成。 aclocal 与 automake 有和 autoheader 与 autoconf 在前面一节中所介绍的相类似的关系。 aclocal 会暗含使用 automake， 因此： USE_AUTOTOOLS= automake:版本[:env] 和 USE_AUTOTOOLS= aclocal:版本 也自动暗含使用 automake:版本。 与 libtool 类似， autoconf 如果使用了可选的 :env 操作符表示仅仅设置用于后续使用的环境， 如果不设置， 则会对 port 进行重新配置。 对于 autoconf 和 autoheader 而言， automake 和 aclocal 提供了对应的可选参数变量 AUTOMAKE_ARGS 和 ACLOCAL_ARGS， 如果需要的话， 可以在 port 的 Makefile 中指定。 使用 GNU <literal>gettext</literal> 基本用法 如果您的 port 需要使用 gettext， 只要将 USE_GETTEXT 设置为 yes， 您的 port 就会增加对 devel/gettext 的依赖。 USE_GETTEXT 也可以指定为所需的 libintl 库的版本， 它是 gettext 的基本组成部分， 尽管如此， 强烈建议您不要 使用这个功能： 您的 port 应能与目前版本的 devel/gettext 配合工作。 在 port 中相当常见的情况下， 会需要同时使用 gettext 和 configure。 一般而言， GNU configure 能够自动定位到 gettext。 如果它没有成功地完成这项工作， 则可以通过类似下面这样的 CPPFLAGS 和 LDFLAGS 将 gettext 的位置告诉它： USE_GETTEXT= yes CPPFLAGS+= -I${LOCALBASE}/include LDFLAGS+= -L${LOCALBASE}/lib GNU_CONFIGURE= yes CONFIGURE_ENV= CPPFLAGS="${CPPFLAGS}" \ LDFLAGS="${LDFLAGS}" 当然， 不需要传参数给 configure 时， 代码可以更为简练： USE_GETTEXT= yes GNU_CONFIGURE= yes CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include" \ LDFLAGS="-L${LOCALBASE}/lib" 可选用法 一些软件产品提供了禁用 NLS 的能力， 例如， 在 configure 时， 指定 参数。 如果您 port 的软件支持这种配置， 则应根据 WITHOUT_NLS 的设置来有条件地使用 gettext。 对于比较简单和不太复杂的 port， 您可以使用下列结构： GNU_CONFIGURE= yes .if !defined(WITHOUT_NLS) USE_GETTEXT= yes PLIST_SUB+= NLS="" .else CONFIGURE_ARGS+= --disable-nls PLIST_SUB+= NLS="@comment " .endif 您要做的下一件事是合理地安排装箱单文件， 使其根据用户配置来决定是否将消息编录 (message catalog) 文件放入最终的装箱单。 前面已经介绍了在 Makefile 中所需的写法， 这种做法在 高级 pkg-plist 用法 这节中进行了介绍。 简单地说， 在 pkg-plist 中出现的 %%NLS%% 均会在禁用 NLS 时自动替换为 @comment ， 反之则替换为空串。 这样， 在最终的装箱单中带 %%NLS%% 的行， 在 NLS 关闭的情况下就会变为注释， 反之， 这些前缀就会自动删掉。 现在需要做的事情就是把 %%NLS%% 插到 pkg-plist 中的消息编录文件的那些行开头， 例如： %%NLS%%share/locale/fr/LC_MESSAGES/foobar.mo %%NLS%%share/locale/no/LC_MESSAGES/foobar.mo 在比较复杂的情形中， 您可能需要使用更高级的技术， 例如 动态生成装箱单 等。 处理消息编录目录 在安装消息编录文件时还有一个需要注意的地方。 这些文件会放到 LOCALBASE/share/locale 下与语言对应的目录中， 这些目录一般您的 port 不需要创建和删除。 最常用的语言的目录已经在 /etc/mtree/BSD.local.dist 中列出； 也就是说， 它们是基本系统的一部分。 其他一些语言的目录， 则由 devel/gettext 控制。 您最好查看一下 pkg-plist， 以确定是否正在安装某种不常用语言的文件。 使用 <literal>perl</literal> 如果 MASTER_SITES 设为 MASTER_SITE_PERL_CPAN， 则应尽量把 MASTER_SITE_SUBDIR 设置为顶级目录的名字。 例如， 对 p5-Module-Name 而言推荐的名字是 Module。 您可以在 cpan.org 找到顶级目录的名字。 这可以确保在模块的作者发生变化时， 保持 port 继续可用。 以上规则有一个例外， 即对应目录不存在或源码包不在那个目录中时， 允许使用作者的 id 作为 MASTER_SITE_SUBDIR。 所有这些选项均同时接受 YES 和版本串， 类似 5.8.0+ 这样的写法。 使用 YES 表示 port 能够配合所有受支持的 Perl 版本来使用。 如果 port 只能配合特定版本的 Perl 来使用， 则可以用版本串来表示， 例如最低版本 (如 5.7.3+)、 最高版本 (如 5.8.0-) 或某个具体的版本 (如 5.8.3)。 用于用到 <literal>perl</literal> 的 port 的变量 变量 意义 USE_PERL5 表示 port 将 perl 5 用于联编和运行。 USE_PERL5_BUILD 表示 port 将 perl 5 用于联编。 USE_PERL5_RUN 表示 port 将 perl 5 用于运行。 PERL perl 5 的完整路径， 可能是系统自带的， 或者从 port 安装， 但没有版本号。 如果您需要在脚本中替换 #! 行， 则应使用这个变量。 PERL_CONFIGURE 采用 Perl 的 MakeMaker 进行配置。 这一变量隐含设置 USE_PERL5。 PERL_MODBUILD 使用 Module::Build 进行配置、 联编并安装。 这一变量隐含设置 PERL_CONFIGURE。 只读变量 意义 PERL_VERSION 系统中安装的 perl 的完整版本 (例如， 5.8.9)。 PERL_LEVEL 系统中安装的 perl 的版本整数值， 其形式为 MNNNPP (例如， 500809)。 PERL_ARCH perl 保存某平台专用的库的位置。 默认值为 ${ARCH}-freebsd。 PERL_PORT 系统中所安装的 perl port 的名字 (例如， perl5)。 SITE_PERL 站点专用的 perl package 安装路径。 其值会自动加入到 PLIST_SUB 中。
Perl 模块通常并没有官方网站， 这些 port 应将 cpan.org 作为其 pkg-descr WWW 行的内容。 推荐的 URL 格式为 http://search.cpan.org/dist/Module-Name/ (保留最后的斜线)。 使用 X11 X.Org 组件 在 Ports 套件中提供的 X11 实现是 X.Org。 如果您的应用程序用到了 X 组件， 则应将 USE_XORG 设为所需要的那些组件。 目前可用的组件包括： 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. 最新的列表， 可以在 /usr/ports/Mk/bsd.xorg.mk 中找到。 The Mesa Project 是一个致力于自由的 OpenGL 实现的计划。 您可以使用 USE_GL 变量来让 port 依赖其不同的组件。 可用的选项包括： glut, glu, glw, glew, gl 和 linux。 为了实现向前兼容， 当使用 yes 时系统会自动将其映射为 glu。 使用 USE_XORG 的例子 USE_XORG= xrender xft xkbfile xt xaw USE_GL= glu 许多 ports 会定义 USE_XLIB， 这会导致 port 依赖 50 多个动态连接库。 由于它出现于 X.org 模块化之前， 因此这个变量仅为向前兼容的原因提供， 新的 port 不应再使用它。 用到 X 的 port 可以使用的变量 USE_XLIB 此 port 用到了 X 库。 已过时 - 您应使用 USE_XORG 变量列出用到的 X.Org 组件， 而不是使用这个变量。 USE_IMAKE 此 port 用到了 imake。 USE_X_PREFIX 已过时。 目前其作用与 USE_XLIB 相同， 并可以直接用后者替换。 XMKMF 设置为 xmkmf 的完整路径名， 如果它不在 PATH 中的话。 默认值是 xmkmf -a。
用于表示对 X11 某些组件的依赖关系的变量 X_IMAKE_PORT 用以提供 imake 以及许多其它用于联编 X11 的工具的 port。 X_LIBRARIES_PORT 用以提供 X11 库的 port。 X_CLIENTS_PORT 用以提供 X 客户的 port。 X_SERVER_PORT 用以提供 X 服务的 port。 X_FONTSERVER_PORT 用以提供字体服务的 port。 X_PRINTSERVER_PORT 用以提供打印服务的 port。 X_VFBSERVER_PORT 用以提供在虚拟帧缓存服务(virtual framebuffer server) 的 port。 X_NESTSERVER_PORT 用以提供嵌套 X 服务的 port。 X_FONTS_ENCODINGS_PORT 用以为字体提供编码的 port。 X_FONTS_MISC_PORT 用以提供多种位图字体的 port。 X_FONTS_100DPI_PORT 用以提供 100dpi 位图字体的 port。 X_FONTS_75DPI_PORT 用以提供 75dpi 位图字体的 port。 X_FONTS_CYRILLIC_PORT 用以提供西里尔位图字体的 port。 X_FONTS_TTF_PORT 用以提供 &truetype; 字体的 port。 X_FONTS_TYPE1_PORT 用以提供 Type1 字体的 port。 X_MANUALS_PORT 用以提供面向开发人员的联机手册的 port。
在变量中使用与 X11 有关的变量 # 使用某些 X11 库并依赖字体服务和西里尔字体。 RUN_DEPENDS= ${LOCALBASE}/bin/xfs:${X_FONTSERVER_PORT} \ ${LOCALASE}/lib/X11/fonts/cyrillic/crox1c.pcf.gz:${X_FONTS_CYRILLIC_PORT} USE_XORG= x11 xpm 需要使用 Motif 的 port 如果您的 port 需要 Motif 库， 则应在 Makefile 中定义 USE_MOTIF。 默认的 Motif 实现是 x11-toolkits/open-motif。 用户可以通过设置 WANT_LESSTIF 变量来选择 x11-toolkits/lesstif 代替它。 bsd.port.mk 会将 MOTIFLIB 变量设置为到合适的 Motif 库的引用。 请使用补丁将您 port 中 Makefile 或 Imakefile 提到 Motif 库的地方改为 ${MOTIFLIB}。 有两种比较常见的情况： 如果 port 中将 Motif 在其 Makefile 或 Imakefile 表达为 -lXm， 则简单地将其替换为 ${MOTIFLIB}。 如果 port 在其 Imakefile 中使用 XmClientLibs， 则将其改为 ${MOTIFLIB} ${XTOOLLIB} ${XLIB}. 注意 MOTIFLIB (通常) 会展开为 -L/usr/X11R6/lib -lXm 或 /usr/X11R6/lib/libXm.a， 所以不需要在其前加入 -L 或 -l。 X11 字体 如果 port 将为 X Window 系统安装字体， 将这些字体放到 LOCALBASE/lib/X11/fonts/local。 通过 Xvfb 来获得虚拟的 <envar>DISPLAY</envar> 某些应用程序必须在有可用的 X11 显示的时候才能成功编译。 当编译的机器没有控制台时， 这会带来问题。 为了解决这个问题， 如果定义了适当的变量， 联编基础设施会启动采用虚拟帧缓存的 X server。 此时， 编译过程中将会传出可用的 DISPLAY。 USE_DISPLAY= yes 桌面项 通过利用 DESKTOP_ENTRIES 变量， 可以很容易地在您的 port 中创建桌面项 (Freedesktop 标准)。 这些项会在类似 GNOME 或 KDE 这样的符合这一标准的桌面环境中显示在应用程序菜单中。 这样做会自动创建、 安装 .desktop 文件， 并将其加入 pkg-plist。 其语法为： DESKTOP_ENTRIES= "NAME" "COMMENT" "ICON" "COMMAND" "CATEGORY" StartupNotify 您可以在 Freedesktop 网站上 找到可用的分类名称。 StartupNotify 表示应用程序在支持启动通知的环境中清除状态信息。 例子： DESKTOP_ENTRIES= "ToME" "Roguelike game based on JRR Tolkien's work" \ "${DATADIR}/xtra/graf/tome-128.png" \ "tome -v -g" "Application;Game;RolePlaying;" \ false 使用 GNOME FreeBSD/GNOME 项目组使用一组自己的变量来定义 port 所使用的 GNOME 组件。 这些变量的详细列表 可以在 FreeBSD/GNOME 项目的主页找到。 使用 Qt 在 port 中使用 Qt 用于使用 Qt 的 port 的变量 USE_QT_VER 表示 port 用到了 Qt 工具套件。 可用的值包括 3 和 4； 用于指定使用的 Qt 的主版本。 此外， 系统会自动为 configure 脚本和 make 命令提供必要的参数。 QT_PREFIX 这个变量会自动设为 Qt 的安装路径 (只读变量)。 MOC 这个变量会自动设为 moc 的路径 (只读变量)。 默认值与 USE_QT_VER 变量的值有关。 QTCPPFLAGS 通过 CONFIGURE_ENV 传给 Qt 工具套件的编译参数。 默认配置与 USE_QT_VER 有关。 QTCFGLIBS 通过 CONFIGURE_ENV 传给 Qt 工具套件的连接库。 默认配置与 USE_QT_VER 有关。 QTNONSTANDARD 禁止系统自动修改 CONFIGURE_ENV、 CONFIGURE_ARGS 和 MAKE_ENV。
其他用于使用 Qt 4.x 的变量 QT_COMPONENTS 用于指定 Qt4 工具和函数库的依赖。 详情见后。 UIC 这个变量会自动设为 uic 的路径 (只读变量)。 默认值与 USE_QT_VER 有关。 QMAKE 这个变量会自动设为 qmake 的路径 (只读变量)。 其默认值与 USE_QT_VER 有关。 QMAKESPEC 这个变量会自动设为 qmake 配置文件的路径 (只读变量)。 其默认值与 USE_QT_VER 有关。
当设置了 USE_QT_VER 时， 系统自动会给 configure 脚本传一系列有用的参数： 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}" 如果将 USE_QT_VER 设为 4， 则还会进行下列配置： CONFIGURE_ENV+= UIC="${UIC}" QMAKE="${QMAKE}" QMAKESPEC="${QMAKESPEC}" MAKE_ENV+= QMAKESPEC="${QMAKESPEC}" 组件的选择 (仅限 Qt 4.x) 当把 USE_QT_VER 设为 4 时， 就可以通过 QT_COMPONENTS 变量来指定对 Qt4 工具和函数库的依赖了。 通过在组件的名称后面添加 _build 或 _run 这样的后缀， 则可相应地将这依赖关系限于联编或运行时刻。 在没有指定后缀时， 系统默认在联编和运行时刻均依赖该组件。 通常情况下在指明函数库一类的组件时应不使用后缀， 联编工具类组件应使用 _build 后缀， 而插件类组件， 则应使用 _run 后缀。 下表中列出了一些最常用的组件 (全部可用的组件， 则在 /usr/ports/Mk/bsd.qt.mk 中的 _QT_COMPONENTS_ALL 列出)： 可用的 Qt4 函数库组件 名字 描述 corelib 核心库 (在 port 只使用 corelib 而没有用到其他库时可以省略) gui 图形用户界面库 network 网络函数库 opengl OpenGL 函数库 qt3support Qt3 兼容支持函数库 qtestlib 单元测试函数库 script 脚本函数库 sql SQL 函数库 xml XML 函数库
您可以通过在成功编译之后， 通过在主可执行文件上运行 ldd 来确定所需的库。 可用的 Qt4 工具组件 名字 描述 moc 元对象编译器 (几乎所有的 Qt 应用程序在联编过程中都需要它) qmake Makefile 生成器 / 联编工具 rcc 资源编译器 (如果应用程序中包含 *.rc 或 *.qrc 文件， 就需要它) uic 用户界面编译器 (如果应用程序中包含使用 Qt Designer 创建的 *.ui 文件时就需要它 - 一般说来 Qt 应用程序都会使用 GUI 的)
可用的 Qt4 插件组件 名字 描述 iconengines SVG 图标引擎插件 (如果应用程序使用 SVG 图标) imageformats 用于 GIF、 JPEG、 MNG 和 SVG 的 imageformat 插件 (如果应用程序使用图片文件)
选择 Qt4 组件 在这个例子中， 我们将要移植的应用程序用到了 Qt4 图形用户界面函数库、 Qt4 核心 (core) 函数库、 所有 Qt4 代码生成工具以及 Qt4 的 Makefile 生成器。 由于 gui 函数库会自动附带对核心函数库的依赖， 因此并不需要明确指出需要 corelib 的依赖关系。 Qt4 代码生成工具 moc、 uic 和 rcc 以及 Makefile 生成器 qmake 只在联编过程中才会用到， 因此可以指定 _build 后缀： USE_QT_VER= 4 QT_COMPONENTS= gui moc_build qmake_build rcc_build uic_build 其他考虑 如果应用程序没有提供 configure 文件， 而是给了一个 .pro 文件， 则应这样： HAS_CONFIGURE= yes do-configure: @cd ${WRKSRC} && ${SETENV} ${CONFIGURE_ENV} \ ${QMAKE} -unix PREFIX=${PREFIX} texmaker.pro 请注意， 这与系统提供的 BUILD.sh 中的 qmake 类似。 传递 CONFIGURE_ENV 能够确保 qmake 可以看到 QMAKESPEC 变量， 否则它可能无法正常工作。 qmake 会生成标准的 Makefile， 因此无需自行编写 build target。 Qt 应用程序通常会编写为能够跨平台使用， 通常 X11/Unix 并不是开发它的平台， 有时这会导致一些边边角角的问题， 例如： 缺少必要的 includepaths。 许多应用程序会使用托盘图标支持， 但忽略了这些头或库文件需要在 X11 目录中查找。 您可以通过命令行告诉 qmake 将这些头文件和函数库加入到搜索路径中， 例如： ${QMAKE} -unix PREFIX=${PREFIX} INCLUDEPATH+=${LOCALBASE}/include \ LIBS+=-L${LOCALBASE}/lib sillyapp.pro 有问题的安装路径。 有时， 类似图标或 .desktop 文件这样的一些数据， 默认情况下没有安装到 XDG-兼容的程序会扫描的路径中。 editors/texmaker 就是一个这样的例子 - 请参考这个 port 的 files 目录中的 patch-texmaker.pro， 以了解如何在 Qmake 工程文件中修正这个问题。 使用 KDE 变量定义 (只用于 KDE 3.x) 用于使用 KDE 3.x 的 port 的变量 USE_KDELIBS_VER 表示 port 用到了 KDE 库。 这个变量可以指定希望使用的 KDE 主版本号， 如果设置了这个变量， 则系统也会将 USE_QT_VER 设为适当的版本。 该变量目前唯一有效的值是 3。 USE_KDEBASE_VER 表示 port 用到了 KDE 的基本系统。 这个变量可以指定希望使用的 KDE 主版本号， 如果设置了这个变量， 则系统也会将 USE_QT_VER 设为适当的版本。 该变量目前唯一有效的值是 3。
用于 KDE 4 的变量定义 如果您的应用程序需要使用 KDE 4.x， 则应将 USE_KDE4 设为所需组件的列表。 下面列出一些最常用到的组件 (最新的组件列表位于 /usr/ports/Mk/bsd.kde4.mk 中的 _USE_KDE4_ALL)： 可用的 KDE4 组件 名称 说明 akonadi 个人信息管理 (PIM)存储服务 automoc4 令 port 使用 automoc4 联编工具集 kdebase 基本的 KDE 应用程序 (Konqueror、 Dolphin、 Konsole) kdeexp 试验性的 KDE 库 (包含尚未完全确定不变的 API) kdehier 常用的 KDE 目录层次结构 kdelibs 基本 KDE 库 kdeprefix 如果设置了这个选项， 则 port 将安装到 ${KDE4_PREFIX} 而不是 ${LOCALBASE} pimlibs PIM 函数库 workspace 用于组成桌面的应用程序和函数库 (Plasma、 KWin)
KDE 4.x port 会安装到 ${KDE4_PREFIX}， 目前是 /usr/local/kde4， 以避免与 KDE 3.x ports 冲突。 这是通过指定 kdeprefix 组件来实现的， 它表示替换默认的 PREFIX。 不过， port 仍会遵循通过 MAKEFLAGS 环境变量设置的 PREFIX 以及其它 make 参数。 KDE 4.x ports 有可能和 KDE 3.x ports 冲突， 因此如果启用了 kdeprefix 组件， 它们会安装到 ${KDE4_PREFIX}。 目前 KDE4_PREFIX 的默认值是 /usr/local/kde4。 也可以将 KDE 4.x ports 安装到自定义的 PREFIX。 当 PREFIX 是通过 MAKEFLAGS 环境变量， 或直接在 make 命令行指定时， 它会替换 kdeprefix 提供的配置。 <varname>USE_KDE4</varname> 示例 下面是一个简单的 KDE 4 port。 USE_CMAKE 指定 port 使用 CMake — 许多 KDE 4 项目所使用的配置工具。 USE_KDE4 则引入 KDE 函数库， 并令 port 在联编阶段使用 automoc4。 需要的 KDE 组件， 以及其他依赖的组件可以从 configure 的日志中获知。 USE_KDE4 并不会自动设置 USE_QT_VER。 如果 port 需要使用某些 Qt4 组件， 则需要设置 USE_QT_VER 并指定所需要的组件。 USE_CMAKE= yes USE_KDE4= automoc4 kdelibs kdeprefix USE_QT_VER= 4 QT_COMPONENTS= qmake_build moc_build rcc_build uic_build 使用 Java 变量定义 如果您的 port 需要 Java™ 开发包 (JDK™) 来完成联编、 支持运行， 甚至完成解开源代码包这样的工作， 就应该定义 USE_JAVA。 在 Ports Collection 中有许多不同的 JDK， 它们的版本各不相同， 或是来自不同的供应商。 如果您的 port 必须使用其中的某个特定的版本， 也可以予以定义。 最新的稳定版本是 java/jdk16。 用到 Java 的 port 可以使用的变量 变量 意义 USE_JAVA 只有定义它才能使其它变量生效。 JAVA_VERSION 用空格分开的适合 port 使用的 Java 版本。 可选的 "+" 可以用于指定某个范围的版本 (可以用： 1.5[+] 1.6[+] 1.7[+] )。 JAVA_OS 用空格分开的适应 port 的 JDK port 操作系统类型 (可以用： native linux)。 JAVA_VENDOR 用空格分开的适应 port 的 JDK port 供应商 (可以用： freebsd bsdjava sun openjdk)。 JAVA_BUILD 设置这个变量表示所选的 JDK port 应被列入 port 的联编依赖关系。 JAVA_RUN 设置这个变量表示所选的 JDK port 应被列入 port 的运行环境依赖关系。 JAVA_EXTRACT 设置这个变量表示所选的 JDK port 应被列入 port 的解压缩支持依赖关系。
下面是在设置了 USE_JAVA 之后， port 能够从系统中获得的配置： 向使用了 Java 的 port 提供的变量 变量 值 JAVA_PORT JDK port 的名字 (例如 'java/diablo-jdk16')。 JAVA_PORT_VERSION JDK port 的完整版本 (例如 '1.6.0')。 如果您只需要版本号的前两位， 则可用 ${JAVA_PORT_VERSION:C/^([0-9])\.([0-9])(.*)$/\1.\2/}。 JAVA_PORT_OS 所用 JDK port 的操作系统 (例如 'native')。 JAVA_PORT_VENDOR 所用 JDK port 的供应商 (例如 'freebsd')。 JAVA_PORT_OS_DESCRIPTION 所用 JDK port 操作系统的描述 (例如 'Native')。 JAVA_PORT_VENDOR_DESCRIPTION 所用 JDK port 供应商的描述 (例如 'FreeBSD Foundation')。 JAVA_HOME JDK 的安装目录 (例如 '/usr/local/diablo-jdk1.6.0')。 JAVAC 所用 Java 编译器的完整路径 (例如 '/usr/local/diablo-jdk1.6.0/bin/javac')。 JAR 所用 jar 工具的完整路径 (例如 '/usr/local/diablo-jdk1.6.0/bin/jar' 或 '/usr/local/bin/fastjar')。 APPLETVIEWER 所用 appletviewer 工具的完整路径 (例如 '/usr/local/diablo-jdk1.6.0/bin/appletviewer')。 JAVA 所用 java 执行文件的完整路径。 您应使用它来执行 Java 程序 (例如 '/usr/local/diablo-jdk1.6.0/bin/java')。 JAVADOC 所用 javadoc 工具的完整路径。 JAVAH 所用 javah 程序的完整路径。 JAVAP 所用 javap 程序的完整路径。 JAVA_KEYTOOL 所用 keytool 工具的完整路径。 JAVA_N2A 所用 native2ascii 工具的完整路径。 JAVA_POLICYTOOL 所用 policytool 程序的完整路径。 JAVA_SERIALVER 所用 serialver 程序的完整路径。 RMIC 所用 RMI 桩/架 生成器， rmic 的完整路径。 RMIREGISTRY 所用 RMI 注册表程序， rmiregistry 的完整路径。 RMID 所用 RMI 服务程序 rmid 的完整路径。 JAVA_CLASSES 所用 JDK 类文件目录的完整路径。 ${JAVA_HOME}/jre/lib/rt.jar。
您可以使用 java-debug make target 以获取用于调试 port 的信息。 大多数前述变量的值皆会予以呈现。 此外， 还会定义下述常量， 以确保所有的 Java port 均以一致之方式安装： 为使用 Java 的 port 定义的常量 常量 值 JAVASHAREDIR 所有 Java 相关资料的安装根目录。 默认值： ${PREFIX}/share/java. JAVAJARDIR 用以安装 JAR 文件的目录。 默认值： ${JAVASHAREDIR}/classes。 JAVALIBDIR 其它 port 安装的 JAR 文件所在的目录。 默认值： ${LOCALBASE}/share/java/classes。
相关的项也会定义在 PLIST_SUB (在 中进行介绍) 和 SUB_LIST 中。 采用 Ant 进行联编 如果 port 采用 Apache Ant 进行联编， 则需要定义 USE_ANT。 如是， 则 Ant 将作为 子-make 命令来使用。 如果 port 未定义 do-build target， 则将默认依 MAKE_ENV、 MAKE_ARGS 和 ALL_TARGET。 的设置执行 Ant。 这类似于 中介绍的关于 USE_GMAKE 的机制。 最佳实践 如果您正移植某个 Java 库， 您的 port 应把 JAR 文件安装到 ${JAVAJARDIR}， 而其它文件则应放在 ${JAVASHAREDIR}/${PORTNAME} 下 (除了文档， 参见下文)。 要减少打包文件的尺寸， 您可以直接在 Makefile 中引用这些 JAR 文件， 具体做法是使用下面的语句 (此处的 myport.jar 是作为 port 一部分安装的 JAR 文件的名字)： PLIST_FILES+= %%JAVAJARDIR%%/myport.jar 移植 Java 应用程序时， port 通常会希望将所有文件安装到同一目录 (包括其依赖的 JAR)。 这时强烈建议使用 ${JAVASHAREDIR}/${PORTNAME}。 移植软件的开发人员， 可以自行决定是否将所依赖的其它 JAR 安装到此目录， 或直接使用已经装好的那些 (来自 ${JAVAJARDIR})。 无论您正制作哪一类的 port (库或者应用程序)， 附加的文档都应安装到和其它 port 同样的位置。 已经知道， JavaDoc 会根据 JDK 版本的不同而产生不同的文件。 对于那些不打算强制使用某一特定版本 JDK 的 port 而言， 这无疑提高了制作装箱单 (pkg-plist) 的难度。 这是为什么强烈建议使用 PORTDOCS 宏的原因。 更进一步， 即使您能够预测 javadoc 将要生成的文件， 所需的 pkg-plist 的尺寸， 也是鼓吹使用 PORTDOCS 的一大理由。 DATADIR 的默认值是 ${PREFIX}/share/${PORTNAME}。 对 Java port 而言将 DATADIR 改为 ${JAVASHAREDIR}/${PORTNAME} 是一个好主意。 当然， DATADIR 会自动加到 PLIST_SUB 中 (在 有所介绍) 因此您可以在 pkg-plist 中直接使用 %%DATADIR%%。 撰写本文时， 对是应该从源代码联编， 还是直接安装预编译的 Java ports 安装包并没有明确的规定。 尽管如此， &os; Java Project 的开发人员仍鼓励移植软件的开发者在不麻烦的情况下尽可能从源代码完成联编。 本节中所介绍的全部特性， 均是在 bsd.java.mk 中实现的。 如果您感觉自己的 port 需要更为复杂的 Java 支持， 请首先参阅 bsd.java.mk CVS 日志， 因为通常撰文介绍最新特性需要一些时间。 此外， 如果您认为所缺少的支持对许多其它 Java port 亦属有益， 请在 &a.java; 对其进行讨论。 在 PR 中的 java 类别， 主要是用于 &os; Java project 移植 JDK 本身之用。 因而， 提交您的 Java port 时， 应归入 ports 类别， 除非您正尝试解决的问题是 JDK 实现本身或 bsd.java.mk 的。 类似地， 您应参考 中所详述的关于 CATEGORIES 在 Java port 中的使用规则。 Web 应用， Apache 和 PHP Apache 用到 Apache 的 port 可以使用的变量 USE_APACHE 此 port 需要 Apache。 可用的值： yes (任意可用版本)、 1.3、 2.0、 2.2、 2.0+、 等等。 默认依赖的版本是 1.3。 WITH_APACHE2 此 port 需要 Apache 2.0。 如果没有这个变量， 则 port 将依赖 Apache 1.3。 这一变量目前已经过时， 因而不应继续使用。 APXS 到 apxs 可执行文件的完整路径。 您可以在 port 中替代该值。 HTTPD 到 httpd 可执行文件的完整路径。 您可以在 port 中替代该值。 APACHE_VERSION 目前系统中安装的 Apache 版本 (只读变量)。 这一变量只有在引用了 bsd.port.pre.mk 之后才能使用， 其可能的值为： 13、 20、 22。 APACHEMODDIR Apache 模块所在的文件夹。 在 pkg-plist 中， 这一变量会自动展开。 APACHEINCLUDEDIR Apache 头文件所在的文件夹。 在 pkg-plist 中， 这一变量会自动展开。 APACHEETCDIR Apache 配置文件所在的文件夹。 在 pkg-plist 中， 这一变量会自动展开。
在移植 Apache 模块时比较有用的变量 MODULENAME 模块的名称。 默认值为 PORTNAME。 例如： mod_hello SHORTMODNAME 模块的简略名字。 默认情况下会自动根据 MODULENAME 计算， 但您也可以自行设置值来替代它。 例如： hello AP_FAST_BUILD 使用 apxs 来编译和安装模块。 AP_GENPLIST 同时自动创建 pkg-plist。 AP_INC 在编译过程中， 将指定的目录加入到搜索头文件的目录中。 AP_LIB 在编译过程中， 将指定的目录加入到搜索函数库的目录中。 AP_EXTRAS 传递给 apxs 的额外参数。
Web 应用 Web 应用程序应安装到 PREFIX/www/应用程序的名字。 为方便起见， 这个路径在 Makefile 和 pkg-plist 均以 WWWDIR 变量的形式提供。 在 Makefile 中可以使用 WWWDIR_REL 来表示包含了 PREFIX 的该变量值。 web 服务器进程所用的用户和用户组， 分别以 WWWOWN 和 WWWGRP 变量的形式提供， 如果您需要修改某些文件的属主的话。 这两个变量的默认值均为 www。 如果您的 port 希望使用其他值， 请使用 WWWOWN?= myuser 这种写法， 以便让用户能够更容易地修改它。 除非您的 port 必需使用 Apache， 否则不要将其写入依赖关系。 请尊重运行您的应用程序的用户选择 Apache 以外的其他 web 服务器的需求。 PHP 用到 PHP 的 port 中可以使用的变量 USE_PHP 此 port 需要 PHP。 取值为 yes 将把 PHP 加入依赖关系。 此外， 还可以在此指定将所需要的 PHP 扩展模块。 例如： pcre xml gettext DEFAULT_PHP_VER 选择在没有安装 PHP 时自动安装的 PHP 主版本。 默认是 4。 可选 4、 5 之一。 IGNORE_WITH_PHP 此 port 无法与给定版本的 PHP 一同工作。 可选值为 4、 5 之一。 USE_PHPIZE 此 port 将作为 PHP 扩展模块进行联编。 USE_PHPEXT 此 port 将作为 PHP 扩展， 且需要作为扩展模块注册。 USE_PHP_BUILD 联编依赖于 PHP。 WANT_PHP_CLI 希望使用 CLI (命令行) 版本的 PHP。 WANT_PHP_CGI 希望使用 CGI 版本的 PHP。 WANT_PHP_MOD 希望使用 Apache 模块版本的 PHP。 WANT_PHP_SCR 希望使用 CLI 或 CGI 版本的 PHP。 WANT_PHP_WEB 希望使用 Apache 模块或 CGI 版本的 PHP。
PEAR 模块 移植 PEAR 模块的过程非常简单。 使用 FILES、 TESTS、 DATA、 SQLS、 SCRIPTFILES、 DOCS 以及 EXAMPLES 这些变量来指明您希望安装的文件。 所有这里列出的文件都会自动安装到合适的位置， 并加入 pkg-plist。 在 Makefile 文件的最后一行引入 ${PORTSDIR}/devel/pear/bsd.pear.mk。 用于 PEAR 类的 Makefile 例子 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> 使用 Python Ports 套件支持同时并行安装多个不同的 Python 版本。 Ports 应确保能够根据用户配置的 PYTHON_VERSION 变量使用正确的 python 解释器。 一般说来， 这是通过将脚本中的 python 路径名替换为 PYTHON_CMD 变量的值来实现的。 在 PYTHON_SITELIBDIR 下安装文件的 ports 应在包名上使用 pyXY- 前缀， 以便明示它们将会配合哪个 Python 版本使用。 PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX} 对用到 Python 的 port 最有用的一些变量 USE_PYTHON 此 port 需要 Python。 可以用 2.3+ 这样的形式来指定所希望的版本。 除此之外， 也可以用横线来分隔两个版本号， 以表示某个范围的版本， 例如： 2.1-2.3 USE_PYDISTUTILS 使用 Python distutils 来完成配置、 编译和安装。 对包含 setup.py 的 port 而言这是必需的。 它会自动覆盖默认的 do-build 以及 do-install 这两个 target。 如未定义 GNU_CONFIGURE， 它还会改变 do-configure。 PYTHON_PKGNAMEPREFIX 作为 PKGNAMEPREFIX 来区分不同 Python 版本的 package。 例如： py24- PYTHON_SITELIBDIR 全站 package 所在的目录， 它包括了 Python 的安装目录 (通常是 LOCALBASE)。 在安装 Python 模块时， PYTHON_SITELIBDIR 变量会非常有用。 PYTHONPREFIX_SITELIBDIR 去掉了 PREFIX 部分的 PYTHON_SITELIBDIR。 应尽可能在 pkg-plist 中使用 %%PYTHON_SITELIBDIR%%。 %%PYTHON_SITELIBDIR%% 的默认值是 lib/python%%PYTHON_VERSION%%/site-packages PYTHON_CMD Python 解释器的命令行， 包括版本号。 PYNUMERIC 将数值处理扩展模块加入依赖关系。 PYNUMPY 对新增的数值计算扩展, numpy的依赖。 (PYNUMERIC 目前已被作者淘汰)。 PYXML 将 XML 扩展模块加入依赖关系。 (对于 Python 2.0 和更高版本不再需要， 因为它已经成为了标准组件)。 USE_TWISTED 将 twistedCore 加入依赖关系。 也可以用这个变量指定所需的组件， 例如： web lore pair flow USE_ZOPE 加入对 Zope， 一种 web 应用平台的依赖。 这会把 Python 依赖改为 Python 2.3。 此外 ZOPEBASEDIR 也会自动设为 Zope 安装目录的位置。
完整的可用变量列表， 可以在 /usr/ports/Mk/bsd.python.mk 中找到。 使用 <application>Tcl/Tk</application> Ports 套件支持同时安装多个 Tcl/Tk 版本。 Ports 应至少支持默认的 Tcl/Tk 版本， 以及通过 USE_TCL 和 USE_TK 变量指定的更高版本。 希望使用的 tcl 版本， 则可以通过 WITH_TCL_VER 变量来使用。 用到 <application>Tcl/Tk</application> 的 port 可以使用的变量 USE_TCL 表示 port 依赖于 Tcl 函数库 (不是 shell)。 可以指定需要的最低版本， 例如 84+。 不支持的版本， 可以在 INVALID_TCL_VER 变量中逐个指定。 USE_TCL_BUILD 表示 port 在联编过程中需要使用 Tcl。 USE_TCL_WRAPPER 需要使用 Tcl shell 而不需要特定版本的 tclsh 的 port 可以使用这个新变量。 系统中会安装 tclsh wrapper， 用户则可以指定所希望的 tcl shell。 WITH_TCL_VER 由用户定义的、 希望使用的 Tcl 版本。 UNIQUENAME_WITH_TCL_VER 和 WITH_TCL_VER 类似， 但是针对 port 指定的。 USE_TCL_THREADS 需要包含线程支持的 Tcl/Tk。 USE_TK 表示 port 依赖于 Tk 库 (不是 wish shell)。 它同时会隐含将 USE_TCL 设置为相同的值。 更多的描述， 请参考 USE_TCL 变量。 USE_TK_BUILD 与 USE_TCL_BUILD 变量表达类似的含义。 USE_TK_WRAPPER 与 USE_TCL_WRAPPER 变量表达类似的含义。 WITH_TK_VER 表达与 WITH_TCL_VER 变量类似的含义， 它同时会隐含将 WITH_TCL_VER 设置为相同的值。
可用的变量的完整列表， 可以在 /usr/ports/Mk/bsd.tcl.mk 中找到。 使用 Emacs 本节尚有待撰写。 使用 Ruby 使用 Ruby 的 port 可以使用的变量 变量 说明 USE_RUBY 此 port 需要 Ruby。 USE_RUBY_EXTCONF 此 port 使用 extconf.rb 来完成配置。 USE_RUBY_SETUP 此 port 使用 setup.rb 来完成配置。 RUBY_SETUP 将此变量名设置为所用的 setup.rb 的文件名。 通常会是 install.rb。
下表展示了 ports 系统提供给 port 作者的一些变量。 您应使用这些变量， 以便把文件装到合适的位置。 请尽可能多地在 pkg-plist 中使用它们。 这些变量不应在 port 中重新定义。 使用 Ruby 的 port 中的一些可用的只读变量 变量 说明 示范值 RUBY_PKGNAMEPREFIX 作为 PKGNAMEPREFIX 以区分用于不同 Ruby 版本的 package。 ruby18- RUBY_VERSION x.y.z 形式的完整 ruby 版本。 1.8.2 RUBY_SITELIBDIR 平台无关库的安装路径。 /usr/local/lib/ruby/site_ruby/1.8 RUBY_SITEARCHLIBDIR 平台相关的库的安装路径。 /usr/local/lib/ruby/site_ruby/1.8/amd64-freebsd6 RUBY_MODDOCDIR 模块文档的安装路径。 /usr/local/share/doc/ruby18/patsy RUBY_MODEXAMPLESDIR 模块用例的安装路径。 /usr/local/share/examples/ruby18/patsy
可用变量的完整列表， 可以在 /usr/ports/Mk/bsd.ruby.mk 中找到。 使用 SDL 变量 USE_SDL 可以用于自动配置 port 的依赖关系， 以适应使用类似 devel/sdl12 和 x11-toolkits/sdl_gui 这些依赖 SDL 的库的情形。 目前系统能够识别下列 SDL 库： 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 因此， 如果 port 需要依赖 net/sdl_net 和 audio/sdl_mixer， 则对应的写法将是： USE_SDL= net mixer 同时， net/sdl_net 和 audio/sdl_mixer 所依赖的 devel/sdl12 也会被自动地加入。 加入您使用 USE_SDL， 它将自动地： 将对于 sdl12-config 的依赖关系加入到 BUILD_DEPENDS 将变量 SDL_CONFIG 加入到 CONFIGURE_ENV 将对所选的库的依赖， 加入到 LIB_DEPENDS 要检查某个特定的 SDL 库是否可用， 可以通过 WANT_SDL 变量来达到目的： WANT_SDL=yes .include <bsd.port.pre.mk> .if ${HAVE_SDL:Mmixer}!="" USE_SDL+= mixer .endif .include <bsd.port.post.mk> 使用 <application>wxWidgets</application> 这一节介绍了在 ports tree 中的 wxWidgets 库的现状， 以及它与 ports 系统的集成。 介绍 许多不同版本的 wxWidgets 库之间是存在相互冲突的 (它们会安装同名的文件) 在 ports 系统中， 这一问题是通过将不同的版本以包含版本号后缀的名字安装来解决的。 这样做的一个最明显的缺点是， 应用程序必须进行修改， 才能找到所希望的版本。 幸运的是， 多数应用程序会调用 wx-config 脚本来确定需要的编译器和连接器选项。 这个脚本会随可用的版本不同而有不同的名字。 主要的应用程序都会尊重环境变量的配置， 或提供一个 configure 参数， 用以指定调用哪个 wx-config。 如果不是这样的话， 就需要对应用程序打补丁了。 版本的选择 为了让您的 port 使用指定版本的 wxWidgets， 可以定义两个变量 (如果只定义了一个， 则另一个会取默认值)： 用于选择 <application>wxWidgets</application> 版本的变量 变量 说明 默认值 USE_WX 列出这个 port 能使用的版本 全部版本 USE_WX_NOT 列出这个 port 不能使用的版本 无
下面是可用的 wxWidgets 版本， 以及对应的 ports： 可用的 <application>wxWidgets</application> versions 版本 Port 2.4 x11-toolkits/wxgtk24 2.6 x11-toolkits/wxgtk26 2.8 x11-toolkits/wxgtk28
从 2.5 版开始， 也提供了对应的 Unicode 版本， 这种版本可以通过 slave port 安装， 与普通版本相比， 它会多一个 -unicode 后缀， 不过这可以通过使用变量来处理 (请参见 )。 在 中的变量， 可以设为下列值或由空格分隔的组合： <application>wxWidgets</application> 版本 说明 例子 单个版本 2.4 某版本以上版本 2.4+ 某版本以下版本 2.6- 某段版本 (版本号较小的必须在前) 2.4-2.6
除此之外， 还有一些用以从可用的本那本中选择所希望的版本的变量。 这种变量也可以设为一组版本， 而靠前的版本的优先级更高。 用于选择希望的版本的 <application>wxWidgets</application> versions 变量名 用于 WANT_WX_VER port WITH_WX_VER 用户
选择组件 也有一些其他应用， 尽管它们本身并不是 wxWidgets 库， 但却与之相关。 这些应用程序可以在 WX_COMPS 变量中使用， 以下是可用的组件： 可用的 <application>wxWidgets</application> 组件 名称 说明 版本限制 wx 主库 无 contrib 第三方库 无 python wxPython (Python 绑定) 2.4-2.6 mozilla wxMozilla 2.4 svg wxSVG 2.6
您可以为每个依赖的组件， 通过冒号分隔的后缀指定其类型。 如果没有指定， 则会使用默认的依赖类型 (参见 )。 下面是可用的类型： 可用的 <application>wxWidgets</application> 依赖类型 名称 说明 build 联编时需要该组件， 相当于 BUILD_DEPENDS run 运行时需要该组件， 相当于 RUN_DEPENDS lib 联编和运行时均需要该组件， 相当于 LIB_DEPENDS
组件的默认依赖关系类型， 如下表所示： 默认的 <application>wxWidgets</application> 依赖关系类型 组件 依赖关系类型 wx lib contrib lib python run mozilla lib svg lib
选择 <application>wxWidgets</application> 组件 下面的片段展示了使用 wxWidgets 版本 2.4 及第三方库的方法。 USE_WX= 2.4 WX_COMPS= wx contrib Unicode wxWidgets 库从其 2.5 版开始支持 Unicode 了。 在 ports 系统中， 这两种版本均有提供， 并可以通过下列变量来选择： 用以在 Unicode 版本的 <application>wxWidgets</application> 的变量 变量 说明 作用 WX_UNICODE 该 port 只能 配合 Unicode 版本使用 port WANT_UNICODE port 能够与两种版本配合使用， 但希望使用 Unicode 版本 port WITH_UNICODE 令 port 使用 Unicode 版本 用户 WITHOUT_UNICODE 令 port 使用普通版本， 如果支持的话 (即未定义 WX_UNICODE) 用户
如果 port 同时支持 Unicode 和普通版本， 请不要使用 WX_UNICODE。 如果希望默认启用 Unicode， 应定义 WANT_UNICODE。 检测已安装的版本 要检测系统中安装的版本， 就需要定义 WANT_WX。 如果没有将其设置为特定的版本， 则组件将包含版本后缀。 HAVE_WX 变量在检测完成后会自动填入内容。 检测已安装的 <application>wxWidgets</application> 版本和组件 下面的片段可以在安装 wxWidgets 的系统中令 port 使用它， 反之则作为一项选项提供。 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 下面的片段在系统中有安装过时启用 wxPython 支持， 或在没有安装时作为选项提供； 对 wxWidgets 也是如此办理， 版本皆为 2.6。 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 定义的变量 以下是一些可以在 port 中使用的变量 (这之前需要定义 中的至少一个变量)。 为使用 <application>wxWidgets</application> 的 port 定义的变量 变量名 说明 WX_CONFIG 到 wxWidgets wx-config 脚本的路径 (名字会随版本不同而不同) WXRC_CMD 到 wxWidgets wxrc 程序的路径 (名字会随版本不同而不同) WX_VERSION 将要用到的 wxWidgets 版本 (例如， 2.6) WX_UNICODE 如果没有定义， 而将会使用 Unicode 时， 系统将自动定义此变量。
在 <filename>bsd.port.pre.mk</filename> 中进行处理 如果您需要在引用了 bsd.port.pre.mk 之后立即对一些变量进行处理， 则需要定义 WX_PREMK。 如果定义了 WX_PREMK， 则在此 之后 定义的依赖关系、 组件和变量将不会生效， 您在引用 bsd.port.pre.mk 之前的 wxWidgets port 变量将直接起作用。 在命令中使用 <application>wxWidgets</application> 变量 下面的片段以执行 wx-config 脚本来得到完整的版本号， 将其赋值到变量中， 并传递给一个程序举例说明了 WX_PREMK 的用法。 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 在 target 中的 wxWidgets 变量可以直接使用， 而无需 WX_PREMK 的参与。 额外的 <command>configure</command> 参数 某些 GNU configure 脚本在只设置了 WX_CONFIG 环境变量时， 无法自动找到 wxWidgets， 而需要使用额外的参数来加以指定。 您可以使用 WX_CONF_ARGS 变量来给出这些参数。 可用于 <varname>WX_CONF_ARGS</varname> 的值 可用值 结果 absolute --with-wx-config=${WX_CONFIG} relative --with-wx=${LOCALBASE} --with-wx-config=${WX_CONFIG:T}
使用 <application>Lua</application> 这一节描述了在 ports 系统中的 Lua 库的现状， 以及它与 ports 系统的集成。 介绍 许多不同版本的 Lua 库和相关的解释器之间是相互冲突的 (它们会安装同名的文件)。 在 ports 系统中， 这一问题是通过将不同版本的文件以不同的版本号作为后缀名解决的。 这样做最大的一个问题是， 每个程序都需要进行修改才能找到它所需要的版本。 不过， 通过将适当的参数传给编译器和连接器很容易解决这个问题。 选择版本 要让您的 port 使用指定版本的 Lua， 可以定义两个变量的值 (如果只定义了其中的一个， 则另一个会使用默认值)： 用于选择 <application>Lua</application> 版本的变量 变量 说明 默认值 USE_LUA port 能够使用的 Lua 版本列表 全部可用版本 USE_LUA_NOT 与 port 不兼容的版本列表 无
下面是目前 ports 系统提供的可用 Lua 版本和对应的目录： 可用的 <application>Lua</application> 版本 版本 Port 4.0 lang/lua4 5.0 lang/lua50 5.1 lang/lua
在 中的变量， 可以设置为下面的版本之一， 或用空格分隔的若干版本： 指定 <application>Lua</application> 版本 说明 例子 一个版本 4.0 某个版本或更高版本 5.0+ 不高于某个版本 5.0- 版本范围 (低版本必须在前) 5.0-5.1
除此之外， 也有一些用来从可用版本中选择推荐版本的其它变量。 这些变量也可以设置为一组版本， 而前面的版本优先级较高。 用于选择推荐 <application>Lua</application> 版本的变量 变量名 用于 WANT_LUA_VER port WITH_LUA_VER 用户
选择 <application>Lua</application> 版本 下面是一个用到 Lua 版本 5.0 或 5.1， 并默认使用 5.0 的 port 的片段。 这个默认值可以通过 WITH_LUA_VER 来另外指定。 USE_LUA= 5.0-5.1 WANT_LUA_VER= 5.0 组件的选择 也有一些其它的应用， 尽管本身并不是 Lua 库， 但却与它们相关。 这些应用可以通过 LUA_COMPS 变量来指定。 可用的组件如下： 可用的 <application>Lua</application> 组件 名字 说明 版本限制 lua 主库 无 tolua 用于访问 C/C++ 代码的库 4.0-5.0 ruby Ruby 绑定 4.0-5.0
还有一些其它的组件， 但这些组件是由解释器， 而不是由应用程序使用的 (也就是不被其它模块使用)。 每个组件的依赖关系类型可以通过手工添加分隔符为冒号的后缀来指定。 如果不指定， 则会采用默认类型 (请参见 )。 以下是可用的依赖关系类型： 可用的 <application>Lua</application> 依赖关系类型 名字 说明 build 这个组件是联编过程所必需的， 相当于 BUILD_DEPENDS run 在运行时需要这个组件， 相当于 RUN_DEPENDS lib 这个组件在联编和运行时都需要， 相当于 LIB_DEPENDS
组件的默认依赖关系类型如下： 默认的 <application>Lua</application> 依赖关系类型 组件 依赖关系类型 lua 对于 4.0-5.0 是 lib (动态连接) 而对于 5.1 则是 build (静态连接) tolua build (静态连接) ruby lib (动态连接)
选择 <application>Lua</application> 组件 下面是一个使用了 Lua 版本 4.0 及其 Ruby 绑定的 port 片段。 USE_LUA= 4.0 LUA_COMPS= lua ruby 检测系统中已安装的版本 要检测系统中已安装的版本， 您必须定义 WANT_LUA。 如果没有将其设定为具体的版本， 则组件会包含版本后缀。 在检测之后， HAVE_LUA 变量将设为检测到的版本。 检测已安装的 <application>Lua</application> 版本和组件 下面是一个如果系统中有安装 Lua 或选择了选项时使用它的 port 片段。 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 下面的这段 port 在系统中已经有安装， 或用户选择了 tolua 和 Lua 支持时加以安装， 版本均选择 4.0。 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 定义的变量 在 port 中可以使用下列变量 (在定义了 中至少一个变量之后)。 为用到 <application>Lua</application> 的 port 定义的变量 变量名 说明 LUA_VER 将要使用的 Lua 版本。 (例如， 5.1) LUA_VER_SH Lua 动态连接库的主版本 (例如， 1) LUA_VER_STR 不带点的 Lua 版本 (例如， 51) LUA_PREFIX 安装 Lua (及其组件) 使用的后缀 LUA_SUBDIR 在 ${PREFIX}/bin、 ${PREFIX}/share 和 ${PREFIX}/lib 中用于安装 Lua 的子目录 LUA_INCDIR 用以安装 Lua 和 tolua 头文件的目录 LUA_LIBDIR 用以安装 Lua 和 tolua 库文件的目录 LUA_MODLIBDIR 用以安装 Lua 模块动态连接库 (.so) 的目录 LUA_MODSHAREDIR 用以安装 Lua 模块 (.lua) 的目录 LUA_PKGNAMEPREFIX Lua 模块包的后缀名 LUA_CMD 到 Lua 解释器的路径 LUAC_CMD 到 Lua 编译器的路径 TOLUA_CMD 到 tolua 程序的路径
告诉 port 到什么地方去找 <application>Lua</application> 下面的 port 片段展示了如何告诉使用的 configure 脚本去什么地方查找 Lua 的头文件和库文件。 USE_LUA= 4.0 GNU_CONFIGURE= yes CONFIGURE_ENV= CPPFLAGS="-I${LUA_INCDIR}" LDFLAGS="-L${LUA_LIBDIR}" 在 <filename>bsd.port.pre.mk</filename> 时进行处理 如果您需要在使用引用 bsd.port.pre.mk 之后就得到变量， 以便将其用于执行一些命令， 需要定义 LUA_PREMK。 如果您定义了 LUA_PREMK， 则在您引用 bsd.port.pre.mk 之后， 即使修改了 Lua port 变量， 版本和依赖关系也都不会随之发生变化了。 在命令中使用 <application>Lua</application> 变量 下面的片段展示了如何利用 LUA_PREMK， 并运行 Lua 解释器得到完整的版本串， 将其赋值给一个变量， 并传递给程序。 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 在 target 中的 Lua 变量可以在命令中安全的使用， 而无需使用 LUA_PREMK。 使用 Xfce USE_XFCE 变量可以用来自动配置使用基于 Xfce 库或应用程序， 如 x11-toolkits/libxfce4gui 和 x11-wm/xfce4-panel 的 port 的依赖关系。 目前， 系统能够识别下列 Xfce 库和应用程序： 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 除此之外， 还能够使用下列参数： configenv： 如果您的 port 需要使用特殊的 CONFIGURE_ENV 来查找所需的库。 -I${LOCALBASE}/include -L${LOCALBASE}/lib 会加到 CONFIGURE_ENV 的 CPPFLAGS。 因此， 如果 port 有到 sysutils/xfce4-mcs-manager 的依赖关系， 并需要在 configure 的环境中指定特殊的饿 CPPFLAGS， 则所用的语法为： USE_XFCE= mcsmanager configenv 使用 Mozilla 用到 Mozilla 的 port 使用的变量 USE_GECKO port 支持的 Gecko 后端。 可选值： libxul (libxul.so)、 seamonkey (libgtkembedmoz.so， 过时， 新 port 应避免使用)。 USE_FIREFOX port 需要使用 Firefox 作为运行环境依赖。 可选值： yes (使用默认版本)、 40、 36、 35。 默认的依赖采用的是版本 40。 USE_FIREFOX_BUILD port 需要使用 Firefox 作为联编环境依赖。 可选值： 参见 USE_FIREFOX。 这个变量会自动设置 USE_FIREFOX 使用相同的值。 USE_SEAMONKEY port 需要使用 SeaMonkey 作为运行环境依赖。 可选值： yes (使用默认版本)、 20、 11 (过时， 新 port 应避免使用)。 默认的依赖采用的是版本 20。 USE_SEAMONKEY_BUILD port 需要使用 SeaMonkey 作为联编环境依赖。 可选值： 参见 USE_SEAMONKEY。 这个变量会自动设置 USE_SEAMONKEY 使用相同的值。 USE_THUNDERBIRD port 需要使用 Thunderbird 作为运行环境依赖。 可选值： yes (使用默认版本)、 31、 30 (过时， 新 port 应避免使用)。 默认的依赖采用的是版本 31。 USE_THUNDERBIRD_BUILD port 需要使用 Thunderbird 作为联编环境依赖。 可选值： 参见 USE_THUNDERBIRD。 这个变量会自动设置 USE_THUNDERBIRD 使用相同的值。
可用变量的完整列表， 请参阅 /usr/ports/Mk/bsd.gecko.mk。 使用数据库 ports 中有关数据库的变量 Variable Means USE_BDB 如果这个变量为 yes， 则把 databases/db41 列为依赖关系。 这个变量还可以被设置成的值有： 40，41， 42、 43、 44、 46、 47、 48 或 51。 您可以声明可接受值的范围， USE_BDB=42+ 将寻找已安装的最高版本， 如果没有找到则退回到 42。 USE_MYSQL 如果这个变量为 yes， 则把 databases/mysql55-server 列为依赖关系。还有一个相关的变量，WANT_MYSQL_VER, 可以设置的值有 323，40，41，50，51， 52， 55 或者 60。 USE_PGSQL 如果设置成 yes，则把 databases/postgresql82 列为依赖关系。还有一个相关的变量，WANT_PGSQL_VER， 可以设置的值有 73，74，80，81，82， 83 或 90。
更多详情请参阅 bsd.database.mk。 启动和停止服务 (rc 脚本) rc.d 脚本在系统启动时用于启动服务， 并为管理员提供停止、 启动和重新启动某个服务的标准方法。 Ports 安装的脚本会集成到系统的 rc.d 框架中。 关于如何使用它的说明， 可以在 使用手册的 rc.d 章节 找到。 关于可用命令的详细解释， 则可以在 &man.rc.8; 和 &man.rc.subr.8; 找到。 最后， 您可以参阅 这篇文章 了解撰写 rc.d 脚本的最佳实践。 可以安装一或多个 rc.d 脚本： USE_RC_SUBR= doormand 这些脚本必须放到 files 目录， 并附加 .in。 这个文件中可以使用标准的 SUB_LIST 替换展开。 除此之外， 我们还强烈推荐使用 %%PREFIX%% 和 %%LOCALBASE%% 替换展开。 关于 SUB_LIST 的介绍可以在 本书的相关章节 找到。 在 &os; 6.1-RELEASE 之前， 与 &man.rcorder.8; 的集成是通过 USE_RCORDER 而不是 USE_RC_SUBR 来完成的。 不过， 除非 port 需要提供安装进基本系统这样的选项， 或者服务需要在 rc.d 脚本 FILESYSTEMS 之前运行这类特殊情况， 一般来说是不需要使用这个功能的。 从 &os; 6.1-RELEASE 开始， 本地安装的 rc.d 脚本 (包括由 port 安装的脚本) 会纳入基本系统的 &man.rcorder.8;。 以下是一个简单的 rc.d 脚本： #!/bin/sh # $FreeBSD$ # # PROVIDE: doormand # REQUIRE: LOGIN # KEYWORD: shutdown # # 在 /etc/rc.conf.local 或 /etc/rc.conf 中增加下述设置可以启用这一服务： # # doormand_enable (bool): 默认设为 NO。 # 设为 YES 可以启用 doormand。 # doormand_config (path): 默认设为 %%PREFIX%%/etc/doormand/doormand.cf。 # . /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" 除非有很站得住脚的理由提前启动服务，所有的 ports 脚本应使用 REQUIRE: LOGIN。 如果服务需要以特定用户 (除 root 之外) 身份启动， 则必须这样做。 在前面的例子中， 我们还使用了 KEYWORD: shutdown 以便让 mythical port 在系统停机的过程中以正常的方式终止， 因为它需要在系统引导过程中启动服务。 如果脚本没有启动任何服务， 则并不需要这样做。 这里， 对变量的默认赋值方法应采用 "="， 而非 ":=" 这样的形式。 这是因为， 前一种赋值方法只有在变量未被设置时才设置默认值， 而后一种方法则会在变量没有设置， 或者 其值为空时都设置默认值。 用户非常可能在其 rc.conf.local 中使用类似 doormand_flags="" 这样的设置， 而采用 ":=" 来进行赋值， 则会在不经意间覆盖用户所希望的设置。 新增的脚本均不应使用 .sh 后缀。 未来， 仍然包含这一后缀的脚本将被批量改名。 卸载时停止服务 可以在卸载的过程中自动地停止服务。 我们建议只有在绝对必要， 例如必须在删除文件之前停止服务这类的情况下才使用这一功能。 通常来说， 决定是否在卸载时停止服务是系统管理员需要考虑的事情。 另外要注意， 这个功能也会影响升级过程。 需要时可以在 pkg-plist 中加入： @stopdaemon doormand 这里的参数必须与 USE_RC_SUBR 变量的内容匹配。 添加用户和用户组 一些 port 需要在安装的系统中创建特定的用户或用户组。 如果有这种情况， 请从 50 到 999 之间选择一个尚未使用的 UID， 并在 ports/UIDs (针对用户) 或 ports/GIDs (针对组) 中予以记录。 请务必确保您没有使用系统中已经在其他 ports 中使用的 UID。 如果您的 port 需要创建新用户或用户组， 请在提交补丁的时候一并提交这两个文件的补丁。 接下来， 可以在您的 Makefile 中使用 USERS 和 GROUPS 这两个变量， 系统会在安装时自动创建用户或组。 USERS= pulse GROUPS= pulse pulse-access pulse-rt 现有的保留 UID 和 GID 列表， 可以在 ports/UIDs 和 ports/GIDs 找到。 依赖内核源代码的 Ports 某些 ports (例如可加载式内核模块) 需要内核的源文件才能编译。 下面是检测用户是否安装了源代码的例子： .if !exists(${SRC_BASE}/sys/Makefile) IGNORE= requires kernel sources to be installed .endif 高级 <filename>pkg-plist</filename> 用法 根据 make 变量对 <filename>pkg-plist</filename> 进行修改 某些 port， 特别是 p5- port， 会需要根据配置选项 (或对于 p5- port 而言， perl 的版本) 来修改它们的 pkg-plist。 为简化这一工作， 在 pkg-plist 中的 %%OSREL%%、 %%PERL_VER%%， 以及 %%PERL_VERSION%% 将自动进行相应的替换。 其中， %%OSREL%% 的值是操作系统以数值表示的版本 (例如 4.9)。 %%PERL_VERSION%% 和 %%PERL_VER%% 是 perl 的完整版本号 (例如 5.8.9)。许多其它与 port 文档文件有关的 %%变量%% 在 相应章节 中进行了介绍。 如果您还需要进行其它的替换， 可以通过将 PLIST_SUB 变量设置为一组 变量=值 对来实现。 其中， %%VAR%% 表示在 pkg-plist 中将被 值 替换的那些文字。 举例来说， 如果 port 需要把很多文件放到和版本有关的目录中， 可以在 Makefile 中按照类似下面的例子： OCTAVE_VERSION= 2.0.13 PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION} 并在 pkg-plist 中将具体的版本替换为 %%OCTAVE_VERSION%%。 这样， 在升级 port 时， 就不需要再到 pkg-plist 中修改那几十 (或者， 有时甚至是上百) 行的内容了。 如果您的 port 需要根据一定的配置来有条件地安装一些文件， 通常的做法是在 pkg-plist 中列出这些文件时， 在对应行的开头加上 %%TAG%%， 并将 TAG 写到 Makefile 中的 PLIST_SUB 变量中， 根据需要替换掉， 或替换为 @comment， 后者表示让打包工具忽略这行： .if defined(WITH_X11) PLIST_SUB+= X11="" .else PLIST_SUB+= X11="@comment " .endif 与之对应， 在 pkg-plist 中： %%X11%%bin/foo-gui 这一替换过程 (以及加入 联机手册 的过程)， 会在 pre-install 和 do-install 两个 target 之间， 通过读取 PLIST 并写入 TMPPLIST (默认情况下， 是： WRKDIR/.PLIST.mktmp) 来完成。 因此， 如果您的 port 动态生成 PLIST， 就需要在 pre-install 之前完成。 另外， 如果您的 port 需要编辑所生成的文件， 则需要在 post-install 中操作名为 TMPPLIST 的那个文件。 另一种可行的修改装箱单的方法， 则是根据 PLIST_FILES 和 PLIST_DIRS 这两个变量的设置来进行。 它们的值会作为目录名连同 PLIST 的内容一起写入 TMPPLIST。 在 PLIST_FILES 和 PLIST_DIRS 中列出的名字， 会经历前面所介绍的 %%变量%% 替换过程。 除此之外， 在 PLIST_FILES 中列出的文件， 会不加任何修改第出现在最终的装箱单中， 而 @dirrm 将作为前缀加到 PLIST_DIRS 所列的名字之前。 为了达到目的， PLIST_FILES 和 PLIST_DIRS 必须在写 TMPPLIST 之前， 也就是在 pre-install 或更早的阶段进行设置。 空目录 清理空目录 一定要让 port 在卸载时进行清理空目录。 通常， 可以通过为所有由 port 创建的目录增加对应的 @dirrm 行来实现。 在删除父目录之前， 需要首先删除它的子目录。 : 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 然而， 有时 @dirrm 会由于其它 port 使用了同一个目录而发生错误。 利用 @dirrmtry 可以只删除那些空目录， 而避免给出警告。 @dirrmtry share/doc/gimp 按照上面的写法， 将不会显示任何错误信息， 而且，即使在 ${PREFIX}/share/doc/gimp 由于其它 port 在其中安装了一些别的文件的时候， 也不会导致 &man.pkg.delete.1; 异常退出。 如何建立空目录 在 port 安装过程中创建的空目录需要特别留意。 安装 package 时并不会自动创建这些目录， 这是因为 package 只保存文件。 要确保安装 package 时会自动创建这些空目录， 需要在 pkg-plist 中加入与 @dirrm 对应的行： @exec mkdir -p %D/share/foo/templates 配置文件 如果 port 需要把一些文件放到 PREFIX/etc， 不要 简单地安装它们， 并将其列入 pkg-plist， 因为这样会导致 &man.pkg.delete.1; 删除用户精心编辑的文件， 而新安装时则又会把这些文件覆盖。 因此， 您应把配置文件的例子按其它的后缀来安装 (例如 filename.sample 就是一个不错的选择) 并显示一条 消息 告诉用户如何复制并编辑这个配置文件， 以便让软件能够正确工作。 因此， 应按其它的后缀来安装配置文件的例子 (filename.sample 就是一个不错的选择)。 如果实际的配置文件不存在， 则将其复制为实际文件的名字。 卸载时， 如果发现用户没有修改配置文件， 则将其删除。 您需要在 port 的 Makefile， 以及 pkg-plist (对于从 package 安装的情形) 进行处理。 示例的 Makefile 部分： post-install: @if [ ! -f ${PREFIX}/etc/orbit.conf ]; then \ ${CP} -p ${PREFIX}/etc/orbit.conf.sample ${PREFIX}/etc/orbit.conf ; \ fi 示例的 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 另外， 还应显示一条 消息 指出用户应在何处复制并编辑这个文件， 以便让软件能开始正常工作。 动态装箱单与静态装箱单的对比 静态装箱单 是指在 Ports Collection 中以 pkg-plist 文件 (可能包含变量替换)， 或以 PLIST_FILES 和 PLIST_DIRS 的形式嵌入到 Makefile 出现的装箱单。 即使它是由工具或 Makefile 中的某个 target 在经由 committer 加入到 Ports Collection 之前 自动生成的也是如此， 因为可以在不下载或编译源代码包的前提下对其进行检视。 动态装箱单 是指在 port 编译并安装时生成的装箱单。 在下载并编译您所移植的应用程序的源代码之前， 或在执行了 make clean 之后， 就无法查看其内容了。 尽管使用动态装箱单并不被禁止， 但监护人应尽可能使用静态装箱单， 因为它能够让用户使用 &man.grep.1;来发现所需的 ports， 例如， 它是否会安装某个特定文件。 动态列表主要应用于复杂的， 其装箱单随所选功能会发生巨变 (因而使得维护静态装箱单不再可行)， 或那些随版本而改变装箱单内容的 port (例如， 使用 Javadoc 来生成文档的那些 ports)。 我们鼓励那些选择使用动态装箱单的监护人提供一个能够生成 pkg-plist 的 target， 以便于用户检视其内容。 装箱单 (package list) 的自动化制作 首先， 请确认已经基本上完成了 port 的工作， 仅缺 pkg-plist。 接下来， 建立一个用于安装您的 port 的临时目录， 并在其中安装它所依赖的所有其他软件包： &prompt.root; mkdir /var/tmp/`make -V PORTNAME` &prompt.root; mtree -U -f `make -V MTREE_FILE` -d -e -p /var/tmp/`make -V PORTNAME` &prompt.root; make depends PREFIX=/var/tmp/`make -V PORTNAME` 将目录结构保存到一新文件中。 &prompt.root; (cd /var/tmp/`make -V PORTNAME` && find -d * -type d) | sort > OLD-DIRS 建立一空白 pkg-plist 文件： &prompt.root; :>pkg-plist 如果您的 port 遵循 PREFIX (应该如此) 则接下来应安装该 port 并创建装箱单。 &prompt.root; make install PREFIX=/var/tmp/`make -V PORTNAME` &prompt.root; (cd /var/tmp/`make -V PORTNAME` && find -d * \! -type d) | sort > pkg-plist 此外还应把新建立的目录加入装箱单。 &prompt.root; (cd /var/tmp/`make -V PORTNAME` && find -d * -type d) | sort | comm -13 OLD-DIRS - | sort -r | sed -e 's#^#@dirrm #' >> pkg-plist 最后需要手工整理 packing list； 这一过程不是 完全 自动的。 联机手册应列入 port 的 Makefile 中的 MANn， 而不是装箱单。 用户配置文件应被删除， 或以 filename.sample 这样的名字来安装。 info/dir 文件， 也不应列入， 同时应按照 info 文件 的说明来增加一些 install-info 行。 所有由 port 安装的库， 应按照 动态连接库 小节中介绍的方法处理。 另外， 也可以使用 /usr/ports/Tools/scripts/ 中的 plist 脚本来自动创建 package list。 plist 脚本是一个 Ruby 脚本， 它能够将前面介绍的手工操作自动化。 开始的步骤和上面的前三行一样， 也就是 mkdir， mtree 并 make depends。 然后联编和安装 port： &prompt.root; make install PREFIX=/var/tmp/`make -V PORTNAME` 然后让 plist 生成 pkg-plist 文件： &prompt.root; /usr/ports/Tools/scripts/plist -Md -m `make -V MTREE_FILE` /var/tmp/`make -V PORTNAME` > pkg-plist 与前面类似， 如此生成的装箱单也需要手工进行一些清理工作。 另一个可以用来创建最初的 pkg-plist 的工具是 ports-mgmt/genplist。 和其他自动化工具类似， 您应对它生成的 pkg-plist 应手工检查并根据需要进行修改。 <filename>pkg-*</filename> 文件 前面有一些没有提及的关于 pkg-* 文件的技巧， 它们可以方便地完成许多任务。 <filename>pkg-message</filename> (安装预编译包时显示的消息文件) 如果您需要在安装时显示一条消息给用户， 可以把这消息放在 pkg-message 中。 这一特性通常可以用于在 &man.pkg.add.1; 之后显示一些附加的安装步骤， 或显示关于授权的信息。 当需要显示一些编译开关或警告时， 请使用 ECHO_MSG。 pkg-message 文件只是为显示安装后的执行操作指导使用的。 类似地， 还需要留意 ECHO_MSG 和 ECHO_CMD 之间的区别。 前一个是在屏幕上显示消息性的文字， 而后一个则用于在执行命令时使用管道。 下面是用到了这两个宏的例子 shells/bash2/Makefile： 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 pkg-message 文件， 并不需要明确地加到 pkg-plist 中。 此外， 在用户使用 port 而不是 package 来安装软件时， 它并不会被显示出来。 因此如果需要的话， 您应该在 post-install target 中指定显示它。 <filename>pkg-install</filename> (安装预编译包时执行的脚本文件) 如果您的 port 需要在预编译的安装包通过 &man.pkg.add.1; 安装时执行一些命令， 则应通过 pkg-install 脚本来完成。 这个脚本会自动地加入 package， 并被 &man.pkg.add.1; 执行两次： 第一次是 ${SH} pkg-install ${PKGNAME} PRE-INSTALL 而第二次是 ${SH} pkg-install ${PKGNAME} POST-INSTALL。 $2 可被用来检测脚本运行的模式。 环境变量 PKG_PREFIX 将设置为 package 的安装目录。 请参见 &man.pkg.add.1; 以了解更进一步的细节。 在使用 make install 时这个脚本不会被自动运行。 如果需要运行它， 则必须在您的 port 中的 Makefile 里明确地予以调用， 其方法是加入类似 PKG_PREFIX=${PREFIX} ${SH} ${PKGINSTALL} ${PKGNAME} PRE-INSTALL 这样的命令。 <filename>pkg-deinstall</filename> (卸载时执行的脚本文件) 这一脚本将在 package 被卸载时执行。 此脚本会被 &man.pkg.delete.1; 执行两次。 第一次是 ${SH} pkg-deinstall ${PKGNAME} DEINSTALL 而第二次则是 ${SH} pkg-deinstall ${PKGNAME} POST-DEINSTALL。 <filename>pkg-req</filename> (安装预编译包时检测是否应执行操作的脚本文件) 如果您的 port 需要确定它是否应被安装， 可以创建 pkg-req requirements 脚本。 它会在安装/卸载时自动运行， 以决定操作是否应被实施。 这个脚本会在使用 &man.pkg.add.1; 安装时以 pkg-req ${PKGNAME} INSTALL 的命令行执行。 卸载时， 它将由 &man.pkg.delete.1; 以 pkg-req ${PKGNAME} DEINSTALL 的命令行执行。 改变 <filename>pkg-*</filename> 文件的名字 所有 pkg-* 文件的名字， 皆系采用变量予以定义， 因此在需要时可以在您的 Makefile 中加以改变。 当您需要在多个 port 之间共享某些 pkg-* 文件， 或需要写入某些文件时就非常有用了。 (参见 在 WRKDIR 以外的地方写文件， 以了解为什么直接将变更写入 pkg-* 子目录是个糟糕的主意) 下面是一组变量以及它们的默认值 (PKGDIR 默认情况下是 ${MASTERDIR}。) 变量 默认值 DESCR ${PKGDIR}/pkg-descr PLIST ${PKGDIR}/pkg-plist PKGINSTALL ${PKGDIR}/pkg-install PKGDEINSTALL ${PKGDIR}/pkg-deinstall PKGREQ ${PKGDIR}/pkg-req PKGMESSAGE ${PKGDIR}/pkg-message 请修改这些变量， 而不是直接覆盖 PKG_ARGS 的值。 如果您改变了 PKG_ARGS， 这些文件将无法在安装 port 时正确地复制到 /var/db/pkg 目录。 使用 <varname>SUB_FILES</varname> 和 <varname>SUB_LIST</varname> SUB_FILES 和 SUB_LIST 这两个变量可以用来在 port 文件中使用某些动态的值， 例如 pkg-message 中的 installation PREFIX。 用 SUB_FILES 变量， 可以指定需要自动进行修改的文件列表。 在 SUB_FILES 中的每一个 文件， 在 FILESDIR 目录中都必须有一个对应的 文件.in。 修改后的版本将保存在 WRKDIR。 在 USE_RC_SUBR (或已经过时的 USE_RCORDER) 中定义的文件会自动加入到 SUB_FILES 中。 对于 pkg-message、 pkg-install、 pkg-deinstall and pkg-req， 对应的 Makefile 变量会被自动设置， 以指向处理过的版本。 SUB_LIST 这个变量的内容是一系列 VAR=VALUE 对。 SUB_FILES 所列出的文件中所有的 %%VAR%% 都将被替换为 VALUE。 系统自动定义了一些常用的替换对， 包括： PREFIX、 LOCALBASE、 DATADIR、 DOCSDIR， 以及 EXAMPLESDIR。 替换结果中所有以 @comment 开头的行， 都将在变量替换之后被删去。 下面的例子中， 将把 pkg-message 中的 %%ARCH%% 替换为系统所运行的架构名称： SUB_FILES= pkg-message SUB_LIST= ARCH=${ARCH} 注意， 在上述例子中， FILESDIR 里必须有 pkg-message.in 这个文件。 下面是一个正确的 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. 测试您的 port 运行 <command>make describe</command> 许多 &os; port 维护工具， 例如 &man.portupgrade.1;， 会依赖于一个名为 /usr/ports/INDEX 的数据库的正确性， 它提供了关于 port 的相关信息， 例如依赖关系等等。 INDEX 是由顶级的 ports/Makefile 通过 make index 来建立的， 这个命令会进入每一个 port 的子目录， 并在那里执行 make describe。 因此， 如果某个 port 的 make describe 失败， 就没有人能生成 INDEX， 人们很快会变得不高兴。 无论在 make.conf 中设置了什么选项， 这个文件都应能够正确地生成。 因此， 应避免在 (例如) 某个依赖关系无法满足时使用 .error。 (参见 。) 如果 make describe 只是产生一个字符串， 而不是错误信息， 可能就没什么问题。 请参见 bsd.port.mk 以了解所生成的串的意义。 最后要说明的是， 新版本的 portlint (在下一节中将进行介绍) 将会自动地运行 make describe。 Portlint 在提交或 commit 之前， 应使用 portlint 来进行检查。 portlint 会对常见的、 包括功能上的和格式上的错误给出警告。 对于新的 (或在 repocopy 代码库中复制的) port， portlint -A 可以完成全面检查； 对于暨存的 port， portlint -C 一般就足够了。 由于 portlint 采用启发式方法来检查错误， 有时它会产生误警。 另外， 有时由于 port 框架的限制可能没有办法修正它指出的问题。 如果您有疑虑， 请写信询问 &a.ports;。 使用 Port Tools 来完成测试 在 Ports 套件中， 提供了一个 ports-mgmt/porttools 程序。 port 是一个能够帮助您简化测试工具的前端脚本。 如果希望对新增的 port 或更新 port 时进行测试， 可以用 port test 来完成这些测试工作， 这也包含了 portlint 检查。 这个命令会检测并列出没有在 pkg-plist 中列出的文件。 具体用法请参见下面的例子： &prompt.root; port test /usr/ports/net/csup <varname>PREFIX</varname> (安装时的顶级目录名) 和 <varname>DESTDIR</varname> PREFIX 能够决定 port 安装时的目的位置。 一般情况下这个位置是 /usr/local 或 /opt， 但也可以设为其它的任意值。 您的 port 则必须遵循这个变量。 除此之外， 如果用户配置了 DESTDIR， 则表示希望将 port 安装到另一个环境， 通常是 jail 或在 / 以外的其他位置挂接的系统中。 实际上， port 会安装到 DESTDIR/PREFIX， 并注册到位于 DESTDIR/var/db/pkg 的预编译包数据库中。 由于 DESTDIR 是由 ports 框架藉由 &man.chroot.8; 来实现的， 您在撰写符合 DESTDIR 规范的 ports 时并不需要什么额外的工作。 一般而言 PREFIX 会设为 LOCALBASE_REL (默认是 /usr/local)。 如果设置了 USE_LINUX_PREFIX， 则 PREFIX 会设为 LINUXBASE_REL (默认是 /compat/linux)。 避免将 /usr/local 或 /usr/X11R6 硬编码到源代码中， 能够大大提高 port 的灵活性， 并适应不同环境的需要。 对于使用 imake 的 X port， 这一工作是自动完成的； 其他情况下， 通常可以简单地将 port 所用到的 Makefile 脚本中出现的 /usr/local (或对于没有使用 imake 的 X port 而言， /usr/X11R6) 替换为读取 ${PREFIX} 变量就能达到目的了， 因为这个变量在联编和安装的过程中， 会自动向下传递。 一定要避免让您的 port 在 /usr/local 而不是正确的 PREFIX 中安装文件。 简单的测试方法是： &prompt.root; make clean; make package PREFIX=/var/tmp/`make -V PORTNAME` 如果有文件安装到了 PREFIX 以外的地方， 打包过程将抱怨找不到这些文件。 这一步骤并不能帮助发现内部引用， 或纠正在引用其它 port 中的文件时使用的 LOCALBASE。 您需要在 /var/tmp/`make -V PORTNAME` 中测试安装好的软件， 才能够达到这样的目的。 您可以在自己的 Makefile 中改变 PREFIX 变量的值， 也可以通过用户环境变量来影响它。 然而， 一般情况下决不应该在 Makefile 中明确设置它的值。 此外， 引用其它 port 中的文件时， 应使用前面介绍的变量， 而不要直接指定它们的路径名。 例如， 如果您的 port 需要使用 PAGER 这个宏来指明 less 的完整路径， 应使用下面的编译选项： -DPAGER=\"${LOCALBASE}/bin/less\" 而非 -DPAGER=\"/usr/local/bin/less\"。 这种方法能够增加在系统管理员把整个 /usr/local 目录挪到其它位置时安装成功的机会。 Tinderbox 如果您是非常热心的 ports 参与者， 则可以看看 Tinderbox。 这是一个强大的用于联编和测试 ports 的系统， 它基于 Pointyhat 的脚本。 您可以使用 ports-mgmt/tinderbox port 来安装 Tinderbox。 请一定仔细阅读随它安装的文档， 因为配置并不简单。 请访问 Tinderbox 网站 以了解进一步的细节。 升级一个 port 如果您发现某个 port 相对原作者所发布的版本已经过时， 则首先需要确认的是您的 port 是最新的。 您可以在 &os; FTP 镜像的 ports/ports-current 目录中找到它们。 但是， 如果您正在使用较多的 port， 则可能使用 CVSup 来保持 Ports Collection 最新更为简单， 这在 使用手册 中进行了介绍。 此外， 这样做也有助于保持 port 依赖关系的正确性。 下一步是检查是否已经有在等待的更新。 要完成这项工作， 可以采用下列两种方法之一。 有一个用于搜索 FreeBSD 问题报告 (PR) 数据库 (也被称作 GNATS)。 在下拉框中选择 ports， 然后输入 port 的名字。 但是， 有些时候人们会忘记将避免混淆的 port 的名字放到 Synopsis 字段中。 这种时候， 您可以试试看 FreeBSD Ports 监视系统 (也被叫做 portsmon)。 这个系统会尝试按照 port 的名字来进行分类。 要搜索和某个特定 port 有关的 PR， 可以使用 port概览。 如果没有候审的 PR， 下一步是给 port 的维护者写信， 这可以通过执行 make maintainer 看到。 这个人可能正在进行升级工作， 或者由于某种理由暂时没有升级 (例如， 新版本有稳定性问题)； 一般您不希望重复他们的工作。 注意没有维护者的 port 的维护者会显示为 ports@FreeBSD.org， 这是一般性 port 问题的邮件列表， 因此发邮件给它一般没什么意义。 如果维护者要求您去完成升级， 或者没有维护者， 您就有机会通过自行完成升级来帮助 &os; 了！ 请使用基本系统提供的 &man.diff.1; 命令来完成相关的工作。 如果只修改一个文件， 可以直接使用 diff 来生成补丁， 将需要修改的文件复制成 something.orig， 并将改动放进 something， 接着生成补丁： &prompt.user; /usr/bin/diff something.orig something > something.diff 如果不是这样的话， 则您应使用 cvs diff 的方法 ()， 或将目录整个复制到另一个目录， 并使用 &man.diff.1; 比较两个目录时在目录中递归产生的输出结果 (例如， 如果您修改后的 port 目录的名字是 superedit 而原始文件的目录是 superedit.bak， 则应保存 diff -ruN superedit.bak superedit 的结果)。 一致式 (unified) 或 上下文式 (context) diff 都是可以的， 但一般来说 port committer 会更喜欢一致式 diff。 请注意这里使用的选项 -N， 它的目的是强制 diff 正确地处理出现新文件， 或老文件被删除的情形。 在把 diff 发给我们之前， 请再次检查输出， 以便确认每一个修改都是有意义的。 (特别注意， 在对比目录之前要用 make clean 清理一下)。 为了简化常用的补丁文件操作， 您可以使用 /usr/ports/Tools/scripts/patchtool.py。 使用之前， 请首先阅读 /usr/ports/Tools/scripts/README.patchtool。 如果 port 目前还无人维护， 而且您自己经常使用它， 请考虑自荐为它的维护者。 &os; 有超过 4000 个没有维护者的 port， 而这正是最需要志愿人员的领域。 (要了解关于维护者的任务描述， 请参见 开发手册中的相关部分。) 将 diff 发送给我们的最佳方式是通过 &man.send-pr.1; (category 一栏写 ports)。 如果您正维护那个 port， 请务必在 synopsis 的开头写上 [maintainer update]， 并将您的 PR 的 Class 设置为 maintainer-update。 反之， 您的 PR 的 Class 就应该是 change-request。 请在信中逐个提及每一个删除或增加的文件， 因为这些都必须明确地在使用 &man.cvs.1; 进行 commit 时明确地指定。 如果 diff 超过了 20K， 请考虑压缩并对其进行 uuencode； 否则， 简单地将其原样加入 PR 即可。 在您 &man.send-pr.1; 之前， 请再次阅读 Problem Reports 一文中的 如何撰写问题报告 小节； 它给出了丰富的关于如何撰写更好的问题报告的介绍。 如果您的更新是由于安全考虑， 或修复已经 commit 的 port 中的严重问题， 请通知 &a.portmgr; 来申请立即重建和分发您的 port 的 package。 否则， 不愿怀疑的使用 &man.pkg.add.1; 的用户， 可能会在未来数周之内继续通过使用 pkg_add -r 安装旧版本。 再次强调， 请使用 &man.diff.1; 而非 &man.shar.1; 来发送现有 port 的更新！ 这可以帮助 ports committer 理解需要修改的内容。 现在您已经了解了所需的所有操作， 您可能会像要阅读在 中关于如何保持最新的描述。 使用 CVS 制作补丁 如果可能的话， 请提交&man.cvs.1; diff； 这种情形要比直接比较 新、旧 目录要容易处理。 此外， 这种方法也让您更容易看出到底改了什么， 并在其他人更新了 Ports Collection 时容易合并这些改动， 在提交之前， 这可以减少维护补丁所需的工作。 &prompt.user; cd ~/my_wrkdir &prompt.user; cvs -d R_CVSROOT co pdnsd &prompt.user; cd ~/my_wrkdir/pdnsd 当然， 这可以是您指定的任意目录； 联编 port 并不局限于 /usr/ports/ 的子目录。 R_CVSROOT 是任何一个公共的 cvs 镜像服务器， 您可以在 &os; 使用手册 中挑选一个。 pdnsd 是 port 的模块名字； 通常说来它和 port 的名字一样， 不过也有些例外， 特别是那些本地化类别 (german/selfhtml 对应的模块名字是 de-selfhtml)； 您可以通过 cvsweb 界面 查询， 或者也可以指定完整路径， 例如在我们这个例子中是 ports/dns/pdnsd。 在工作目录中， 您可以像往常一样进行任何更改。 如果您添加或删除了文件， 则需要告诉 cvs 来追踪这些改动： &prompt.user; cvs add new_file &prompt.user; cvs remove deleted_file 请反复检查 列出的事项并使用 进行检查。 &prompt.user; cvs status &prompt.user; cvs update 这会合并 CVS 中其他人做的改动和您的补丁； 在这个过程中， 您需要仔细观察输出。 文件名前面的那个字母会显示做了什么， 请参阅 中给出的说明。 cvs update 文件名前字母前缀的含义 U 文件更新无误。 P 文件更新无误 (通常只有在使用远程代码库时才会看到)。 M 文件有本地修改， 并合并成功而未产生任何冲突。 C 文件有本地修改， 进行了合并并产生了冲突。
如果您在执行 cvs update 时某些文件出现了 C， 则说明有其他人在 CVS 中做了修改， 而 &man.cvs.1; 无法将这些改动与您本地的改动进行合并。 不过， 无论如何， 最好都检查一下合并的结果， 因为 cvs 并不知道 port 应该是什么样子， 因此它所做的合并无论是否产生了冲突， 都有可能 (并且并不罕见) 产生没有意义的结果。 最后一步是以 CVS 中的文件为基础生成 unified &man.diff.1;： &prompt.user; cvs diff -uN > ../`basename ${PWD}`.diff 指定 十分重要， 因为它确保了添加或删除的文件也出现在补丁中。 补丁将包含删除的文件， 在打上补丁时， 这些文件会被清空， 所以最好在 PR 中提醒 committer 删除它们。 根据 的指导提交您的补丁。 UPDATING 和 MOVED 文件 如果在升级 port 时需要类似修改配置文件或运行特定的程序这样的特别步骤， 则应在 /usr/ports/UPDATING 文件中予以说明。 这个文件中的项目格式如下： YYYYMMDD: AFFECTS: users of port类别/port名字 AUTHOR: 您的名字 <您的电子邮件地址> 所需执行的特别步骤 如果您需要在内文中加入具体的 portmaster 或 portupgrade 的说明， 请确保所用的 shell 命令使用了正确的转义字符。 如果 port 被删除或改名，则应在 /usr/ports/MOVED 中添加相应的说明项目。 这个文件中的项目格式如下： 原来的名字|新名字 (如果删除则应留空)|删除或改名的日期|原因 Ports 的安全 安全为何如此重要 软件中偶尔会引入 bug。 毋庸置疑， 安全漏洞是最为危险的。 从技术角度看， 这些漏洞可以通过消除导致它们的 bug 来修复。 然而， 处理一般的 bug 和安全漏洞的策略是截然不同的。 典型的小 bug 通常只影响那些启用了某些能够触发它的选项组合的用户。 开发人员最终会在发布没有那个问题的新版之后给出一个补丁来修正它， 而用户中的主体并不会立即升级， 因为他们并没有因存在问题而感到苦恼。 严重的 bug 可能会导致数据丢失和其它问题， 无论如何， 谨慎的用户知道， 除了软件 bug 之外还有很多其它事故可能会导致数据丢失， 因此他们会备份重要数据； 此外， 严重的 bug 通常会被很快发现。 安全漏洞则完全不同。 第一， 它们可能存在数年而不被发现， 因为它们可能并不导致软件无法正常工作。 第二， 通过利用漏洞， 恶意的一方可能会得到未获授权的访问权限， 并利用这些权限毁掉或修改敏感数据； 而更糟糕的情况则是用户可能根本注意不到损害已经发生。 第三， 暴露出安全漏洞的系统， 往往能够帮助攻击者闯入其它之前不可能进入的系统。 因此， 只是修正安全漏洞是不够的： 必须以清晰和全面的方式通知公众， 这样他们就能够评估风险， 并采取适当的措施。 修复安全漏洞 当说起 port 或 package 时， 安全漏洞往往是出现在原作者的发行包， 或移植过程中加入的文件里。 对于前一种情况， 软件的原作者通常会立刻发布一个补丁甚至新版， 您只需要按照原作者的修正去更新 port 就可以了。 如果由于某种原因修正被延误， 则要么 将 port 标记为 FORBIDDEN， 要么在 port 中加入一个自己的补丁。 如果有存在漏洞的 port， 尽可能尽快修复其漏洞就是。 无论是哪种情况， 您还是需要按照 标准的提交流程 提交， 除非您有直接在 ports tree 上 commit 的权限。 作为 ports committer 并不能够随便 commit 所有 port。 请注意通常 port 都有维护者， 而他们应得到您的尊重。 在漏洞被修正之后， 一定要同时增加 port 的修订版本号。 这样， 规律性地升级安装的 package 的用户就能够看到他们需要进行升级。 另外， 还应联编预编译的安装包， 并通过 FTP 和 WWW 镜像发布， 以取代有漏洞的版本。 注意要增加 PORTREVISION 数字， 除非在修正问题时 PORTVERSION 发生了变化。 一般来说， 如果在 port 中增加了补丁文件， 就应该增加 PORTREVISION， 但例外的例子是您已经将软件升级到了最新版， 因为这时已经改掉 PORTVERSION 了。 请参见 相关小节 以了解进一步的信息。 通知整个用户群体 VuXML 数据库 当发现了安全漏洞时的一项重要而紧迫的步骤， 就是让使用 port 的用户群了解其危险。 这类通知有两重目的。 首先， 如果危害真的很严重， 可能理性的办法就是立即应用一项缓解措施， 例如， 停止受到影响的服务， 甚至完全删除 port， 直到问题被修正为止。 其次， 许多用户只是偶尔升级所安装的软件包， 通过通知， 他们能够知道已经到了 必须 更新软件的时候， 因为已经有了修正这些问题的版本了。 由于现有的 port 数量极其庞大， 为每一个问题都发布安全公告， 毫无疑问地会发表和狼来了一样多的安全公告， 并增大受众在真的发生严重的问题时忽略问题的可能。 因此， 在 port 中发现的安全漏洞， 会在 FreeBSD VuXML 数据库 中记录。 安全官团队成员会持续地追踪这个数据库的修改， 以了解需要他们注意的内容。 如果您是 committer， 则可以自行更新 VuXML 数据库。 这样， 您就能够同时帮助安全官团队， 并尽早将至关重要的信息传达给用户群体。 然而， 如果您不是 committer， 或者您相信自己发现了一个异常严重的漏洞， 请不要犹豫， 按照 FreeBSD 安全信息 页面上的方法联系安全官团队。 正如其名称所暗示的那样， VuXML 数据库是一个 XML 文档。 其源文件 vuln.xml 被保存在 security/vuxml port 的目录中。 所以， 它的全名是 PORTSDIR/security/vuxml/vuln.xml。 每当您发现 port 中的安全漏洞时， 请把新的纪录加入到那个文件中。 在熟悉 VuXML 之前， 您最好先看看是否有类似的您发现的问题的其它记录， 并复制它作为模板。 VuXML 简介 XML 是一个复杂的语言， 它远远超越了这本书的范围。 不过， 只需了解标记的命名规则， 就能 VuXML 记录的结构有一个大体的了解了。 XML 标记的名字应出现在一对尖括号之间。 每一个 <tag> 必须有一个对应的 </tag>。 标记可以嵌套， 如果嵌套的话， 内层的标记必须在外层标记之前结束。 这就形成了一个标记的层次结构， 也就是关于它们之间如何嵌套的规则。 听起来很像 HTML， 是不是？ 最主要的区别在于， XML 是可扩展的 (eXtensible)， 例如通过定义新的标记等等。 由于其结构的内在性质， XML 能够赋予无组织的数据新的形态。 VuXML 是专门为描述安全漏洞设计的语言。 现在让我们来观察一个实际的 VuXML 记录： <vuln vid="f4bc80f4-da62-11d8-90ea-0004ac98a7b9"> <topic>Several vulnerabilities found in Foo</topic> <affects> <package> <name>foo</name> <name>foo-devel</name> <name>ja-foo</name> <range><ge>1.6</ge><lt>1.9</lt></range> <range><ge>2.*</ge><lt>2.4_1</lt></range> <range><eq>3.0b1</eq></range> </package> <package> <name>openfoo</name> <range><lt>1.10_7</lt></range> <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> <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> <freebsdsa>SA-10:75.foo</freebsdsa> <freebsdpr>ports/987654</freebsdpr> <cvename>CAN-2010-0201</cvename> <cvename>CAN-2010-0466</cvename> <bid>96298</bid> <certsa>CA-2010-99</certsa> <certvu>740169</certvu> <uscertsa>SA10-99A</uscertsa> <uscertta>SA10-99A</uscertta> <mlist msgid="201075606@hacker.com">http://marc.theaimsgroup.com/?l=bugtraq&amp;m=203886607825605</mlist> <url>http://j.r.hacker.com/advisories/1</url> </references> <dates> <discovery>2010-05-25</discovery> <entry>2010-07-13</entry> <modified>2010-09-17</modified> </dates> </vuln> 标记的名字都是简单明了的， 下面我们来介绍一下需要由您填写的字段： 这是 VuXML 记录的顶级 tag。 它有一个强制性的字段， vid， 用于为此记录 (它包含的部分) 指定一个全局唯一标识符 (UUID)。 您应为每一个新的 vuXML 生成新的 UUID (而且别忘了要把模板中的 UUID 换成新的， 如果您不是从头开始的话)。 您可以使用 &man.uuidgen.1; 来生成 VuXML UUID。 关于问题的一句话描述。 此处给出受到影响的 package 的名字。 可以给出多个名字， 因为可能有多个软件包基于同一个 master port 或软件产品。 这可能包括稳定和开发分支、 本地化版本， 以及提供了不同的编译时选项的 slave port。 撰写 VuXML 记录时， 您有责任找到所有相关的包。 很多时候 make search name=foo 是您的朋友。 需要留意的通常包括： foo port 的 foo-devel 变体； 包含不同后缀的其它变体， 例如 -a4 (对于和打印有关的软件包)， -without-gui (提供但禁用了 X 支持的软件包)， 以及类似的其它情况； jp-， ru-、 zh-， 以及其它可能的本地化变体， 它们通常可以在 Ports Collection 中相应的国家分类中找到。 受影响的 package 版本， 可以使用 <lt>, <le>, <eq>, <ge>, 和 <gt> 表达成一个或多个版本及其范围。 注意给出的版本范围不应存在重叠。 在描述范围的时候， * (星号) 表达最小的版本。 更具体地说， 2.* 小于 2.a。 因此， 星号可以用来匹配所有可能的 alpha、 beta， 以及 RC 版本。 例如， <ge>2.*</ge><lt>3.*</lt> 可以选择性地匹配每一个 2.x 的版本， 而 <ge>2.0</ge><lt>3.0</lt> 显然不能， 因为它会漏掉 2.r3 而匹配 3.b。 上面的例子指定了受影响的版本， 是包括 1.6 到 1.9 上下界的所有版本， 以及 2.x 在 2.4_1 之前的版本， 和 3.0b1 版。 受到影响的一组 package (本质上是 ports) 可以列在 <affected> 小节中。 如果多个软件产品都采用了同样的基础代码， (比如说 FooBar、 FreeBar 和 OpenBar) 而且包含同样的 bug 或漏洞。 请注意列出多个名字时， 应该在一个 <package> 小节中完成。 如果可能， 版本的范围应包括 PORTEPOCH 和 PORTREVISION。 务必注意， 根据加权规则， 带有非零 PORTEPOCH 的版本， 系统会认为比没有 PORTEPOCH 的版本高， 例如 3.0,1 高于 3.1 甚至 8.9。 关于问题的摘要性信息。 此处使用 XHTML。 务必要成对使用 <p> 和 </p>。 可以使用较为复杂的标记， 但仅限于有助于让信息更准确和明了的修饰： 请不要过分地美化。 这部分包含了相关的可供参考的文档。 请尽可能多提供参考文献。 指定 FreeBSD 安全公告。 指定 FreeBSD 问题报告。 指定 Mitre CVE ID。 指定 SecurityFocus Bug ID。 指定 US-CERT 安全公告。 指定 US-CERT 漏洞说明。 指定 US-CERT 计算机安全警报。 指定 US-CERT 技术性计算机安全警报。 指向邮件列表存档的 URL。 属性 msgid 是可选项， 用以指定某一封信的 message ID。 一般的 URL。 只有在没有其它更适合的参考文献时， 才应使用它。 问题被全面披露的日期 (YYYY-MM-DD)。 记录加入到数据库中的日期 (YYYY-MM-DD)。 记录最后一次被修改的日期 (YYYY-MM-DD)。 新记录不应包括这个字段。 只有在修改记录时才应加入它。 测试您对 VuXML 数据库所作的修改 假定您打算撰写， 或已经写好了一个关于 package clamav 的问题描述， 并且， 已经知道 0.65_7 版本修正了这个问题。 您需要做的准备工作， 是 安装 一个新版本的 ports ports-mgmt/portaudit 程序、 ports-mgmt/portaudit-db， 以及 security/vuxml。 要运行 packaudit， 您必须拥有其 DATABASEDIR， 通常是 /var/db/portaudit 的写入权限。 您可以通过 DATABASEDIR 环境变量来指定一个不同的位置。 如果您的工作目录是 ${PORTSDIR}/security/vuxml 以外的其它地方， 则应使用环境变量 VUXMLDIR 来指明 vuln.xml 的位置。 首先， 检查一下是否已经有了关于这个漏洞的描述。 如果已经有过这样的记录， 那么它将匹配较早版本的 package， 0.65_6： &prompt.user; packaudit &prompt.user; portaudit clamav-0.65_6 如果什么都没有发现， 您就可以考虑写一个新的记录来描述这个漏洞了。 现在可以生成一个新的 UUID (假设它是 74a9541d-5d6c-11d8-80e3-0020ed76ef5a)， 然后将您的新记录加入到 VuXML 数据库中。 接下来， 用下面的命令来检查它是否符合语法： &prompt.user; cd ${PORTSDIR}/security/vuxml && make validate 您需要安装下列 package 中的至少一个： textproc/libxml2、 textproc/jade。 接下来从 VuXML 文件重构 portaudit 数据库： &prompt.user; packaudit 要验证您新加入的项的 <affected> 小节能够正确地匹配希望的 package， 可以使用下面的命令： &prompt.user; portaudit -f /usr/ports/INDEX -r 74a9541d-5d6c-11d8-80e3-0020ed76ef5a 请参见 &man.portaudit.1; 以了解关于这个命令语法的更多细节。 请确信新添加的记录不会在输出中匹配不应匹配的项。 现在检查您添加的记录所匹配的版本是否正确： &prompt.user; 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. 显然， 前一个版本会匹配， 而后一个不会。 最后， 验证您从 VuXML 数据库中能够正确地得到预期的网页效果： &prompt.user; mkdir -p ~/public_html/portaudit &prompt.user; packaudit &prompt.user; lynx ~/public_html/portaudit/74a9541d-5d6c-11d8-80e3-0020ed76ef5a.html 该做什么和不该做什么 介绍 这里是一些在移植软件时可能会遇到的常见问题。 您应按照这个列表检查自己的 port， 同样地， 您也可以帮助检查 PR 数据库 中由其它人提交的 port。 请按照在 问题报告和一般性注释 中介绍的方法提交您的看法。 帮助检查 PR 数据库中的 ports 即能够帮助我们更快地 commit 它们， 也能证明您清楚地了解如何完成这些工作。 <varname>WRKDIR</varname> (联编时使用的临时目录) 任何时候都不要在 WRKDIR 以外的位置写文件。 WRKDIR 是在 port 联编过程中唯一的一处一定可写的地方 (参见 如何从 CDROM 安装 port 以了解从只读的目录中联编和安装 port 的例子)。 如果您需要改变 pkg-* 文件， 请按照 重新定义某个变量 介绍的方法， 而不是覆盖它们来实现。 <varname>WRKDIRPREFIX</varname> (用于联编的临时目录的父目录名) 一定要确保您的 port 尊重 WRKDIRPREFIX 的设置。 绝大多数 port 并不需要担心这个。 具体说来， 当引用其它 port 的 WRKDIR 时， 需要注意正确的位置应该是 WRKDIRPREFIXPORTSDIR/subdir/name/work 而不是 PORTSDIR/subdir/name/work 或 .CURDIR/../../subdir/name/work， 或别的什么。 另外， 如果您自行定义了 WRKDIR， 也要把 ${WRKDIRPREFIX}${.CURDIR} 放到前面。 区分不同的操作系统， 以及 OS 的版本 在不同版本的 Unix 下可能需要对代码进行一些修改或增加少许编译选项， 才能够正确地编译和运行。 如果您需要根据一些条件来对代码进行修改， 请尽可能让这些修改通用， 这样， 我们就能够将这些代码移植回更早的 FreeBSD 系统， 并交叉移植到其它 BSD 系统， 例如来自 CSRG 的 4.4BSD， BSD/386， 386BSD， NetBSD 和 OpenBSD。 推荐的获得 4.3BSD/Reno (1990) 以及更新版本 BSD 代码版本号的方式， 是使用 sys/param.h 中所定义的 BSD 宏的值。 一般来说这个文件已经被引用了； 如果没有的话， 增加下述代码： #if (defined(__unix__) || defined(unix)) && !defined(USG) #include <sys/param.h> #endif 到 .c 文件中合适的地方。 我们相信所有定义了这两个符号的系统中， 都提供了 sys/param.h。 如果您发现有不这样做的系统， 请通过致信 &a.ports; 让我们了解这一情况。 另一种方法是使用 GNU Autoconf 风格的方式： #ifdef HAVE_SYS_PARAM_H #include <sys/param.h> #endif 采用这种方法时， 不要忘了把 -DHAVE_SYS_PARAM_H 加到 Makefile 中的 CFLAGS 里。 一旦引用了 sys/param.h， 您就可以使用： #if (defined(BSD) && (BSD >= 199103)) 来检测代码是否正在 4.3 Net2 代码基础， 或更新的系统上编译 (例如 FreeBSD 1.x， 4.3/Reno， NetBSD 0.9， 386BSD， BSD/386 1.1 以及更高版本)。 使用： #if (defined(BSD) && (BSD >= 199306)) 来检测代码是否正在 4.4 或更新的系统 (例如 FreeBSD 2.x， 4.4， NetBSD 1.0、 BSD/386 2.0 或更高版本)。 对于 4.4BSD-Lite2 代码系来说， BSD 宏的值应该是 199506。 这里只是作为信息提供， 您不应使用它来区分基于 4.4-Lite 的 FreeBSD 和基于 4.4-Lite2 的版本。 这些情况下， 您应使用 __FreeBSD__ 宏。 保守地使用： __FreeBSD__ 在所有版本的 FreeBSD 中皆有定义。 如果您正进行的修改 只 影响 FreeBSD， 则应使用这个宏。 类似 sys_errlist[] 之于 strerror() 这样的移植问题是伯克利代码系公用的， 而并非 FreeBSD 所专有。 在 FreeBSD 2.x 中， __FreeBSD__ 定义为 2。 更早版本中， 它曾经是 1。 新的版本都会在主要的版本号变化时变更它。 如果您需要区分 FreeBSD 1.x 系统和 FreeBSD 2.x 及更高版本的区别， 通常应使用前述的 BSD 宏来进行。 如果事实上需要一个 FreeBSD 专有的修改 (例如， 在使用 ld 时需要特殊的共享库选项)， 则可以用 __FreeBSD__ 和 #if __FreeBSD__ > 1 来检测 FreeBSD 2.x 和新系统上的变化。 如果需要更细粒度地检测 FreeBSD 2.0-RELEASE 之后版本的变化， 则可以使用： #if __FreeBSD__ >= 2 #include <osreldate.h> # if __FreeBSD_version >= 199504 /* 适用于 2.0.5+ 版本的代码 */ # endif #endif 在已有的数百个 port 中， 只有一两个应该使用 __FreeBSD__。 早期的 port 在不适当的地方使用了它并引发问题， 并不意味着您也必定如此。 __FreeBSD_version 值 下面是在 sys/param.h __FreeBSD_version 中定义的值及其意义的列表， 这里给出以方便您查阅： __FreeBSD_version 值 值 日期 版本 119411 2.0-RELEASE 199501, 199503 March 19, 1995 2.1-CURRENT 199504 April 9, 1995 2.0.5-RELEASE 199508 August 26, 1995 2.1 之前的 2.2-CURRENT 199511 November 10, 1995 2.1.0-RELEASE 199512 November 10, 1995 2.1.5 之前的 2.2-CURRENT 199607 July 10, 1996 2.1.5-RELEASE 199608 July 12, 1996 2.1.6 之前的 2.2-CURRENT 199612 November 15, 1996 2.1.6-RELEASE 199612 2.1.7-RELEASE 220000 February 19, 1997 2.2-RELEASE (not changed) 2.2.1-RELEASE (无变化) 在 2.2.1-RELEASE 之后的 2.2-STABLE 221001 April 15, 1997 texinfo-3.9 之后的 2.2-STABLE 221002 April 30, 1997 top 之后的 2.2-STABLE 222000 May 16, 1997 2.2.2-RELEASE 222001 May 19, 1997 2.2.2-RELEASE 之后的 2.2-STABLE 225000 October 2, 1997 2.2.5-RELEASE 225001 November 20, 1997 2.2.5-RELEASE 之后的 2.2-STABLE 225002 December 27, 1997 合并 ldconfig -R 之后的 2.2-STABLE 226000 March 24, 1998 2.2.6-RELEASE 227000 July 21, 1998 2.2.7-RELEASE 227001 July 21, 1998 2.2.7-RELEASE 之后的 2.2-STABLE 227002 September 19, 1998 &man.semctl.2; 修改之后的 2.2-STABLE 228000 November 29, 1998 2.2.8-RELEASE 228001 November 29, 1998 2.2.8-RELEASE 之后的 2.2-STABLE 300000 February 19, 1996 &man.mount.2; 修改之前的 3.0-CURRENT 300001 September 24, 1997 &man.mount.2; 修改之后的 3.0-CURRENT 300002 June 2, 1998 &man.semctl.2; 修改之后的 3.0-CURRENT 300003 June 7, 1998 ioctl 参数变化之后的 3.0-CURRENT 300004 September 3, 1998 ELF 变换之后的 3.0-CURRENT 300005 October 16, 1998 3.0-RELEASE 300006 October 16, 1998 3.0-RELEASE 之后的 3.0-CURRENT 300007 January 22, 1999 3/4切分之后的 3.0-STABLE 310000 February 9, 1999 3.1-RELEASE 310001 March 27, 1999 3.1-RELEASE 之后的 3.1-STABLE 310002 April 14, 1999 C++ 构建/析构函数顺序变化之后的 3.1-STABLE 320000 3.2-RELEASE 320001 May 8, 1999 3.2-STABLE 320002 August 29, 1999 二进制不兼容的 IPFW 和 socket 变化之后的 3.2-STABLE 330000 September 2, 1999 3.3-RELEASE 330001 September 16, 1999 3.3-STABLE 330002 November 24, 1999 libc 中加入 &man.mkstemp.3; 之后的 3.3-STABLE 340000 December 5, 1999 3.4-RELEASE 340001 December 17, 1999 3.4-STABLE 350000 June 20, 2000 3.5-RELEASE 350001 July 12, 2000 3.5-STABLE 400000 January 22, 1999 3/4切分之后的 4.0-CURRENT 400001 February 20, 1999 修改动态连接器处理方式之后的 4.0-CURRENT 400002 March 13, 1999 C++ 构建/析构函数顺序变化之后的 400003 March 27, 1999 提供 &man.dladdr.3; 之后的 4.0-CURRENT 400004 April 5, 1999 修正了 __deregister_frame_info 的 4.0-CURRENT (也表示在 EGCS 1.1.2 集成之后的 4.0-CURRENT) 400005 April 27, 1999 &man.suser.9; API 变化之后的 4.0-CURRENT (也表示 newbus 之后的 4.0-CURRENT) 400006 May 31, 1999 cdevsw 注册机制改变之后的 4.0-CURRENT 400007 June 17, 1999 加入了 socket 级凭据的 so_cred 之后的 4.0-CURRENT 400008 June 20, 1999 在 libc_r 中加入 poll 系统调用接口之后的 4.0-CURRENT 400009 July 20, 1999 将内核中 dev_t 类型改为 struct specinfo 指针之后的 4.0-CURRENT 400010 September 25, 1999 修正了一处 &man.jail.2; 漏洞之后的 4.0-CURRENT 400011 September 29, 1999 sigset_t 数据类型改变之后的 4.0-CURRENT 400012 November 15, 1999 切换到 GCC 2.95.2 编译器之后的 4.0-CURRENT 400013 December 4, 1999 加入了可插的 linux模式 ioctl 处理程序后的 4.0-CURRENT 400014 January 18, 2000 引入 OpenSSL 之后的 4.0-CURRENT 400015 January 27, 2000 GCC 2.95.2 中 ABI 默认值从 -fvtable-thunks 改为 -fno-vtable-thunks 之后的 4.0-CURRENT 400016 February 27, 2000 引入 OpenSSH 之后的 4.0-CURRENT 400017 March 13, 2000 4.0-RELEASE 400018 March 17, 2000 4.0-RELEASE 之后的 4.0-STABLE 400019 May 5, 2000 引入延迟校验和之后的 4.0-STABLE 400020 June 4, 2000 将 libxpg4 的代码并入 libc 之后的 4.0-STABLE 400021 July 8, 2000 Binutils 升级到 2.10.0 之后的 4.0-STABLE， ELF 标志变化， 以及将 tcsh 引入基本系统 410000 July 14, 2000 4.1-RELEASE 410001 July 29, 2000 4.1-RELEASE 之后的 4.1-STABLE 410002 September 16, 2000 &man.setproctitle.3; 从 libutil 移入 libc 之后的 4.1-STABLE 411000 September 25, 2000 4.1.1-RELEASE 411001 4.1.1-RELEASE 之后的 4.1.1-STABLE 420000 October 31, 2000 4.2-RELEASE 420001 January 10, 2001 合并 libgcc.a 和 libgcc_r.a， 并修改了相关的 GCC 连接方式之后的 4.2-STABLE 430000 March 6, 2001 4.3-RELEASE 430001 May 18, 2001 引入 wint_t 之后的 4.3-STABLE 430002 July 22, 2001 PCI 电源状态 API 合并之后的 4.3-STABLE 440000 August 1, 2001 4.4-RELEASE 440001 October 23, 2001 引入 d_thread_t 之后的 4.4-STABLE 440002 November 4, 2001 mount 结构改变之后的 4.4-STABLE (影响文件系统 kld) 440003 December 18, 2001 用户态部分的 smbfs 被引入之后的 4.4-STABLE 450000 December 20, 2001 4.5-RELEASE 450001 February 24, 2002 usb 结构元素改名之后的 4.5-STABLE 450004 April 16, 2002 在 &man.rc.conf.5; 变量 sendmail_enable 默认值改为 NONE 之后的 4.5-STABLE 450005 April 27, 2002 默认将 XFree86 4 用于预编译包联编之后的 4.5-STABLE 450006 May 1, 2002 accept 过滤器修正了安全问题并且不再会轻易被 DoS 之后的 4.5-STABLE 460000 June 21, 2002 4.6-RELEASE 460001 June 21, 2002 修正了 &man.sendfile.2; 以吻合文档， 而不再根据发出的头计算发出数据量之后的 4.6-STABLE 460002 July 19, 2002 4.6.2-RELEASE 460100 June 26, 2002 4.6-STABLE 460101 June 26, 2002 MFC `sed -i' 之后的 4.6-STABLE 460102 September 1, 2002 MFC 许多 pkg_install 新特性之后的 4.6-STABLE 470000 October 8, 2002 4.7-RELEASE 470100 October 9, 2002 4.7-STABLE 470101 November 10, 2002 开始生成 __std{in,out,err}p 引用， 而不是 __sF。 这将 std{in,out,err} 从编译时表达式变成了运行时值。 470102 January 23, 2003 MFC mbuf 相关的将 m_aux mbuf 改为 m_tag 的修改之后的 4.7-STABLE 470103 February 14, 2003 OpenSSL 升级到 0.9.7 之后的 4.7-STABLE 480000 March 30, 2003 4.8-RELEASE 480100 April 5, 2003 4.8-STABLE 480101 May 22, 2003 &man.realpath.3; 变为线程安全的之后的 4.8-STABLE 480102 August 10, 2003 对 twe 的 3ware API 修改之后的 4.8-STABLE 490000 October 27, 2003 4.9-RELEASE 490100 October 27, 2003 4.9-STABLE 490101 January 8, 2004 kinfo_eproc 中加入 e_sid 之后的 4.9-STABLE 490102 February 4, 2004 MFC rtld 的 libmap 功能之后的 4.9-STABLE 491000 May 25, 2004 4.10-RELEASE 491100 June 1, 2004 4.10-STABLE 491101 August 11, 2004 MFC 20040629 版本的包维护工具之后的 4.10-STABLE 491102 November 16, 2004 修正了 VM 当解除 wire 不存在页面时的问题之后的 4.10-STABLE 492000 December 17, 2004 4.11-RELEASE 492100 December 17, 2004 4.11-STABLE 492101 April 18, 2006 将 libdata/ldconfig 目录加入 mtree 文件之后的 4.11-STABLE。 500000 March 13, 2000 5.0-CURRENT 500001 April 18, 2000 加入 ELF 头字段， 并改变我们的 ELF 执行文件标记方式之后的 5.0-CURRENT 500002 May 2, 2000 kld 元数据修改之后的 5.0-CURRENT 500003 May 18, 2000 buf/bio 修改之后的 5.0-CURRENT 500004 May 26, 2000 binutils 升级后的 5.0-CURRENT 500005 June 3, 2000 将 libxpg4 并入 libc， 以及引入 TASKQ 之后的 5.0-CURRENT 500006 June 10, 2000 加入 AGP 接口之后的 5.0-CURRENT 500007 June 29, 2000 Perl 升级到 5.6.0 之后的 5.0-CURRENT 500008 July 7, 2000 KAME 代码升级到 2000/07 之后的 5.0-CURRENT 500009 July 14, 2000 ether_ifattach() 和 ether_detach() 修改之后的 5.0-CURRENT 500010 July 16, 2000 将 mtree 改为原先的默认值， 并使用 -L 来跟随符号连接之后的 5.0-CURRENT 500011 July 18, 2000 kqueue API 修改之后的 5.0-CURRENT 500012 September 2, 2000 &man.setproctitle.3; 从 libutil 挪到 libc 之后的 5.0-CURRENT 500013 September 10, 2000 首个 SMPng commit 之后的 5.0-CURRENT 500014 January 4, 2001 <sys/select.h> 改为 <sys/selinfo.h> 之后的 5.0-CURRENT 500015 January 10, 2001 libgcc.a 和 libgcc_r.a 以及 GCC 连接方式变动之后的 5.0-CURRENT 500016 January 24, 2001 修改以允许 libc 和 libc_r 连接到一起， 不再鼓励使用 -pthread 之后的 5.0-CURRENT 500017 February 18, 2001 从 struct ucred 切换到 struct xucred 以便使内核为 mountd 等程序导出的 API 稳定下来之后的 5.0-CURRENT 500018 February 24, 2001 加入 CPUTYPE 用于 CPU 专用的优化的 make 变量之后的 5.0-CURRENT 500019 June 9, 2001 machine/ioctl_fd.h 改为 sys/fdcio.h 之后的 5.0-CURRENT 500020 June 15, 2001 locale 名称改变之后的 5.0-CURRENT 500021 June 22, 2001 引入 bzip2 之后的 5.0-CURRENT， 同时也代表删去了 S/Key 500022 July 12, 2001 加入 SSE 支持之后的 5.0-CURRENT 500023 September 14, 2001 KSE 第2个里程碑之后的 5.0-CURRENT 500024 October 1, 2001 d_thread_t 之后的 5.0-CURRENT， 同时 UUCP 被移入 ports 500025 October 4, 2001 64-位平台上的描述符和 creds API 变化之后的 5.0-CURRENT 500026 October 9, 2001 采用 XFree86 4 作为默认的预编译包， 以及加入 strnstr() libc 函数之后的 5.0-CURRENT 500027 October 10, 2001 加入 strcasestr() libc 函数之后的 5.0-CURRENT 500028 December 14, 2001 引入了用户态的 smbfs 组件之后的 5.0-CURRENT (未予增加) 加入了新的 C99 指定位宽整形变量之后的 5.0-CURRENT 500029 January 29, 2002 修改了 &man.sendfile.2; 的返回值之后的 5.0-CURRENT 500030 February 15, 2002 引入适合表达文件标志的 fflags_t 类型之后的 5.0- 500031 February 24, 2002 usb 结构元素改名之后的 5.0-CURRENT 500032 March 16, 2002 引入 Perl 5.6.1 之后的 5.0-CURRENT 500033 April 3, 2002 &man.rc.conf.5; 变量 sendmail_enable 默认值改为 NONE 之后的 5.0-CURRENT 500034 April 30, 2002 mtx_init() 增加了第三个参数之后的 5.0-CURRENT 500035 May 13, 2002 包含 Gcc 3.1 的 5.0-CURRENT 500036 May 17, 2002 在 /usr/src 中删去了 Perl 的 5.0-CURRENT 500037 May 29, 2002 加入 &man.dlfunc.3; 之后的 5.0-CURRENT 500038 July 24, 2002 一些 struct sockbuf 的成员变为结构， 并重新排列顺序之后的 5.0-CURRENT 500039 September 1, 2002 引入 GCC 3.2.1 之后的 5.0-CURRENT。 头文件也不再使用 _BSD_FOO_T_ 而开始使用 _FOO_T_DECLARED。 这个值还可以用于作为一个包含使用 &man.bzip2.1; 的预编译包支持的预期点。 500040 September 20, 2002 以去掉对 disklabel 结构内容的依赖的名义， 对磁盘相关的函数进行了许多修改之后的 5.0-CURRENT 500041 October 1, 2002 libc 中加入 &man.getopt.long.3; 之后的 5.0-CURRENT 500042 October 15, 2002 Binutils 2.13 升级， 包含了新的 FreeBSD 模拟， vec 以及输出格式之后的 5.0-CURRENT 500043 November 1, 2002 libc 中加入了弱 pthread_XXX 符号之后的 5.0-CURRENT， 从而淘汰了 libXThrStub.so。 5.0-RELEASE。 500100 January 17, 2003 创建 RELENG_5_0 分支之后的 5.0-CURRENT 500101 February 19, 2003 <sys/dkstat.h> 变成了一个空文件， 不应再被引用 500102 February 25, 2003 修改 d_mmap_t 接口之后的 5.0-CURRENT 500103 February 26, 2003 taskqueue_swi 以无全局锁的方式运行之后的 5.0-CURRENT， 同时还加入了使用全局锁的 taskqueue_swi_giant 500104 February 27, 2003 去掉了 cdevsw_add() 和 cdevsw_remove() 出现 MAJOR_AUTO 分配机制 500105 March 4, 2003 采用新的 cdevsw 初始化方法之后的 5.0-CURRENT 500106 March 8, 2003 devstat_add_entry() 被 devstat_new_entry() 取代 500107 March 15, 2003 修改 devstat 接口； 请参见 sys/sys/param.h 1.149 500108 March 15, 2003 改变了 Token-Ring 接口 500109 March 25, 2003 加入 vm_paddr_t 500110 March 28, 2003 将 &man.realpath.3; 改为线程安全之后的 5.0-CURRENT 500111 April 9, 2003 &man.usbhid.3; 与 NetBSD 同步之后的 5.0-CURRENT 500112 April 17, 2003 加入新的 NSS 实现， 以及 POSIX.1 getpw*_r, getgr*_r 函数之后的 5.0-CURRENT 500113 May 2, 2003 删去旧式 rc 系统之后的 5.0-CURRENT 501000 June 4, 2003 5.1-RELEASE. 501100 June 2, 2003 创建 RELENG_5_1 分支之后的 5.1-CURRENT 501101 June 29, 2003 改正 sigtimedwait(2) 和 sigwaitinfo(2) 语义之后的 5.1-CURRENT 501102 July 3, 2003 在 &man.bus.dma.tag.create.9; 中加入了 lockfunc 和 lockfuncarg 字段之后的 5.1-CURRENT 501103 July 31, 2003 集成了 GCC 3.3.1-pre 20030711 之后的 5.1-CURRENT 501104 August 5, 2003 twe 中 3ware API 变化之后的 5.1-CURRENT 501105 August 17, 2003 允许动态连接 /bin 和 /sbin， 以及将某些库移动到 /lib 之后的 5.1-CURRENT 501106 September 8, 2003 增加内核级 Coda 6.x 支持之后的 5.1-CURRENT 501107 September 17, 2003 将 16550 UART 常量从 <dev/sio/sioreg.h> 挪到 <dev/ic/ns16550.h> 之后的 5.1-CURRENT。 此外， rtld 也从此无条件支持 libmap 功能 501108 September 23, 2003 更新 PFIL_HOOKS API 之后的 5.1-CURRENT 501109 September 27, 2003 增加 kiconv(3) 之后的 5.1-CURRENT 501110 September 28, 2003 默认的 cdevsw open 和 close 操作变化之后的 5.1-CURRENT 501111 October 16, 2003 cdevsw 的布局变化之后的 5.1-CURRENT 501112 October 16, 2003 增加 kobj 多继承之后的 5.1-CURRENT 501113 October 31, 2003 修改 struct ifnet 中的 if_xname 之后的 5.1-CURRENT 501114 November 16, 2003 将 /bin 和 /sbin 改为动态连接之后的 5.1-CURRENT 502000 December 7, 2003 5.2-RELEASE 502010 February 23, 2004 5.2.1-RELEASE 502100 December 7, 2003 创建 RELENG_5_2 分支之后的 5.2-CURRENT 502101 December 19, 2003 libc 中加入了 __cxa_atexit/__cxa_finalize 两个函数之后的 5.2-CURRENT 502102 January 30, 2004 默认线程库从 libc_r 改为 libpthread 之后的 5.2-CURRENT 502103 February 21, 2004 设备驱动 API 大规模翻修之后的 5.2-CURRENT 502104 February 25, 2004 增加 getopt_long_only() 之后的 5.2-CURRENT 502105 March 5, 2004 C 的 NULL 定义改为 ((void *)0) 之后的 5.2-CURRENT， 这会产生更多的编译警告 502106 March 8, 2004 pf 连入联编和安装过程之后的 5.2-CURRENT 502107 March 10, 2004 在 sparc64 上将 time_t 改为 64-位 值之后的 5.2-CURRENT 502108 March 12, 2004 在一些头文件修改以支持 Intel C/C++ 编译器， 以及让 execve(2) 更严格地符合 POSIX 之后的 5.2-CURRENT 502109 March 22, 2004 引入 bus_alloc_resource_any API 之后的 5.2-CURRENT 502110 March 27, 2004 加入 UTF-8 locale 之后的 5.2-CURRENT 502111 April 11, 2004 删去 getvfsent(3) API 之后的 5.2-CURRENT 502112 April 13, 2004 为 make(1) 增加 .warning 语句之后的 5.2-CURRENT 502113 June 4, 2004 所有串口设备都强制使用 ttyioctl() 之后的 5.2-CURRENT 502114 June 13, 2004 引入 ALTQ 框架之后的 5.2-CURRENT 502115 June 14, 2004 修改 sema_timedwait(9) 使其成功时返回 0， 失败时返回非 0 的错误代码之后的 5.2-CURRENT 502116 June 16, 2004 将内核 dev_t 改为指向 struct cdev * 的指针之后的 5.2-CURRENT 502117 June 17, 2004 将内核 udev_t 改为 dev_t 之后的 5.2-CURRENT 502118 June 17, 2004 为 clock_gettime(2) 和 clock_getres(2) 增加 CLOCK_VIRTUAL 和 CLOCK_PROF 支持之后的 5.2-CURRENT 502119 June 22, 2004 对网络接口复制进行全面修改之后的 5.2-CURRENT 502120 July 2, 2004 package 工具升级为 20040629 之后的 5.2-CURRENT 502121 July 9, 2004 不再将蓝牙代码标记为 i386 专用之后的 5.2-CURRENT 502122 July 11, 2004 引入 KDB 调试器框架之后的 5.2-CURRENT。 同时还引入了 DDB 作为后台， 以及 GDB 后台。 502123 July 12, 2004 修改 VFS_ROOT 和 vflush 使其使用一个 struct thread 参数之后的 5.2-CURRENT。 struct kinfo_proc 增加了一个用户数据指针。 同时， 默认的 X 实现切换为 xorg 502124 July 24, 2004 将使用 rc.d 和传统脚本的 port 分别启动之后的 5.2-CURRENT 502125 July 28, 2004 取消前一修改之后的 5.2-CURRENT 502126 July 31, 2004 删除 kmem_alloc_pageable() 并引入 gcc 3.4.2 的 5.2-CURRENT 502127 August 2, 2004 修改 UMA 内核 API 允许构建函数和初始化失败之后的 5.2-CURRENT 502128 August 8, 2004 vfs_mount 签名和全局替换 suser(9) API 的 PRISON_ROOT 为 SUSER_ALLOWJAIL 之后的 5.2-CURRENT 503000 August 23, 2004 pfil API 修改之前的 5.3-BETA/RC 503001 September 22, 2004 5.3-RELEASE 503100 October 16, 2004 创建 RELENG_5_3 分支之后的 5.3-STABLE 503101 December 3, 2004 加入了 glibc 风格的 &man.strftime.3; 填充选项的 5.3-STABLE 503102 February 13, 2005 MFC OpenBSD 的 nc(1) 之后的 5.3-STABLE 503103 February 27, 2005 在 MFC 了 <src/include/stdbool.h> 和 <src/sys/i386/include/_types.h> 用于兼容 GCC 和 Intel C/C++ 编译器的修正之后的 5.4-PRERELEASE 503104 February 28, 2005 MFC 了将 ifi_epoch 由 wall 时钟时间改为 uptime 之后的 5.4-PRERELEASE 503105 March 2, 2005 MFC 了 vswprintf(3) 中的 EOVERFLOW 检查的 5.4-PRERELEASE 504000 April 3, 2005 5.4-RELEASE. 504100 April 3, 2005 创建 RELENG_5_4 分支之后的 5.4-STABLE 504101 May 11, 2005 加大默认线程堆栈尺寸之后的 5.4-STABLE 504102 June 24, 2005 加入 sha256 之后的 5.4-STABLE 504103 October 3, 2005 MFC if_bridge 之后的 5.4-STABLE 504104 November 13, 2005 bsdiff 和 portsnap MFC 之后的 5.4-STABLE 504105 January 17, 2006 在 MFC 了 ldconfig_local_dirs 修改之后的 5.4-STABLE。 505000 May 12, 2006 5.5-RELEASE. 505100 May 12, 2006 在创建 RELENG_5_5 分支之后的 5.5-STABLE 600000 August 18, 2004 6.0-CURRENT 600001 August 27, 2004 内核中永久性启用 PFIL_HOOKS 之后的 6.0-CURRENT 600002 August 30, 2004 最初将 ifi_epoch 加入 if_data 结构之后的 6.0-CURRENT。 此后不久即被撤销。 请不要使用这个值。 600003 September 8, 2004 if_data 中再次加入 ifi_epoch 成员之后的 6.0-CURRENT 600004 September 29, 2004 将 struct inpcb 参数加入 pfil API 之后的 6.0-CURRENT 600005 October 5, 2004 newsyslog 加入了 "-d DESTDIR" 参数之后的 6.0-CURRENT 600006 November 4, 2004 加入了 glibc 风格的 &man.strftime.3; 填充选项之后的 6.0-CURRENT 600007 December 12, 2004 加入了 802.11 框架更新之后的 6.0-CURRENT 600008 January 25, 2005 修改 VOP_*VOBJECT() 并为无全局锁的文件系统引入 MNTK_MPSAFE 标志之后的 6.0-CURRENT 600009 February 4, 2005 加入 cpufreq 框架和驱动之后的 6.0-CURRENT 600010 February 6, 2005 引入 OpenBSD 的 nc(1) 之后的 6.0-CURRENT 600011 February 12, 2005 删去并不存在的 SVID2 matherr() 支持之后的 6.0-CURRENT 600012 February 15, 2005 增大默认线程堆栈尺寸之后的 6.0-CURRENT 600013 February 19, 2005 增加了针对 <src/include/stdbool.h> 和 <src/sys/i386/include/_types.h> 的用于 Intel C/C++ 编译器的 GCC-兼容性修正。 600014 February 21, 2005 修正了 vswprintf(3) 的 EOVERFLOW 检查之后的 6.0-CURRENT 600015 February 25, 2005 将 struct if_data 成员 ifi_epoch 从 wall 时钟时间改为 uptime 之后的 6.0-CURRENT 600016 February 26, 2005 修改 LC_CTYPE 磁盘格式之后的 6.0-CURRENT 600017 February 27, 2005 修改 NLS 编录磁盘格式之后的 6.0-CURRENT 600018 February 27, 2005 修改 LC_COLLATE 磁盘格式之后的 6.0-CURRENT 600019 February 28, 2005 将 acpica 头文件安装到 /usr/include 600020 March 9, 2005 为 send(2) API 加入了 MSG_NOSIGNAL 600021 March 17, 2005 在 cdevsw 上增加了一些字段 600022 March 21, 2005 基本系统中删去了 gtar 600023 April 13, 2005 unix(4) 中加入了 LOCAL_CREDS, LOCAL_CONNWAIT 两个 socket 选项 600024 April 19, 2005 加入了 &man.hwpmc.4; 及其相关工具之后的 6.0-CURRENT 600025 April 26, 2005 加入 struct icmphdr 之后的 6.0-CURRENT 600026 May 3, 2005 pf 更新到了 3.7 600027 May 6, 2005 引入了内核 libalias 和 ng_nat 600028 May 13, 2005 将 ttyname_r(3) 接口改为符合 POSIX 标准， 并通过 unistd.h 和 libc 600029 May 29, 2005 将 libpcap 升级为 v0.9.1 alpha 096 之后的 6.0-CURRENT 600030 June 5, 2005 引入 NetBSD 的 if_bridge(4) 之后的 6.0-CURRENT 600031 June 10, 2005 将 struct ifnet 从驱动的 softc 中拆出之后的 6.0-CURRENT。 600032 July 11, 2005 引入了 libpcap v0.9.1 之后的 6.0-CURRENT。 600033 July 25, 2005 所有自 RELENG_5 以来没有修改过的共享库的版本递增之后的 6.0-STABLE。 600034 August 13, 2005 为 dev_clone 事件处理函数增加身份信息参数之后的 6.0-STABLE。 6.0-RELEASE。 600100 November 1, 2005 6.0-RELEASE 之后的 6.0-STABLE 600101 December 21, 2005 将 local_startup 目录中的脚本集成到基本系统的 &man.rcorder.8; 之后的 6.0-STABLE。 600102 December 30, 2005 更新 ELF 类型和常量之后的 6.0-STABLE。 600103 January 15, 2006 MFC 了 pidfile(3) API 之后的 6.0-STABLE。 600104 January 17, 2006 在 MFC 了 ldconfig_local_dirs 修改之后的 6.0-STABLE。 600105 February 26, 2006 在 csh(1) 中加入了 NLS 目录支持之后的 6.0-STABLE。 601000 May 6, 2006 6.1-RELEASE 601100 May 6, 2006 6.1-RELEASE 之后的 6.1-STABLE。 601101 June 22, 2006 引入 csup 之后的 6.1-STABLE。 601102 July 11, 2006 更新了 iwi(4) 之后的 6.1-STABLE。 601103 July 17, 2006 将域名解析函数更新至 BIND9， 并导出了可重入版本的 netdb 函数之后的 6.1-STABLE。 601104 August 8, 2006 在 OpenSSL 中启用了 DSO (动态共享库) 支持之后的 6.1-STABLE。 601105 September 2, 2006 由于 802.11 修正变动了 IEEE80211_IOC_STA_INFO ioctl API 之后的 6.1-STABLE。 602000 November 15, 2006 6.2-RELEASE 602100 September 15, 2006 6.2-RELEASE 之后的 6.2-STABLE。 602101 December 12, 2006 加入 Wi-Spy quirk 之后的 6.2-STABLE。 602102 December 28, 2006 增加 pci_find_extcap() 之后的 6.2-STABLE。 602103 January 16, 2007 MFC 了对 dlsym 进行修改， 使其在指定 dso 及其暗指的依赖中查找符号之后的 6.2-STABLE。 602104 January 28, 2007 MFC 了 netgraph 节点 ng_deflate(4) 和 ng_pred1(4) 以及用于 ng_ppp(4) 节点的新压缩及加密模式之后的 6.2-STABLE。 602105 February 20, 2007 MFC 了从 NetBSD 移植的 BSD 授权的 &man.gzip.1; 之后的 6.2-STABLE。 602106 March 31, 2007 MFC 了 PCI MSI 和 MSI-X 支持之后的 6.2-STABLE。 602107 April 6, 2007 MFC 了包含宽字符支持的 ncurses 5.6 之后的 6.2-STABLE。 602108 April 11, 2007 MFC 了实现 Linux SCSI SG 直通设备 API 子集的 CAM 'SG' 设备之后的 6.2-STABLE。 602109 April 17, 2007 MFC 了 readline 5.2 patchset 002 之后的 6.2-STABLE。 602110 May 2, 2007 MFC 了用于 amd64 和 i386 的 pmap_invalidate_cache()、 pmap_change_attr()、 pmap_mapbios()、 pmap_mapdev_attr()、 and pmap_unmapbios() 之后的 6.2-STABLE。 602111 June 11, 2007 由于 MFC 了 BOP_BDFLUSH 导致文件系统模块 KBI 变化之后的 6.2-STABLE。 602112 September 21, 2007 一系列 libutil(3) MFC 之后的 6.2-STABLE。 602113 October 25, 2007 MFC 了宽字符和单字节 ctype 函数分拆之后的 6.2-STABLE。 新编译的引用了 ctype.h 的可执行文件， 可能会需要一个在旧系统上不存在的新增符号 __mb_sb_limit。 602114 October 30, 2007 恢复了 ctype ABI 向前兼容性之后的 6.2-STABLE。 602115 November 21, 2007 回退了宽字符和单字节 ctype 分拆之后的 6.2-STABLE。 603000 November 25, 2007 6.3-RELEASE 603100 November 25, 2007 在 6.3-RELEASE 之后的 6.3-STABLE。 603101 December 7, 2007 修正了 bit macro 的多字节支持之后的 6.3-STABLE。 603102 April 24, 2008 为 flock 结构加入 l_sysid 之后的 6.3-STABLE。 603103 May 27, 2008 MFC 了 memrchr 函数之后的 6.3-STABLE。 603104 June 15, 2008 为 make(1) MFC :u 变量修饰符之后的 6.3-STABLE。 604000 October 4, 2008 6.4-RELEASE 604100 October 4, 2008 6.4-RELEASE 之后的 6.4-STABLE。 700000 July 11, 2005 7.0-CURRENT。 700001 July 23, 2005 所有自 RELENG_5 以来没有修改过的共享库的版本递增之后的 7.0-CURRENT。 700002 August 13, 2005 为 dev_clone 事件处理函数中增加身份信息参数之后的 7.0-CURRENT。 700003 August 25, 2005 将 memmem(3) 加入 libc 之后的 7.0-CURRENT。 700004 October 30, 2005 将 solisten(9) 改为接受一 backlog 参数之后的 7.0-CURRENT。 700005 November 11, 2005 将 IFP2ENADDR() 改为返回一 IF_LLADDR() 指针之后的 7.0-CURRENT。 700006 November 11, 2005 在 struct ifnet 中增加 if_addr 成员， 并删除 IFP2ENADDR() 之后的 7.0-CURRENT。 700007 December 2, 2005 将 local_startup 目录中的脚本集成到基本系统的 &man.rcorder.8; 之后的 7.0-CURRENT。 700008 December 5, 2005 去掉 MNT_NODEV 挂接选项之后的 7.0-CURRENT。 700009 December 19, 2005 对 ELF-64 类型和符号版本进行变更之后的 7.0-CURRENT。 700010 December 20, 2005 增加 hostb 和 vgapci 驱动、 pci_find_extcap()， 并将 AGP 驱动改为不再影射 aperature 之后的 7.0-CURRENT。 700011 December 31, 2005 除 Alpha 之外的所有平台上 tv_sec 改为 time_t 之后的 7.0-CURRENT。 700012 January 8, 2006 修改 ldconfig_local_dirs 之后的 7.0-CURRENT。 700013 January 12, 2006 在修改了 /etc/rc.d/abi 以支持 /compat/linux/etc/ld.so.cache 以某只读文件系统上的符号连接形式存在之后的 7.0-CURRENT。 700014 January 26, 2006 引入 pts 之后的 7.0-CURRENT。 700015 March 26, 2006 在引入 &man.hwpmc.4; 的第 2 版 ABI 之后的 7.0-CURRENT。 700016 April 22, 2006 在 libc 中加入了 &man.fcloseall.3; 之后的 7.0-CURRENT。 700017 May 13, 2006 删去 ip6fw 之后的 7.0-CURRENT。 700018 July 15, 2006 引入了 snd_emu10kx 之后的 7.0-CURRENT。 700019 July 29, 2006 引入了 OpenSSL 0.9.8b 之后的 7.0-CURRENT。 700020 September 3, 2006 增加了 bus_dma_get_tag 函数之后的 7.0-CURRENT。 700021 September 4, 2006 在引入了 libpcap 0.9.4 和 tcpdump 3.9.4 之后的 7.0-CURRENT。 700022 September 9, 2006 在对 dlsym 进行修改， 使其在指定 dso 及其暗指的依赖中查找符号之后的 7.0-CURRENT。 700023 September 23, 2006 为 OSSv4 混音器 API 加入新的声音 IOCTL 之后的 7.0-CURRENT。 700024 September 28, 2006 汇入 OpenSSL 0.9.8d 之后的 7.0-CURRENT。 700025 November 11, 2006 加入了 libelf 之后的 7.0-CURRENT。 700026 November 26, 2006 对音效相关的 sysctl 进行大幅调整之后的 7.0-CURRENT。 700027 November 30, 2006 加入 Wi-Spy quirk 之后的 7.0-CURRENT。 700028 December 15, 2006 在 libc 中加入 sctp 调用之后的 7.0-CURRENT。 700029 January 26, 2007 将 GNU &man.gzip.1; 实现替换为从 NetBSD 移植的采用 BSD 授权版本之后的 7.0-CURRENT。 700030 February 7, 2007 在 IPv4 多播转发代码中删去了 IPIP 隧道封装 (VIFF_TUNNEL) 之后的 7.0-CURRENT。 700031 February 23, 2007 修改了 bus_setup_intr() (newbus) 之后的 7.0-CURRENT。 700032 March 2, 2007 引入了 ipw(4) 和 iwi(4) 固件之后的 7.0-CURRENT。 700033 March 9, 2007 在 ncurses 中引入了宽字符支持之后的 7.0-CURRENT。 700034 March 19, 2007 修改了 insmntque()、 getnewvnode() 以及 vfs_hash_insert() 工作方式之后的 7.0-CURRENT。 700035 March 26, 2007 增加 CPU 频率变动通知机制之后的 7.0-CURRENT。 700036 April 6, 2007 引入了 ZFS 文件系统之后的 7.0-CURRENT。 700037 April 8, 2007 新增了实现 Linux SCSI SG 直通设备 API 子集的 CAM 'SG' 设备之后的 7.0-CURRENT。 700038 April 30, 2007 将 &man.getenv.3;、 &man.putenv.3;、 &man.setenv.3; 和 &man.unsetenv.3; 改为符合 POSIX 之后的 7.0-CURRENT。 700039 May 1, 2007 回退了 700038 中的变动之后的 7.0-CURRENT。 700040 May 10, 2007 在 libutil 中增加了 &man.flopen.3; 之后的 7.0-CURRENT。 700041 May 13, 2007 启用了符号版本， 并将 libthr 改为默认线程库之后的 7.0-CURRENT。 700042 May 19, 2007 引入了 gcc 4.2.0 之后的 7.0-CURRENT。 700043 May 21, 2007 将 RELENG_6 之后未修改过版本的共享库版本增加之后的 7.0-CURRENT。 700044 June 7, 2007 将 vn_open()/VOP_OPEN() 的参数由文件描述符数组下标改为 struct file * 之后的 7.0-CURRENT。 700045 June 10, 2007 修改 &man.pam.nologin.8; 使其向 PAM 框架提供帐号管理功能而非身份验证功能之后的 7.0-CURRENT。 700046 June 11, 2007 更新 802.11 无线支持之后的 7.0-CURRENT。 700047 June 11, 2007 增加 TCP LRO 网络接口能力之后的 7.0-CURRENT。 700048 June 12, 2007 在 IPv4 协议栈中加入了 RFC 3678 API 支持之后的 7.0-CURRENT。 先前 IP_MULTICAST_IF ioctl 的 RFC 1724 行为被删去； 0.0.0.0/8 不再能够用于指定接口索引下标， 而应使用 struct ipmreqn 代替。 700049 July 3, 2007 引入 OpenBSD 4.1 的 pf 之后的 7.0-CURRENT。 (not changed) 为 FAST_IPSEC 增加 IPv6 支持， 删去 KAME IPSEC， 并将 FAST_IPSEC 更名为 IPSEC 之后的 7.0-CURRENT。 (未变动) 700050 July 4, 2007 将 setenv/putenv/等等调用， 从传统 BSD 改为 POSIX 标准之后的 7.0-CURRENT。 700051 July 4, 2007 增加新的 mmap/lseek/等等这些系统调用之后的 7.0-CURRENT。 700052 July 6, 2007 将 I4B 头文件移动到 include/i4b 之后的 7.0-CURRENT。 700053 September 30, 2007 增加了 PCI domain 支持之后的 7.0-CURRENT。 700054 October 25, 2007 MFC 了宽字符和单字节字符 ctype 分拆之后的 7.0-CURRENT。 700055 October 28, 2007 7.0-RELEASE， 以及 MFC 了恢复对 FreeBSD 4/5/6 版本的 PCIOCGETCONF、 PCIOCREAD 和 PCIOCWRITE IOCTL ABI 向下兼容之后的 7.0-CURRENT， 这一变动导致 PCIOCGETCONF IOCTL 的 ABI 再次发生变化。 700100 December 22, 2007 7.0-RELEASE 之后的 7.0-STABLE 700101 February 8, 2008 MFC m_collapse() 之后的 7.0-STABLE。 700102 March 30, 2008 MFC kdb_enter_why() 之后的 7.0-STABLE。 700103 April 10, 2008 为 flock 结构加入 l_sysid 之后的 7.0-STABLE。 700104 April 11, 2008 在 procstat(1) MFC 之后的 7.0-STABLE。 700105 April 11, 2008 在 MFC umtx 特性之后的 7.0-STABLE。 700106 April 15, 2008 为 &man.psm.4; MFC &man.write.2; 支持之后的 7.0-STABLE。 700107 April 20, 2008 为 &man.fcntl.2; MFC F_DUP2FD 之后的 7.0-STABLE。 700108 May 5, 2008 对 &man.lockmgr.9; 做了一些修改之后的 7.0-STABLE， 在使用 &man.lockmgr.9; 时必需包含 sys/lock.h。 700109 May 27, 2008 MFC 了 memrchr 函数之后的 7.0-STABLE。 700110 August 5, 2008 MFC 了内核 NFS locked 客户端之后的 7.0-STABLE。 700111 August 20, 2008 加入了对物理连续巨帧支持之后的 7.0-STABLE。 700112 August 27, 2008 在 MFC 内核 DTrace 支持之后的 7.0-STABLE。 701000 November 25, 2008 7.1-RELEASE 701100 November 25, 2008 7.1-RELEASE 之后的 7.1-STABLE。 701101 January 10, 2009 合并了 strndup 之后的 7.1-STABLE。 701102 January 17, 2009 加入了 cpuctl(4) 支持之后的 7.1-STABLE。 701103 February 7, 2009 合并了 多/无-IPv4/v6 jail 之后的 7.1-STABLE。 701104 February 14, 2009 在 struct mount 中保存了挂起属主， 以及在 struct vfsops 中引入了 vfs_susp_clean 方法之后的 7.1-STABLE。 701105 March 12, 2009 对 kern.ipc.shmsegs sysctl 变量不兼容的修改， 以允许在 64bit 构架上分配更多的 SysV 共享内存段之后的 7.1-STABLE。 701106 March 14, 2009 合并了一个对 POSIX semaphore 等待操作修正之后的 7.1-STABLE。 702000 April 15, 2009 7.2-RELEASE 702100 April 15, 2009 7.2-RELEASE 之后的 7.2-STABLE。 702101 May 15, 2009 ichsmb(4) 改为使用左邻接辅编址来保持与其它 SMBus 控制器驱动一致性之后的 7.2-STABLE。 702102 May 28, 2009 MFC 了 fdopendir 函数之后的 7.2-STABLE。 702103 June 06, 2009 MFC 了 PmcTools 之后的 7.2-STABLE。 702104 July 14, 2009 MFC 了 closefrom 系统调用之后的 7.2-STABLE。 702105 July 31, 2009 MFC 了 SYSVIPC ABI 改动之后的 7.2-STABLE。 702106 September 14, 2009 MFC 了 x86 PAT 增强， 并新增了 d_mmap_single() 以及 scatter/gather 型 VM 对象类型之后的 7.2-STABLE。 703000 February 9, 2010 7.3-RELEASE 703100 February 9, 2010 7.3-RELEASE 之后的 7.3-STABLE。 704000 December 22, 2010 7.4-RELEASE 704100 December 22, 2010 7.4-RELEASE 之后的 7.4-STABLE。 800000 October 11, 2007 8.0-CURRENT。 分拆了宽字符和单字节字符 ctype。 800001 October 16, 2007 引入了 libpcap 0.9.8 和 tcpdump 3.9.8 之后的 8.0-CURRENT。 800002 October 21, 2007 将 kthread_create() 系列函数改名为 kproc_create() 之后的 8.0-CURRENT。 800003 October 24, 2007 恢复了对 FreeBSD 4/5/6 版本的 PCIOCGETCONF、 PCIOCREAD 和 PCIOCWRITE IOCTL ABI 向下兼容之后的 8.0-CURRENT， 这一变动导致 PCIOCGETCONF IOCTL 的 ABI 再次发生变化。 800004 November 12, 2007 将 agp(4) 驱动从 src/sys/pci 挪到 src/sys/dev/agp 之后的 8.0-CURRENT。 800005 December 4, 2007 修改了 jumbo frame 分配器之后的 8.0-CURRENT。 800006 December 7, 2007 在给 &man.hwpmc.4; 加入了 callgraph 捕捉功能后的 8.0-CURRENT 800007 December 25, 2007 kdb_enter() 增加 "why" 参数之后的 8.0-CURRENT。 800008 December 28, 2007 在去除 LK_EXCLUPGRADE 选项后的 8.0-CURRENT。 800009 January 9, 2008 引入 &man.lockmgr.disown.9; 之后的 8.0-CURRENT。 800010 January 10, 2008 修改 &man.vn.lock.9; 原型之后的 8.0-CURRENT。 800011 January 13, 2008 修改 &man.VOP.LOCK.9; 和 &man.VOP.UNLOCK.9; 原型之后的 8.0-CURRENT。 800012 January 19, 2008 引入 &man.lockmgr.recursed.9;、 &man.BUF.RECURSED.9; 和 &man.BUF.ISLOCKED.9; 并删除了 BUF_REFCNT() 之后的 8.0-CURRENT。 800013 January 23, 2008 引入 ASCII 编码之后的 8.0-CURRENT。 800014 January 24, 2008 修改 &man.lockmgr.9; 并删除了 lockcount() 和 LOCKMGR_ASSERT() 之后的 8.0-CURRENT。 800015 January 26, 2008 扩展了 &man.fts.3; 数据结构之后的 8.0-CURRENT。 800016 February 1, 2008 为 MEXTADD(9) 增加了一个参数之后的 8.0-CURRENT。 800017 February 6, 2008 为 &man.lockmgr.9; 引入 LK_NODUP 和 LK_NOWITNESS 选项后的 8.0-CURRENT。 800018 February 8, 2008 引入 m_collapse 之后的 8.0-CURRENT。 800019 February 9, 2008 为 sysctl 变量 kern.proc.filedesc 加入 当前工作目录，root 目录和 jail 目录支持之后的 8.0-CURRENT。 800020 February 13, 2008 引入 &man.lockmgr.assert.9; 之后的 8.0-CURRENT。 800021 February 15, 2008 引入 &man.lockmgr.args.9; 和移除 LK_INTERNAL 标志之后的 8.0-CURRENT。 800022 (backed out) 把 BSD &man.ar.1; 作为系统默认的 ar 之后的 8.0-CURRENT。 800023 February 25, 2008 修改了 &man.lockstatus.9; 和 &man.VOP.ISLOCKED.9; 原型，特别时去掉 struct thread 参数之后的 8.0-CURRENT。 800024 March 1, 2008 砍掉了 lockwaiters 和 BUF_LOCKWAITERS 函数， brelvp 的返回值从 void 修改成 int，并引入 &man.lockinit.9; 新标志之后的 8.0-CURRENT。 800025 March 8, 2008 为 &man.fcntl.2; 引入 F_DUP2FD 之后的 8.0-CURRENT。 800026 March 12, 2008 修改了 cv_broadcastpri 优先权参数之后的 8.0-CURRENT，比如 0 表示无优先权。 800027 March 24, 2008 修改了 bpf 监测 ABI, 加入了 zerocopy bpf buffer 之后的 8.0-CURRENT。 800028 March 26, 2008 为 flock 结构增加了 l_sysid 之后的 8.0-CURRENT。 800029 March 28, 2008 重新整合了 BUF_LOCKWAITERS 函数并加入 &man.lockmgr.waiters.9; 之后的 8.0-CURRENT。 800030 April 1, 2008 引入 &man.rw.try.rlock.9; 和 &man.rw.try.wlock.9; 之后的 8.0-CURRENT。 800031 April 6, 2008 引入 lockmgr_rw 和 lockmgr_args_rw 函数之后的 8.0-CURRENT。 800032 April 8, 2008 实现了 openat 和相关的系统调用，为 &man.open.2; 引入了 O_EXEC 标志，和提供了相应的 linux 兼容的系统调用之后的 8.0-CURRENT。 800033 April 8, 2008 为 &man.psm.4; 增加了原生的 &man.write.2; 支持之后的 8.0-CURRENT。 现在任意命令可写入 /dev/psm%d 并读出状态。 800034 April 10, 2008 引入 memrchr 函数之后的 8.0-CURRENT。 800035 April 16, 2008 引入 fdopendir 函数之后的 8.0-CURRENT 800036 April 20, 2008 无线部分转向 multi-bss (也叫做 vaps) 支持之后的 8.0-CURRENT。 800037 May 9, 2008 加入多路由表支持 (也就是 setfib(1)、 stfib(2)） 后的 8.0-CURRENT。 800038 May 26, 2008 删去了 netatm 和 ISDN4BSD 后的 8.0-CURRENT。 这个版本也表示增加了 Compact C Type (CTF) 工具。 800039 June 14, 2008 移除 sgtty 之后的 8.0-CURRENT。 800040 June 26, 2008 增加了内核级 NFS lockd 客户端的 8.0-CURRENT。 800041 July 22, 2008 增加了 arc4random_buf(3) 和 arc4random_uniform(3) 之后的 8.0-CURRENT。 800042 August 8, 2008 增加了 cpuctl(4) 之后的 8.0-CURRENT。 800043 August 13, 2008 修改 bpf(4) 使用单一的设备节点而不是克隆之后的 8.0-CURRENT。 800044 August 17, 2008 在提交了 vimage 项目第一步之后的 8.0-CURRENT。把全局变量重命名为虚拟化带 V_ 前缀并用宏映射到原来的全局名称。 800045 August 20, 2008 引入 MPSAFE TTY 层之后的 8.0-CURRENT， 包括对相关驱动和工具的修改。 800046 September 8, 2008 将 amd64 架构上 GDT 拆分到不同 CPU 之后的 8.0-CURRENT。 800047 September 10, 2008 删去了 VSVTX、 VSGID 和 VSUID 之后的 8.0-CURRENT。 800048 September 16, 2008 将内核中 NFS 挂接部分的代码改为能够通过 nmount() iovec， 而不再是大的 nfs_args 结构体作为参数之后的 8.0-CURRENT。 800049 September 17, 2008 删去了 &man.suser.9; 和 &man.suser.cred.9; 之后的 8.0-CURRENT。 800050 October 20, 2008 修改了缓冲存储器 API 之后的 8.0-CURRENT。 800051 October 23, 2008 删去了 &man.MALLOC.9; 和 &man.FREE.9; 宏之后的 8.0-CURRENT。 800052 October 28, 2008 引入了 accmode_t 和重新命名 VOP_ACCES 'a_mode' 为 a_accmode 之后的 8.0-CURRENT。 800053 November 2, 2008 修改了 &man.vfs.busy.9; 原型并引入了 MBF_NOWAIT 和 MBF_MNTLSTLOCK 标志之后的 8.0-CURRENT。 800054 November 22, 2008 增加了 buf_ring、 内存栅以及 ifnet 函数， 以方便撰写支持多硬件传输队列的驱动， 以及无锁环形缓冲实现的驱动程序， 并更高效地管理包队列功能之后的 8.0-CURRENT。 800055 November 27, 2008 引入了 &man.hwpmc.4; 对于 Intel™ Core，Core2 和 Atom 的支持之后的 8.0-CURRENT。 800056 November 29, 2008 引入了 multi-/no-IPv4/v6 jail 之后的 8.0-CURRENT。 800057 December 1, 2008 将 ath hal 改为使用源代码之后的 8.0-CURRENT。 800058 December 12, 2008 引入了 VOP_VPTOCNP 操作之后的 8.0-CURRENT。 800059 December 15, 2008 引入了新的 arp-v2 重写之后的 8.0-CURRENT。 800060 December 19, 2008 引入了 makefs 之后的 8.0-CURRENT。 800061 January 15, 2009 引入了 TCP Appropriate Byte Counting 之后的 8.0-CURRENT。 800062 January 28, 2009 删去了 minor()、 minor2unit()、 unit2minor() 等之后的 8.0-CURRENT。 800063 February 18, 2009 在 GENERIC 配置中改为使用 USB2 栈之后的 8.0-CURRENT； 这个数值同时也标志新增了 fdevname(3)。 800064 February 23, 2009 将 USB2 栈移动并替换 dev/usb 之后的 8.0-CURRENT。 800065 February 26, 2009 在对 libmp(3) 中所有函数更名之后的 8.0-CURRENT。 800066 February 27, 2009 更改了 USB devfs 管理和布局之后的 8.0-CURRENT。 800067 February 28, 2009 加入了 getdelim()， getline()， stpncpy()， strnlen()， wcsnlen()， wcscasecmp()， 和 wcsncasecmp() 之后的 8.0-CURRENT。 800068 March 2, 2009 在 usbhub devclass 更名为 uhub 之后的 8.0-CURRENT。 800069 March 9, 2009 重命名 libusb20.so.1 为 libusb.so.1 之后的 8.0-CURRENT。 800070 March 9, 2009 合并 IGMPv3 和 Source-Specific Multicast (SSM) 入 IPv4 栈之后的 8.0-CURRENT。 800071 March 14, 2009 为 gcc 打上了在 c99 和 gnu99 模式中使用 C99 inline 语义补丁之后的 8.0-CURRENT。 800072 March 15, 2009 移除了 IFF_NEEDSGIANT 标志; 不再支持非线程安全的网络设备驱动之后的 8.0-CURRENT。 800073 March 18, 2009 实现了 rpath 动态字符替换之后的 8.0-CURRENT. 800074 March 24, 2009 引入了 tcpdump 4.0.0 和 libpcap 1.0.0 之后的 8.0-CURRENT。 800075 April 6, 2009 修改了 structs vnet_net、 vnet_inet 和 vnet_ipfw 结构布局之后的 8.0-CURRENT。 800076 April 9, 2009 为 dummynet 新增了延迟评估工具之后的 8.0-CURRENT。 800077 April 14, 2009 删去了 VOP_LEASE() 和 vop_vector.vop_lease 之后的 8.0-CURRENT 800078 April 15, 2009 在 struct rt_metrics 和 struct rt_metrics_lite 中添加了 rt_weight 字段， 导致其结构发生变化之后的 8.0-CURRENT。 此后 RTM_VERSION 增加， 但又回退了。 800079 April 15, 2009 在 struct route 和 struct_in6 中添加了 struct llentry 指针之后的 8.0-CURRENT。 800080 April 15, 2009 改变了 struct inpcb 布局之后的 8.0-CURRENT。 800081 April 19, 2009 改变了 malloc_type 布局之后的 8.0-CURRENT。 800082 April 21, 2009 改变了 struct ifnet 布局， 并增加了 if_ref() 和 if_rele() 引用计数维护功能之后的 8.0-CURRENT。 800083 April 22, 2009 实现了底层蓝牙 HCI API 之后的 8.0-CURRENT。 800084 April 29, 2009 修改了 IPv6 SSM 和 MLDv2 之后的 8.0-CURRENT。 800085 April 30, 2009 启用了包括一个活跃映像的 VIMAGE 内核支持之后的 8.0-CURRENT。 800086 May 8, 2009 为 patch(1) 增加任意长输入行支持之后的 8.0-CURRENT。 800087 May 11, 2009 修改了一些 VFS KPI 之后的 8.0-CURRENT。 VFS 的 FSD 部分中删去了线程参数。 VFS_* 函数并不需要这些上下文信息， 因为它总是与 curthread 相关。 在某些特殊情况中， 则保留了原先的行为。 800088 May 20, 2009 对 net80211 监视模式进行调整之后的 8.0-CURRENT。 800089 May 23, 2009 增加了 UDP 控制块支持之后的 8.0-CURRENT。 800090 May 23, 2009 将网络接口克隆虚拟化之后的 8.0-CURRENT。 800091 May 27, 2009 增加了层次式 jail 并取消全局 securelevel 之后的 8.0-CURRENT。 800092 May 29, 2009 修改了 sx_init_flags() KPI 之后的 8.0-CURRENT。 SX_ADAPTIVESPIN 退役， 而新增的 SX_NOADAPTIVE 标志则表达相反语义。 800093 May 29, 2009 为 struct mount 增加 mnt_xflag 之后的 8.0-CURRENT。 800094 May 30, 2009 新增了 &man.VOP.ACCESSX.9; 之后的 8.0-CURRENT。 800095 May 30, 2009 调整轮询 KPI (polling KPI) 之后的 8.0-CURRENT。 轮询处理程序会返回处理过的包的数量。 新增的 IFCAP_POLLING_NOCOUNT 则表示返回值不重要， 并跳过计数。 800096 June 1, 2009 对新的 netisr 进行了改进， 并调整了保存和存取 FIB 方式之后的 8.0-CURRENT。 800097 June 8, 2009 引入了 vnet 析构挂钩和相关基础设施之后的 8.0-CURRENT。 800097 June 11, 2009 引入了 netgraph 输出到输入路径调用检测和排队机制， 并调整了 struct thread 布局之后的 8.0-CURRENT。 800098 June 14, 2009 引入了 OpenSSL 0.9.8k 之后的 8.0-CURRENT。 800099 June 22, 2009 更新了 NGROUPS 并将路由虚拟化挪到它自己的 VImage 模块之后的 8.0-CURRENT。 800100 June 24, 2009 修改了 SYSVIPC ABI 之后的 8.0-CURRENT。 800101 June 29, 2009 删去了与网络接口一一对应的 /dev/net/* 字符设备之后的 8.0-CURRENT。 800102 July 12, 2009 在 struct sackhint、 struct tcpcb 以及 struct tcpstat 上增加占位元素之后的 8.0-CURRENT。 800103 July 13, 2009 将 TOE 驱动接口中的 struct tcpopt 替换为 TCP syncache 中的 struct toeopt 之后的 8.0-CURRENT。 800104 July 14, 2009 新增了基于 linker-set 的 per-vnet 分配器之后的 8.0-CURRENT。 800105 July 19, 2009 递增了所有未使用符号版本的动态连接库版本之后的 8.0-CURRENT。 800106 July 24, 2009 引入 VM 对象类型 OBJT_SG 之后的 8.0-CURRENT。 800107 August 2, 2009 通过加入 newbus sxlock 使 newbus 子系统不再使用 Giant， 以及 8.0-RELEASE。 800108 November 21, 2009 实现了 EVFILT_USER kevent 过滤器之后的 8.0-STABLE。 800500 January 7, 2010 令 pkg_add -r 使用 packages-8-stable 的 __FreeBSD_version 版本变化的 8.0-STABLE。 800501 January 24, 2010 调整了 scandir(3) 和 alphasort(3) 函数原型， 使其符合 SUSv4 之后的 8.0-STABLE。 800502 January 31, 2010 新增了 sigpause(3) 之后的 8.0-STABLE。 800503 February 25, 2010 新增了用于管理网络接口说明的 SIOCGIFDESCR 和 SIOCSIFDESCR ioctl 之后的 8.0-STABLE。 这组接口受到了 OpenBSD 的启发。 800504 March 1, 2010 MFC 了 x86emu， 来自 OpenBSD 的 x86 CPU 实模式模拟器之后的 8.0-STABLE。 800505 May 18, 2010 MFC 了添加 liblzma, xz, xzdec 以及 lzmainfo 之后的 8.0-STABLE。 801000 June 14, 2010 8.1-RELEASE 801500 June 14, 2010 8.1-RELEASE 之后的 8.1-STABLE。 801501 November 3, 2010 用于 PL_FLAG_SCE/SCX/EXEC/SI 的 struct sysentvec 的 KBI 以及 用于 ptrace(PT_LWPINFO) 的 pl_siginfo 的 KBI 改变之后的 8.1-STABLE。 802000 December 22, 2010 8.2-RELEASE 802500 December 22, 2010 8.2-RELEASE 之后的 8.2-STABLE。 802501 February 28, 2011 合并了 DTrace 变动， 包含用户态跟踪支持之后的 8.2-STABLE。 802502 March 6, 2011 在 libm 中合并了 log2 和 log2f 之后的 8.2-STABLE。 802503 May 1, 2011 将 gcc 升级至 FSF gcc-4_2-branch 最后一个 GPLv2 版本之后的 8.2-STABLE。 802504 May 28, 2011 引入模块化拥塞控制支持基础设施和 KPI 之后的 8.2-STABLE。 802505 May 28, 2011 引入了 Hhook 和 Khelp KPI 之后的 8.2-STABLE。 802506 May 28, 2011 在 tcpcb 结构中增加 OSD 之后的 8.2-STABLE。 802507 June 6, 2011 引入 ZFS v28 之后的 8.2-STABLE。 802508 June 8, 2011 删去了 sv_schedtail struct sysvec 方法之后的 8.2-STABLE。 802509 July 14, 2011 在 binutils 中合并了 SSE3 支持之后的 8.2-STABLE。 802510 July 19, 2011 为 rfork(2) 添加了 RFTSIGZMB 标志之后的 8.2-STABLE。 900000 August 22, 2009 9.0-CURRENT。 900001 September 8, 2009 引入了 x86emu， 来自 OpenBSD 的 x86 CPU 实模式模拟器之后的 9.0-CURRENT。 900002 September 23, 2009 实现了 EVFILT_USER kevent 过滤器之后的 9.0-CURRENT。 900003 December 2, 2009 新增了 sigpause(3) 以及 csu 的 PIE 支持之后的 9.0-CURRENT。 900004 December 6, 2009 新增了 libulog 及其 libutempter 兼容接口之后的 9.0-CURRENT。 900005 December 12, 2009 新增了用于查询指定休眠队列上等待者数量的 sleepq_sleepcnt() 函数之后的 9.0-CURRENT。 900006 January 4, 2010 调整了 scandir(3) 和 alphasort(3) 函数原型， 使其符合 SUSv4 之后的 9.0-CURRENT。 900007 January 13, 2010 删去了 utmp(5) 并增加了 utmpx (参阅 getutxent(3)) 以改善用户登录日志和系统事件支持之后的 9.0-CURRENT。 900008 January 20, 2010 9.0-CURRENT 引入了 BSD 授权的 bc/dc 并将 GNU bc/dc 标注为过时之后的 9.0-CURRENT。 900009 January 26, 2010 新增了用于管理网络接口说明的 SIOCGIFDESCR 和 SIOCSIFDESCR ioctl 之后的 9.0-CURRENT。 这组接口受到了 OpenBSD 的启发。 900010 March 22, 2010 引入了 zlib 1.2.4 之后的 9.0-CURRENT。 900011 April 24, 2010 添加了 soft-updates 日志功能之后的 9.0-CURRENT。 900012 May 10, 2010 添加了 liblzma, xz, xzdec 以及 lzmainfo 之后的 9.0-CURRENT。 900013 May 24, 2010 添加了针对 linux(4) 的 USB 修正之后的 9.0-CURRENT。 900014 Jun 10, 2010 添加了 Clang 之后的 9.0-CURRENT。 900015 July 22, 2010 引入了 BSD grep 之后的 9.0-CURRENT。 900016 July 28, 2010 在 struct malloc_type_internal 中加入了 mti_zone 之后的 9.0-CURRENT。 900017 August 23, 2010 默认 grep 改回使用 GNU grep 并增加 WITH_BSD_GREP 开关之后的 9.0-CURRENT。 900018 August 24, 2010 将 pthread_kill(3) 产生的信号在 si_code 中改为使用 SI_LWP 标记之后的 9.0-CURRENT。 之前， si_code 对应的标志为 SI_USER。 900019 August 28, 2010 为 mmap(2) 新增了 MAP_PREFAULT_READ 标志之后的 9.0-CURRENT。 900020 September 9, 2010 为 sbuf 增加了 drain 功能并改变了 struct sbuf 布局之后的 9.0-CURRENT。 900021 September 13, 2010 DTrace 增加用户态跟踪支持之后的 9.0-CURRENT。 900022 October 2, 2010 新增了 BSDL man 工具， 并淘汰 GNU/GPL man 工具之后的 9.0-CURRENT。 900023 October 11, 2010 引入 20101010 git 快照版本 xz 之后的 9.0-CURRENT。 900024 November 11, 2010 将 libgcc.a 替换为 libcompiler_rt.a 之后的 9.0-CURRENT。 900025 November 12, 2010 引入了模块化拥塞控制之后的 9.0-CURRENT。 900026 November 30, 2010 引入串行管理协议 (SMP) 直通， 以及与之对应的 CAM CCB XPT_SMP_IO 和 XPT_GDEV_ADVINFO 之后的 9.0-CURRENT。 900027 December 5, 2010 在 libm 中增加 log2 之后的 9.0-CURRENT。 900028 December 21, 2010 添加了 Hhook (Helper Hook)、 Khelp (Kernel Helpers) 和 Object Specific Data (OSD) KPI 之后的 9.0-CURRENT。 900029 December 28, 2010 修改 TCP 协议栈使其允许 Khelp 模块通过 helper hook 指针， 与 TCP 控制块交互并保存连接数据之后的 9.0-CURRENT。 900030 January 12, 2011 将 libdialog 更新至版本 20100428 之后的 9.0-CURRENT。 900031 February 7, 2011 添加了 pthread_getthreadid_np(3) 之后的 9.0-CURRENT。 900032 February 8, 2011 删除了 uio_yield 函数原型和符号之后的 9.0-CURRENT。 900033 February 18, 2011 将 binutils 更新至 2.17.50 之后的 9.0-CURRENT。 900034 March 8, 2011 修改了 struct sysvec (sv_schedtail) 之后的 9.0-CURRENT。 900035 March 29, 2011 将基本系统中 gcc 和 libstdc++ 升级至最后的 GPLv2 授权版本之后的 9.0-CURRENT。 900036 April 18, 2011 在基本系统中删去了 libobjc 和 Objective-C 支持之后的 9.0-CURRENT。 900037 May 13, 2011 在基本系统中引入了 libprocstat(3) 函数库以及 fuser(1) 工具之后的 9.0-CURRENT。 900038 May 22, 2011 为 VFS_FHTOVP(9) 添加锁标志参数之后的 9.0-CURRENT。 900039 June 28, 2011 引入了来自 OpenBSD 4.5 的 pf 之后的 9.0-CURRENT。 900040 July 19, 2011 将 amd64 和 ia64 平台上的 MAXCPU 提高到 64， 并把 XLP (mips) 上的值提高到 128 之后的 9.0-CURRENT。 900041 August 13, 2011 实现了 Capsicum capabilities 之后的 9.0-CURRENT。 fget(9) 新增了权限参数。 900042 August 28, 2011 提高修改过 ABI 的动态连接库版本号之后的 9.0-CURRENT。 900043 September 2, 2011 增加了对不支持 SCSI 快取缓存同步功能的 USB 大容量存储设备自动检测功能之后的 9.0-CURRENT。 900044 September 10, 2011 重构了 auto-quirk 之后的 9.0-CURRENT。 900045 Oct 13, 2011 将非兼容性系统调用入口点全部增加 sys_ 前缀之后的 9.0-CURRENT。
请注意， 2.2.5-RELEASE 之后有一段时间的 2.2-STABLE 会声称自己是 2.2.5-STABLE。 这种模式的版本号表示的是年月。 但随后， 我们决定， 从 2.2 开始， 将它改为更为简洁的 主/次 版本号的形式来命名版本。 这是因为并行地在多个分支上进行开发， 使得通过实际的发布日期来区分不同的版本变得不再现实。 如果您正在做新的 port， 应该不需要担心较早的 -CURRENT； 在此列出仅供参考。 在 <filename>bsd.port.mk</filename> 之后写一些内容 不要在 .include <bsd.port.mk> 这行之后增加任何内容。 这通常可以通过在您的 Makefile 中间的某处引用 bsd.port.pre.mk， 并在结尾的地方引用 bsd.port.post.mk 来避免。 只能够采用 bsd.port.pre.mk/bsd.port.post.mk 或 bsd.port.mk 两种写法之一； 任何时候都不要同时使用两种写法。 bsd.port.pre.mk 只定义了很少的变量， 它们可以在 Makefile 中用于进行一些测试， 而 bsd.port.post.mk 则定义了所有其它的变量。 下面是一些由 bsd.port.pre.mk 定义的比较重要的变量 (这并不是一份完整的列表， 您可以阅读 bsd.port.mk 以获得全部变量的名字)。 变量 描述 ARCH 由 uname -m 输出得到的硬件架构的名字 (例如， i386) OPSYS 由 uname -s 返回的操作系统类型 (例如， FreeBSD) OSREL 操作系统的版本号 (例如 2.1.5 或 2.2.7) OSVERSION 操作系统的版本号的数值形式； 它等于 __FreeBSD_version。 PORTOBJFORMAT 系统默认的执行文件格式 (elf 或 aout； 请注意， 现代的 FreeBSD 版本中， aout 已在淘汰之列。) LOCALBASE local 目录的根 (例如， /usr/local/) PREFIX port 应被安装到哪里 (参见 关于 PREFIX 的更多说明)。 如果您需要定义 USE_IMAKE， USE_X_PREFIX， 或 MASTERDIR 这些变量， 则应在引用 bsd.port.pre.mk 之前完成。 下面是一些在引用 bsd.port.pre.mk 之后可以进行的判断： # 如果 perl5 已经在系统中提供， 则不必编译 lang/perl5 .if ${OSVERSION} > 300003 BROKEN= perl is in system .endif # ELF 只使用一个 shlib 版本 .if ${PORTOBJFORMAT} == "elf" TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR} .else TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR}.${SHLIB_MINOR} .endif # 软件会自动为 ELF 创建符号链接， 但 a.out 则需要另行创建 post-install: .if ${PORTOBJFORMAT} == "aout" ${LN} -sf liblinpack.so.1.0 ${PREFIX}/lib/liblinpack.so .endif 您还记得应该在 BROKEN= 和 TCL_LIB_FILE= 后面使用制表符， 而不是空格， 对吧？ :-) 在 wrapper 脚本中使用 <function>exec</function> 语句 如果 port 安装了用以启动其他程序的脚本， 并且运行其他程序是这些脚本的最后一项操作， 请务必使用 exec 语句来运行这些程序， 例如： #!/bin/sh exec %%LOCALBASE%%/bin/java -jar %%DATADIR%%/foo.jar "$@" 使用 exec 语句表示执行指定的程序来取代 shell 进程。 如果省略了 exec， 则 shell 进程会一直在内存中， 从而不必要地消耗了额外的系统资源。 理性行事 任何 Makefile 都应该简单并理性地行事。 如果您能让其中的条目更为简单和易读， 一定要这样做。 例如， 使用 make 提供的 .if 结构， 而不要使用 shell 的 if， 只要能重定义 EXTRACT* 就不要重载 do-extract， 尽量使用 GNU_CONFIGURE 而不是 CONFIGURE_ARGS += --prefix=${PREFIX}。 如果您在尝试做什么事情的时候发现不得不写大量的代码， 请回过头来复审一下 bsd.port.mk， 看看是否有您正打算做的事情的现成实现。 尽管读起来可能很费劲， 但有很多貌似很难的问题， 在 bsd.port.mk 中都给出了十分简便的解决方案。 遵循 <varname>CC</varname> 和 <varname>CXX</varname> 设置 port 应遵循 CC 和 CXX 变量的设置。 这也就是说， port 不应使用绝对的方式来设置这个变量的值， 而罔顾已经存在的设置； 与此相反， 它应该在其值后加入需要的其它值。 这样， 就可以设置全局的联编选项， 令其影响所有的 port 联编过程了。 如果实在无法这样做， 请在 Makefile 中加入 NO_PACKAGE=ignores cflags。 下面的 Makefile 实例给出了如何遵循 CC 和 CXX 变量的设置。 注意这里用到的 ?=： CC?= gcc CXX?= g++ 下面则是没有遵循 CC 和 CXX 的例子： CC= gcc CXX= g++ 在 FreeBSD 系统中， CC 和 CXX 这两个变量都可以在 /etc/make.conf 中自行定义。 第一个例子只有在 /etc/make.conf 中没有定义时才对这两个变量进行定义， 从而保持了系统范围的配置。 而第二个例子则会覆盖任何现有的配置。 遵循 <varname>CFLAGS</varname> 您的 port 应遵循 CFLAGS 变量的设置。 这也就是说， port 不应使用绝对的方式来设置这个变量的值， 而罔顾已经存在的设置； 与此相反， 它应该在其值后加入需要的其它值， 这样， 就可以设置全局的联编选项， 令其影响所有的 port 联编过程了。 如果实在无法这样做， 请在 Makefile 中加入 NO_PACKAGE=ignores cflags。 下面的 Makefile 例子， 可以帮助我们理解如何遵循 CFLAGS 的设置。 注意所用的 +=： CFLAGS+= -Wall -Werror 下面是一个未能遵循 CFLAGS 设置的例子： CFLAGS= -Wall -Werror 一般来说， CFLAGS 在 FreeBSD 系统中是在 /etc/make.conf 里配置的。 第一个例子在 CFLAGS 变量中增加了一些参数， 并保持了所有系统预定义的标志。 而第二个例子， 则会覆盖掉任何先前定义的参数。 您应从第三方软件的 Makefile 中去掉特殊的优化设置。 系统的 CFLAGS 给出了全系统范围内的优化设置参数。 下面是一个未经修改的 Makefile 实例： CFLAGS= -O3 -funroll-loops -DHAVE_SOUND 如果使用系统的优化参数， 则 Makefile 中的设置应该类似下面这样： CFLAGS+= -DHAVE_SOUND 线程库 在 &os; 上， 线程库必须通过特殊的连接器参数 -pthread 连接到可执行文件。 如果 port 一定要直接连接 -lpthread 或 -lc_r， 则应将其改为使用由 ports 框架提供的 PTHREAD_LIBS。 这个变量的值通常是 -pthread， 但在某些特定平台上的 &os; 版本中， 它可能是其它值， 因此， 不要将 -pthread 硬编码到您的补丁中， 而应使用 PTHREAD_LIBS 变量。 如果设置了 PTHREAD_LIBS， 而在联编时出现 unrecognized option '-pthread' 这样的错误， 可能需要通过将 CONFIGURE_ENV 设为 LD=${CC} 来使用 gcc 作为连接器。 -pthread 这一选项并不为 ld 所直接支持。 反馈 如果进行了一些很好的修改和补丁， 一定要把它们发回给原作者， 或维护者， 以便在下一版本的代码中包含它们。 这会让您在软件发布新版本的时候变得轻松一些。 <filename>README.html</filename> 不要包含 README.html 文件。 这个文件并非 CVS 代码库中的一部分， 它是由 make readme 命令生成的。 使用 <varname>BROKEN</varname>、 <varname>FORBIDDEN</varname> 或 <varname>IGNORE</varname> 阻止用户安装 port 某些时候会需要阻止用户安装某个 port。 想要告诉用户某个 port 不应被安装， 有许多可以在 port 的 Makefile 中使用的 make 变量。 下列 make 的值， 将是在用户试图安装时得到的提示信息。 务请使用正确的 make 变量， 因为每一个都表达了截然不同的意义， 而且许多自动化系统， 例如 port 联编集群、 FreshPorts， 以及 portsmon， 都依赖于 Makefile 的正确性。 变量 BROKEN 专门用于表达目前无法正确编译、 安装或卸载这类问题。 如果是临时性的问题， 则可以使用它。 如果进行了相关的配置， 则联编集群仍将尝试联编它， 以确认导致问题的深层问题是否已被解决。 (不过， 一般情况下， 联编集群并不会这样做。) 举例来说， 当 port 发生下述情况时， 应使用 BROKEN： 无法编译 (does not compile) 无法正确进行配置或安装操作 在 ${LOCALBASE} 以外的地方安装文件 卸载时无法删除所安装的全部文件 (不过， 留下用户改过的文件可接受的， 因为可能希望这样作) FORBIDDEN 用于表示 ports 中包含安全漏洞， 或者可能会给安装了这个 port 的 FreeBSD 系统带来严重的安全隐患 (例如： 一个很不安全的程序， 或包含了能够被轻易攻陷的服务的软件)。 如果发现了安全漏洞， 而其作者没有发布升级版本， 则应立即把那个 port 标记为 FORBIDDEN。 理想情况下， 包含安全漏洞的 port 应被尽快升级， 以便减少包含漏洞的 FreeBSD 主机的数量 (我们希望保持良好的安全记录)， 然而， 有时在安全漏洞的披露和软件更新之间可能会有一个间隔， 此时应予以说明。 除了安全之外， 请不要以任何其它理由将 port 标记为 FORBIDDEN。 IGNORE 用来表示 port 由于某些其它原因不应予以联编。 如果认为发生了结构性的问题， 则应使用它。 任何情况下， 联编集群都不会联编标记为 IGNORE 的 port。 以下是使用 IGNORE 的一些例子： 能够编译但无法正常运行 无法与运行的 &os; 版本一同工作 联编时需要 &os; 内核的源代码， 但用户没有安装它们 由于授权原因， 必须手工下载 distfile 无法与的某个已安装的 port 一同工作 (例如， port 依赖于 www/apache21 而安装的则是 www/apache13) 如果 port 与某个已经安装的 port 冲突 (例如， 它们在同一位置安装同名但功能不同的文件)， 则应 使用 CONFLICTS 来标记它。 CONFLICTS 将自动地设置 IGNORE。 如果 port 只应在某些平台上标记为 IGNORE， 还有另外两个方便使用的 IGNORE 变量可供选择： ONLY_FOR_ARCHS 和 NOT_FOR_ARCHS。 例如： ONLY_FOR_ARCHS= i386 amd64 NOT_FOR_ARCHS= alpha ia64 sparc64 可以使用 ONLY_FOR_ARCHS_REASON 和 NOT_FOR_ARCHS_REASON 来配置定制的 IGNORE 消息。 此外， 还可以使用 ONLY_FOR_ARCHS_REASON_ARCH 和 NOT_FOR_ARCHS_REASON_ARCH 来分别指定与具体平台有关的信息。 如果 port 会下载并安装用于 i386 的预编译二进制文件， 则应设置 IA32_BINARY_PORT。 如果设置了这个变量， 则系统会检查是否已经在 /usr/lib32 目录中安装了 IA32 版本的函数库， 以及内核是否提供了 IA32 兼容支持。 如果这些依赖条件不满足， 则会自动设置 IGNORE。 实现说明 这些字串不应使用引号括起来。 此外， 由于显示给用户的方式不同， 这些字串的措辞也应有所不同。 例如： BROKEN= this port is unsupported on FreeBSD 5.x IGNORE= is unsupported on FreeBSD 5.x 它们分别会在 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. 使用 <varname>DEPRECATED</varname> 或 <varname>EXPIRATION_DATE</varname> 表示某个 port 将被删除 一定要记得 BROKEN 和 FORBIDDEN 只应作为当某个 port 无法正常工作时的临时解决方案。 永久性地坏掉了的 port 应被从 ports tree 中完全删除。 需要时还可以使用 DEPRECATED 和 EXPIRATION_DATE 来通知用户某个 port 不应被使用， 并即将被删除。 前一个变量用来表达为什么计划删除 port； 而后一个是则是一个 ISO 8601 格式的日期 (YYYY-MM-DD)。 两者都会向用户呈现。 也可以设置 DEPRECATED 而不给出 EXPIRATION_DATE (例如， 建议使用某个新版本的 port)， 但反之则没有意义。 目前还没有确切的关于需要给出多少通知的政策。 当前的实践是， 对于与安全有关的问题为一个月， 而与联编有关的问题则为两个月。 这也让有兴趣的 committer 能够有一点时间来修正问题。 避免使用 <literal>.error</literal> 结构 在 Makefile 中给出信号， 表示由于某种外界因素 (例如， 用户指定了无效的联编选项) 而无法安装的方法是将变量 IGNORE 设为一非空值。 这个值将被格式化， 并在用户执行 make install 是给出提示。 用 .error 实现这一目的是一种常见的误用。 这样做的问题是， 许多在 ports 树上运行的自动化工具会因此而失败。 最常见的情况见于联编 /usr/ports/INDEX 的过程 (参见 )。 然而， 即使十分普通的命令， 例如 make maintainer， 在这种情况下也会失败。 这是不可接受的。 怎样避免使用 <literal>.error</literal> 考虑有人在 make.conf 中设置了 USE_POINTYHAT=yes 的情形。 接下来的例子中， 第一个 Makefile 中的问题将导致 make index 失败， 而第二个则不会： .if USE_POINTYHAT .error "POINTYHAT is not supported" .endif .if USE_POINTYHAT IGNORE=POINTYHAT is not supported .endif 对于 <filename>sysctl</filename> 的使用 除了在 target 中之外， 是不鼓励使用 sysctl 的。 这是因为计算 makevar， 例如在 make index 中所进行的那种， 都不得不运行一条命令， 这会使这一操作变得更慢。 在使用 &man.sysctl.8; 时， 务必通过 SYSCTL 变量来进行， 因为此变量将展开成命令的完整路径， 并且用户可以根据需要另行指定。 重新发布的 distfiles 有时， 一些软件的作者会修改业已发布的 distfile 的内容， 而并不修改文件名。 这种情况下， 您需要验证这些变动是来自软件作者的官方改动。 在过去， 曾经发生过下载服务器上的 distfile 被悄悄换成注入过恶意代码的版本， 并给用户安全造成威胁或损害的事情。 您应保留一份旧的 distfile， 并下载一份新的， 分别展开， 用 &man.diff.1; 来对比其内容。 如果没有发现可疑的变动， 就可以更新 distinfo 了。 请务必在您的 PR 或 commit log 中对这些差异进行描述， 以便让别人了解您已经仔细对比过差异， 并确认没有问题了。 除此之外， 也可以联系软件的作者， 以确认这些修改是否是他们做的。 杂记 需要仔细地反复检查 pkg-descr 和 pkg-plist 这两个文件。 如果您正在复审一个 port， 并认为这两个文件应该改进， 请一定要这样做。 请不要在系统中复制多份 GNU General Public License。 一定要非常小心地处理法律问题！ 不要让我们发布没有得到合法授权的软件！ 示范的 <filename>Makefile</filename> 这里是一个您可以在建立新 port 时参考的 Makefile。 请务必删除不需要的那些注释 (方括号中间的文字)！ 建议您按照下面这样的格式 (变量顺序， 小节之间的空行等) 来编写。 这个格式的作用是便于查找重要的信息。 我们建议您使用 portlint 来检查 Makefile。 [头部... 主要是让我们更容易地分辨不同的 port。] # New ports collection makefile for: xdvi [版本这行， 只有在 PORTVERSION 变量不足以描述 port 时才需要] # Date created: 26 May 1995 [这是最初将软件移植到 FreeBSD 上的日期， 一般来说是建立这份 Makefile 的日期。 请注意不要在之后再次修改这个日期。] # Whom: Satoshi Asami <asami@FreeBSD.org> # # $FreeBSD$ [ ^^^^^^^^^ 这是 CVS 在文件 commit 到我们的代码库时， 自动进行替换的 RCS ID。 如果您正在升级 port， 不要把它改回 "$FreeBSD$"。 CVS 会自动进行处理。] # [这个小节描述 port 本身以及主要下载站点 - PORTNAME 和 PORTVERSION 应放在最前面， 随后是 CATEGORIES， 然后是 MASTER_SITES， 接下来是 MASTER_SITE_SUBDIR。 如果需要的话， 接下来应指定 PKGNAMEPREFIX 和 PKGNAMESUFFIX。 随后是 DISTNAME， EXTRACT_SUFX， 以及 DISTFILES， EXTRACT_ONLY， 如果需要的话。] PORTNAME= xdvi PORTVERSION= 18.2 CATEGORIES= print [如果不想使用 MASTER_SITE_* 宏， 一定不要忘记结尾的斜线 ("/")！] MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications PKGNAMEPREFIX= ja- DISTNAME= xdvi-pl18 [如果源代码包不是标准的 ".tar.gz" 形式， 就需要设置这个] EXTRACT_SUFX= .tar.Z [分散的补丁 -- 可以为空] PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/ PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz [监护人(maintainer); *必须有*! 这是某个资源处理 port 更新、 联编失败， 以及回答用户直接提问或汇报 bug 的人。 为了保证 Ports Collection 有尽可能高的品质， 我们不再接受指定给 "ports@FreeBSD.org" 的新 port。] MAINTAINER= asami@FreeBSD.org COMMENT= A DVI Previewer for the X Window System [依赖的其它软件包 -- 可以为空] RUN_DEPENDS= gs:${PORTSDIR}/print/ghostscript LIB_DEPENDS= Xpm.5:${PORTSDIR}/graphics/xpm [这节是其它不适合上几节的标准 bsd.port.mk 变量] [如果需要在 configure、 build 或 install 过程中提问...] IS_INTERACTIVE= yes [如果解压缩到 ${DISTNAME} 以外的目录...] WRKSRC= ${WRKDIR}/xdvi-new [如果作者发布的补丁不是相对于 ${WRKSRC} 的， 可能需要调整这个] PATCH_DIST_STRIP= -p1 [如果需要运行由 GNU autoconf 生成的 "configure" 脚本] GNU_CONFIGURE= yes [如果需要使用 GNU make， 而不是 /usr/bin/make 来完成联编...] USE_GMAKE= yes [如果是一个 X 应用程序， 并使用 "xmkmf -a" 来运行...] USE_IMAKE= yes [et cetera.] [将在接下来的部分使用的非标准的变量] MY_FAVORITE_RESPONSE= "yeah, right" [接下来是特殊规则， 按调用顺序排列] 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 [结语] .include <bsd.port.mk> 保持同步 &os; 的 Ports Collection 在持续地进行修改。 这里提供了一些关于如何保持同步的信息。 FreshPorts 最简单的了解已经被 commit 到 ports 中的更新的方法， 是订阅 FreshPorts。 您可以选择多个 ports 并对其进行监视。 强烈建议维护人员订阅它， 这样就不仅能接收到他们自己所做的修改， 而且能看到其它 &os; committer 所做的改动。 (保持与所依赖的 ports 框架同步是必要的—虽然一般来说您会在这样的 commit 之前收到一个礼貌性的通知， 但有时可能会有人没有注意到需要这样做， 或者这样做很困难。 另外， 有些时候通知的修改也可能是微不足道的。 我们希望每一个人能够正确地进行判断。) 如果想使用 FreshPorts， 之需要建立一个账号。 如果您注册的邮件地址是 @FreeBSD.org， 您会看到 web 页面右侧的 opt-in 连接。 如果您已经注册了 FreshPorts 账号， 但没有使用 @FreeBSD.org 邮件地址， 则只需把邮件地址改为 @FreeBSD.org， 重新订阅， 并将其改回。 FreshPorts 也会对每一个 FreeBSD ports tree 上的 commit 进行自动的合法性检查。 如果您订阅了这项服务， 则如果发现了错误， 就会收到来自 FreshPorts 的检测报告。 代码库的 Web 访问界面 可以通过 web 界面来浏览源代码库中的文件。 影响整个 ports 系统的修改， 现在都会在 CHANGES 文件中说明。 影响某一个 port 的变动， 则在 UPDATING 文件中说明。 尽管如此， 所有问题最为权威的答案， 毫无疑问应该是 bsd.port.mk 的源代码， 以及相关的文件。 &os; Ports 邮件列表 如果您维护了某个或某一些 ports， 则应该考虑订阅 &a.ports;。 对于 ports 工作方式的重要修改都会在此宣示， 并提交到 CHANGES。 位于 <systemitem class="fqdomainname">pointyhat.FreeBSD.org</systemitem> 的 &os; Port 联编集群 &os; 的一个最不为人所知的强项是， 它拥有一个专用于持续联编 Ports Collection 的集群， 这个集群会联编所有主要的 OS 版本在每一个 Tier-1 架构上的 package。 您可以在 package 联编和错误日志 找到其结果。 每一个 port 都会被联编， 除非标记为 IGNORE。 标记了 BROKEN 的 port 仍然会被继续尝试， 以了解是否某些依赖关系的变动解决了其问题 (这是通过给 port 的 Makefile 传 TRYBROKEN 参数来完成的)。 &os; 的 Ports Distfile 扫描器 联编集群是一组专门用于联编所有 port 最新版本的机器， 其上已经下载了所有的 distfiles。 然而， 由于 Internet 在持续地发生变化， - distfile 可能很快就消失了。 FreeBSD + distfile 可能很快就消失了。 FreeBSD Ports distfile 扫描器 试图查询每一个 port 的所有下载站点， 以期找出这些文件是否依然存在。 维护者应规律性地检查这些报告， 这不仅会提高用户联编的速度， 同时也避免了浪费那些镜像了全部 distfile 的志愿者的带宽。 &os; 的 Ports 追踪系统 另一个非常方便的资源， 就是 FreeBSD Ports 追踪系统 (也被称作 portsmon)。 这个系统包含了一个处理若干信息来源的数据库， 并提供了一个可以通过 web 方式浏览的界面。 目前， 它利用到了和 ports 有关的问题报告 (PR)、 来自联编集群的错误日志， 以及来自 Ports Collection 的文件所提供的信息。 未来， 还会对它进行进一步的扩展， 从而提供包括 distfile 普查， 以及其它来源在内的更多信息。 要使用这个工具， 可以从查看关于某一个 port 的全部资料的 Port 的纵览 开始。 本文撰写时, 这是唯一一个能够将 GNATS PR 项， 同对应的 port 名字映射起来的资源。 (提交 PR 的用户， 有时并不在 Synopsis (概要) 中指明 port 的名字， 尽管我们希望他们这样做)。 因此， portsmon 在您想要查找是否有人提交某个现存的 port 的 PR， 以及它的联编是否出现了错误； 或在您创建新的 port 之前想要查找一下是否已经有人提交过时， 就非常有用了。