Der erste Teil des Makefile beschreibt die Versionsnummer des Ports und führt ihn in der richtigen Kategorie auf.
Setzen Sie bitte die Variable PORTNAME auf den Basisnamen Ihres Ports und die Variable PORTVERSION auf dessen Versionsnummer.
Die PORTREVISION-Variable ist ein streng monoton wachsender Wert, welcher auf 0 zurückgesetzt wird, nachdem PORTVERSION erhöht wurde (d.h. jedes Mal, wenn ein offizielles Release erfolgt). Sie wird an den Namen des Pakets angehängt, wenn sie ungleich 0 ist. Änderungen an PORTREVISION werden von automatisierten Werkzeugen (z.B. pkg_version(1)) genutzt, um anzuzeigen, dass ein neues Paket verfügbar ist.
PORTREVISION sollte jedes Mal erhöht werden, wenn eine Änderung am Port erfolgt, die beträchtliche Auswirkungen auf den Inhalt oder Struktur des aus dem Port erzeugten Pakets zur Folge hat.
Beispiele dafür, wann PORTREVISION erhöht werden sollte:
Hinzufügen von Patches, welche Sicherheitslücken schließen, Fehler beseitigen oder neue Funktionalität zum Port hinzufügen.
Änderungen am Makefile des Ports, welche compile-time-Optionen hinzufügen oder entfernen.
Änderungen bezüglich Packliste oder am Verhalten während der Installation des Pakets (d.h. Änderungen an einem Skript, welches Ausgangsdaten für das Paket erzeugt, wie z.B. SSH-Hostschlüssel).
Versionssprung einer Shared-Library, welche eine Abhängigkeit dieses Ports ist (In diesem Fall würde ein Anwender bei der Installation des alten Pakets scheitern, falls er eine neue Version der Abhängigkeit bereits installiert hat, weil nach der alten Bibliothek libfoo.x anstatt nach libfoo.(x+1)) gesucht wird).
Schleichende Änderungen am Distfile, welche bedeutende funktionale Änderungen verursachen, d.h. Änderungen des Distfile erfordern eine Korrektur an distinfo, ohne dass damit zusammenhängend die PORTVERSION verändert wird, obwohl ein diff -ru zwischen der alten und der neuen Version bedeutende Veränderungen am Code nachweist.
Beispiele für Änderungen, welche keine Erhöhung von PORTREVISION erfordern:
Stilistische Änderungen am Grundgerüst des Ports ohne funktionale Änderungen am daraus resultierenden Paket.
Änderungen an der Variable MASTER_SITES oder andere funktionale Änderungen, welche das resultierende Paket nicht verändern.
Marginale Patches am Distfile wie die Korrektur von Tippfehlern, welche nicht wichtig genug sind, um dem Benutzer die Bürde eines Upgrades aufzuerlegen.
Build fixes, die ein Paket erst kompilierbar machen, welches ohne diese Änderungen vorher nicht erzeugt werden konnte (solange die Änderungen keine funktionale Differenz bringen auf Plattformen, auf denen dieses Paket schon vorher gebaut werden konnte). Da PORTREVISION den Inhalt des Pakets wiederspiegelt, ist es nicht notwendig PORTREVISION zu erhöhen, wenn das Paket vorher nicht erstellt werden konnte.
Als Faustregel gilt: Stellen Sie sich die Frage, ob die durchgeführte Änderung am Port jedem hilft (entweder aufgrund einer Verbesserung, Beseitigung eines Fehlers, oder der Annahme, dass das neue Paket überhaupt erst funktioniert) und wägen Sie es gegen den Umstand ab, dass jedermann, der seine Ports-Sammlung regelmässig auf dem neuesten Stand hält, zu einer Aktualisierung gezwungen wird. Falls Sie die Frage positiv beantworten sollten, erhöhen Sie die Variable PORTREVISION.
Von Zeit zu Zeit geschieht es, dass irgendjemand (Drittanbieter von Software oder FreeBSD Ports Committer) etwas Dummes tut und eine Version einer Software veröffentlicht, deren Versionsnummer niedriger ist als die der vorherigen. Ein Beispiel hierfür ist ein Port, der von foo-20000801 auf foo-1.0 geändert wird (der Erstere wird fälschlicherweise als neue Version behandelt, weil 2000801 ein numerisch größerer Wert ist als 1).
In Situationen wie diesen sollte die Variable PORTEPOCH erhöht werden. Wenn PORTEPOCH größer als 0 ist, wird sie an den Namen des Pakets angehängt, wie in Abschnitt 0 oberhalb bereits beschrieben. PORTEPOCH darf niemals verringert oder auf 0 gesetzt werden, weil der Vergleich des Pakets mit einem früheren Zeitpunkt scheitern würde (d.h. das Paket würde niemals als veraltet erkannt werden): Die neue Versionsnummer (1.0,1 im obigen Beispiel) ist immer noch numerisch kleiner als die vorherige Version (2000801), aber das Suffix ,1 wird von automatisierten Werkzeugen gesondert behandelt und wird als größer erkannt, als das implizit angenommene Suffix ,0 im früheren Paket.
Das Entfernen oder Zurücksetzen von PORTEPOCH führt zu unendlichem Ärger. Wenn Sie die obigen Ausführungen nicht vollständig verstanden haben, lesen Sie es bitte unbedingt nochmals bis Sie es vollständig verinnerlicht haben, oder fragen Sie vor jeder Änderung auf den Mailinglisten nach!
Es wird erwartet, dass PORTEPOCH für die weitaus überwiegende Zahl der Ports nicht verwendet wird und der verantwortungsvolle und vorausschauende Umgang mit PORTVERSION macht es meist überflüssig, falls ein späteres Release die Versionsstruktur ändern sollte. Vorsicht ist geboten, wenn ein Release einer Drittanbieter-Software ohne eine offizielle Versionsnummer veröffentlicht wird, wie z.B. bei ``Snapshot-Versionen''. Man ist versucht, das Release mit dem jeweiligen Datum zu bezeichnen, was unweigerlich zu den oben beschriebenen Problemen führt, wenn das nächste ``offizielle'' Release erscheint.
Wenn z.B. ein Snapshot zum Datum 20000917 veröffentlicht wird und die vorherige Version der Software war 1.2, dann sollte der Snapshot die PORTVERSION 1.2.20000917 oder ähnlich erhalten und nicht 20000917, damit das nachfolgende Release, angenommen 1.3, immer noch einen größeren numerischen Wert aufweist.
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 erhöht.
PORTNAME= gtkmumble PORTVERSION= 0.10 PORTREVISION= 1
PKGNAME wird zu gtkmumble-0.10_1
Eine neue Version wird vom Software-Drittanbieter veröffentlicht, bezeichnet mit der Version 0.2 (es stellt sich heraus, dass der Autor beabsichtigte, dass 0.10 eigentlich 0.1.0 bedeuten sollte, nicht ``was kommt nach 0.9'' – Hoppla, aber nun ist es zu spät). Da die neue Unterversion 2 numerisch kleiner ist als die vorherige Version 10, muss PORTEPOCH erhöht werden, um sicherzustellen, dass das neue Paket auch als ``neuer'' erkannt wird. Da es ein neues Release des Drittanbieters ist, wird PORTREVISION auf 0 zurückgesetzt (oder aus dem Makefile entfernt).
PORTNAME= gtkmumble PORTVERSION= 0.2 PORTEPOCH= 1
PKGNAME wird zu gtkmumble-0.2,1
Das nächste Release ist 0.3. Da PORTEPOCH niemals verringert wird, sind die Versionsvariablen nun wie folgt:
PORTNAME= gtkmumble PORTVERSION= 0.3 PORTEPOCH= 1
PKGNAME wird zu gtkmumble-0.3,1
Anmerkung: Falls PORTEPOCH mit diesem Upgrade auf 0 zurückgesetzt worden wäre, dann würde jemand, der das Paket gtkmumble-0.10_1 installiert hätte, das Paket gtkmumble-0.3 nicht als neuer erkennen, da 3 immer noch numerisch kleiner ist als 10. Bedenken Sie, dass genau dies der springende Punkt an PORTEPOCH ist.
Zwei optionale Variablen, PKGNAMEPREFIX und PKGNAMESUFFIX, werden verknüpft mit PORTNAME und PORTVERSION, um PKGNAME zu bilden als ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION} . Stellen Sie bitte unbedingt sicher, dass diese Variablen den Richtlinien für einen guten Paketnamen entsprechen. Insbesondere dürfen Sie keinesfalls einen Bindestrich (-) in PORTVERSION verwenden. Falls das Paket den language- oder -compiled.specifics-Teil aufweist (siehe unten) benutzen Sie PKGNAMEPREFIX oder PKGNAMESUFFIX respektive. Machen Sie diese Variablen nicht zum Bestandteil von PORTNAME!
Die Umgebungsvariable LATEST_LINK wird während der Paketerstellung verwendet, um einen Kurznamen festzulegen, der danach von pkg_add -r genutzt werden kann. Dadurch wird es beispielsweise möglich, die aktuelle Perl-Version durch einen einfachen Aufruf von pkg_add -r perl zu installieren (ohne die Angabe der korrekten Versionsnummer). Dieser Name muss eindeutig sowie ``offensichtlich'' sein.
In einigen Fällen können mehrere Versionen einer Applikation gleichzeitig in der Ports-Sammlung sein. Das index build- und das package build-System müssen nun in der Lage sein, diese als unterschiedliche Ports zu erkennen, obwohl diese Versionen alle die gleichen Variablen PORTNAME, PKGNAMEPREFIX und sogar PKGNAMESUFFIX aufweisen. In solchen Fällen sollte die optionale Variable LATEST_LINK auf einen unterschiedlichen Wert für alle Ports gesetzt werden mit Ausnahme des ``Haupt-Ports''. Beispiele hierfür sind die lang/gcc46 und lang/gcc-Ports und die www/apache*-Familie. Wenn Sie die Umgebungsvariable NO_LATEST_LINK setzen, wird kein Link erzeugt, was für alle Versionen (aber nicht für die ``Hauptversion'') nützlich sein kann. Beachten Sie bitte, dass die Frage der Auswahl der ``wichtigsten'' Version (``am populärsten'', ``am besten Unterstützt'', ``zuletzt gepatcht'' usw.) ausserhalb der Möglichkeiten dieses Handbuches liegt. Wir sagen Ihnen nur, wie Sie die anderen Ports spezifizieren, nachdem Sie den ``Haupt-Port'' erkoren haben.
Im Folgenden finden Sie die Regeln für die Benennung Ihrer Pakete. Diese sollen gewährleisten, dass das Paketverzeichnis leicht zu durchsuchen ist, da es bereits abertausende Pakete gibt und die Nutzer sich mit Schauder abwenden, wenn Ihre Augen überstrapaziert werden!
Der Paketname soll aussehen wie [language[_region]]-name[[-]compiled.specifics]-version.numbers.
Der Paketname ist definiert als ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION} . Stellen Sie bitte sicher, dass die Variablen Ihres Ports diesem Format entsprechen.
FreeBSD bemüht sich ausserordentlich, die Landessprachen seiner Nutzer zu unterstützen. Die language-Variable soll eine Abkürzung mit 2 Buchstaben sein der Sprachen gemäß ISO-639, falls der Port für eine bestimmte Sprache spezifisch ist. Beispiele hierfür sind ja für Japanisch, ru für Russisch, vi für Vietnamesisch, zh für Chinesisch, ko für Koreanisch und de für Deutsch.
Sollte der Port spezifisch sein für eine gewisse Region innerhalb eines Sprachraumes, dann fügen Sie bitte auch den Ländercode mit 2 Buchstaben hinzu. Beispiele sind en_US für nordamerikanisches Englisch und fr_CH für schweizerisches Französisch.
Der language-Teil muss in der PKGNAMEPREFIX-Variable gesetzt werden.
Der erste Buchstabe des name-Teils muss kleingeschrieben werden (der Rest des Namens kann Großbuchstaben enthalten. Daher seien Sie bitte umsichtig, wenn Sie den Namen einer Software konvertieren, welche Grossbuchstaben enthält). Es ist Tradition, Perl 5-Module durch ein vorstehendes p5- und durch Umwandlung des doppelten Doppelpunktes in Bindestriche zu bezeichnen. So wird z.B. aus dem Data::Dumper-Modul der p5-Data-Dumper-Port.
Vergewissern Sie sich, dass der Name des Ports und seine Versionsnummer klar getrennt sind und in den Variablen PORTNAME und PORTVERSION stehen. Der einzige Grund, um in PORTNAME einen Versionsteil aufzunehmen ist der, dass die Software wirklich so bezeichnet wird, wie z.B. die Ports 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 Indexeinträge) 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 hierfür sind Papiergrößen und Font-Einheiten.
Der -compiled.specifics-Teil muss in der Variablen PKGNAMESUFFIX gesetzt werden.
Die Versionszeichenfolge sollte einen Bindestrich (-) am Schluss haben und eine von Punkten getrennte Liste von Integer-Zahlen und kleingeschriebenen Buchstaben sein. Es ist nicht zulässig, einen weiteren Bindestrich innerhalb des Versionsstrings zu verwenden! Die einzige Ausnahme hiervon ist die Zeichenfolge pl (bedeutet ``patchlevel''), welche nur dann gebraucht werden darf, wenn die Applikation über keine Haupt– oder Unterversionsnummern verfügt. Wenn die Versionsbezeichnung der Software Zeichenketten wie ``alpha'', ``beta'', ``rc'' oder ``pre'' enthält, dann nehmen Sie bitte den ersten Buchstaben daraus und setzen ihn unmittelbar hinter einen Punkt. Falls die Versionszeichenfolge nach diesem Punkt fortgesetzt wird, sollen die Zahlen ohne einen Punkt zwischen den einzelnen Buchstaben folgen.
Das Ziel ist es, die Ports anhand der Versionszeichenfolge zu sortieren. Stellen Sie bitte unbedingt sicher, dass die Bestandteile der Versionsnummer immer durch einen Punkt getrennt sind und falls Datumsangaben verwendet werden, dass diese im Format 0.0.yyyy.mm.dd und nicht dd.mm.yyyy oder gar dem nicht Y2K-kompatiblen Format yy.mm.dd vorliegen. Es ist wichtig, dass die Versionsnummer mit 0.0. beginnt, da die Versionsnummer im Falle einer Veröffentlichung auf jeden Fall kleiner als yyyy sein wird.
Hier sind einige reale Beispiele, die aufzeigen, wie man den Namen einer Applikation zu einem vernünftigen Paketnamen umwandelt:
| Softwarename | PKGNAMEPREFIX | PORTNAME | PKGNAMESUFFIX | PORTVERSION | Grund |
|---|---|---|---|---|---|
| mule-2.2.2 | (leer) | mule | (leer) | 2.2.2 | Keine Änderung erforderlich |
| EmiClock-1.0.2 | (leer) | emiclock | (leer) | 1.0.2 | keine Großbuchstaben für einzelne Applikationen |
| rdist-1.3alpha | (leer) | rdist | (leer) | 1.3.a | Keine Zeichenketten wie alpha erlaubt |
| es-0.9-beta1 | (leer) | es | (leer) | 0.9.b1 | keine Zeichenketten wie beta erlaubt |
| mailman-2.0rc3 | (leer) | mailman | (leer) | 2.0.r3 | keine Zeichenketten wie rc erlaubt |
| v3.3beta021.src | (leer) | tiff | (leer) | 3.3 | Was sollte denn das eigentlich sein? |
| tvtwm | (leer) | tvtwm | (leer) | pl11 | Versionsstring zwingend erforderlich |
| piewm | (leer) | piewm | (leer) | 1.0 | Versionsstring zwingend erforderlich |
| xvgr-2.10pl1 | (leer) | xvgr | (leer) | 2.10.1 | pl nur erlaubt, wenn keine Versionsnummer vorhanden |
| gawk-2.15.6 | ja- | gawk | (leer) | 2.15.6 | Japanische Sprachversion |
| psutils-1.13 | (leer) | psutils | -letter | 1.13 | Papergröße beim Paketbau fix kodiert |
| pkfonts | (leer) | pkfonts | 300 | 1.0 | Paket für 300 DPI Schriftarten |
Falls es in der Originalquelle überhaupt keinen Anhaltspunkt für irgendeine Versionsbezeichnung gibt und es unwahrscheinlich ist, dass der Autor jemals eine neue Version veröffentlichen wird, dann setzen Sie bitte die Version einfach auf 1.0 (wie im obigen Beispiel piewm). Sie können auch den Autor fragen oder eine Datumszeichenfolge in der Art 0.0.yyyy.mm.dd als Version verwenden.
| Zurück | Zum Anfang | Weiter |
| Die Konfiguration des Makefile | Nach oben | Kategorisierung |