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
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.
Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an
<de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an
<de-bsd-translators@de.FreeBSD.org>.