Ein Fink-Paket erstellen

Der name des Pakets

Der Name des Elternpakets (der selbe wie %n außer innerhalb eines SplitOff)

Anmerkung: Wenn ein Eltern-Paket-Feld %type_*[] enthält, dann werden die Werte der Prozent-Erweiterung in %N in einem SplitOff-Block mit eingeschlossen. (Schließlich sind sie Teil von %n bei den Eltern.)

Die epoche des Pakets

Die version des Pakets. Beachten sie, dass die Epoche nicht zu %v gehört.

Die vollständige Version des Pakets, die automatisch die Epoche enthält, wenn vorhanden. Beachten sie, dass diese Prozent-Erweiterung nur für Pakete zur Verfügung steht, deren InfoN-Ebene mindestens 4 ist.

Die revision des Pakets

Der vollständige (full) Paketname (%n-%v-%r). Beachten sie, dass die Epoche nicht zu %f gehört.

Der prefix wo Fink installiert ist, also /opt/sw. Sie dürfen nicht annehmen, dass alle Nutzer Fink in /opt/sw installiert haben, nutzen sie immer %p für den korrekten Pfad.

Im Verzeichnis destination wird der Baum für ein Paket erstellt, z. B. in /opt/sw/src/fink.build/root-gimp-1.2.1-1. Dieses temporäre Verzeichnis dient als Wurzelverzeichnis während der Installationsphase beim Compilieren eines Pakets. Sie sollten nicht annehmen, dass root-%f in %p/src ist, denn ein Nutzer kann dieses Verzeichnis mit dem Feld Buildpath in der Datei /opt/sw/etc/fink.conf ändern.

Das Verzeichnis Destination für das Elternpaket (das selbe wie %d außer innerhalb eines SplitOff)

Der vollständige installationsphase-Präfix, äquivalent zu %d%p

Der Install-Präfix des Elternpakets, äquivalent zu %D%P (das selbe wie %i außer innerhalb eines SplitOff)

Der Pfad, wo sich die Patches befinden. Ab Fink-0.29.0 sollte diese Variable nicht mehr benutzt werden. Nutzen sie %{PatchFile}, um auf die .patch-Datei zuzugreifen. Die Unterstützung für %a wird in der Zukunft entfernt werden.

Das Verzeichnis build, also /opt/sw/src/fink.build/gimp-1.2.1-1/gimp-1.2.1. Sie sollten nicht annehmen, dass sich %f in %p/src befindent, denn ein Nutzer kann dieses Verzeichnis über das Feld Buildpath in der Datei /opt/sw/etc/fink.conf ändern. Das innerste Verzeichnis wird nach dem Dateinamen der Quelle benannt oder dem Wert des Felds SourceDirectory (falls vorhanden) oder wird nicht verwendet wenn das Feld NoSourceDirectory auf true gesetzt ist.

Anmerkung: Nutzen sie dies nur, wenn es gar nicht anders geht. Das Verzeichnis build ist das aktuelle Verzeichnis, wenn Skripte ausgeführt werden; sie sollten in Kommandos relative Pfadnamen verwenden.

Die configure Parameter: --prefix=%p plus alles, was mit ConfigureParams angegeben wurde. (Das Verhalten ist anders, wenn das Paket das Feld Type: perl gesetzt hat. In diesem Fall werden die Voreinstellungen für das Erstellen von Perl-Paketen anstatt von --prefix=%p in der Definition von %c verwendet.)

Die Zeichenfolge für die Architektur der machine. Dies ist nicht länger durch den Typ der Maschine bestimmt, sondern eine Wahl des Nutzers bei der Installation zwischen den Architekturen, die auf der Hardware des Nutzers laufen können. Mögliche Werte sind 'powerpc' für PowerPC-Macs und 'i386' oder 'x86_64' für Intel-Macs. Die Auswahl 'x86_64' steht auf Intel-Macs nur zur Verfügung, wenn der Mac 64-bit Bibliotheken und Programme ausführen kann. (Dieser Werf wurde etwa in Fink-0.12 eingeführt, die aktuellen Beschreibung gilt für Fink-0.29.5 und später.)

Das Zeichen Prozent (Ein Zeichen, das nicht erweitert wird, was auch immer danach folgt). Die Erweiterung erfolgt streng von links nach rechts. Damit hat %%n nichts mit dem Paketnamen zu tun, sondern bedeutet die Zeichenfolge %n. (In Fink-0.18.0 eingeführt)

pseudo-hashes, die den Subtyp für den angegebenen type zurückgeben. Lesen sie die Dokumentation für das Feld Type weiter unten in diesem Dokument. Die Form _raw ist die exakte Zeichenfolge des Subtyps, während bei der Form _pkg alle Punkte entfernt wurden (entsprechend Finks Konventionen für Paketnamen mit Sprachversionen und andere kluge Verwendungen). (Eingeführt in einer post-0.19.2 CVS-Version von Fink.) Die Form -num wurde in Fink-0.26.0 eingeführt und entfernt alle Zeichen außer Zahlen aus dem Feld Type.

Beachten sie, dass (%type_pkg[type]) direkt als Bedingung verwendet werden kann, wenn das Feld Type den type als "Boolean" deklariert. (Der boolesche Wert ist wahr oder falsch, je nachdem wie der Subtype ausgerechnet wird.)

Der invariante Teil des Paketnamens. Sie sind wie %n and %N, außer dass alle Teile von %type_pkg[] und %type_raw[] gelöscht sind. (Eingeführt in einer post-0.19.2 CVS-Version von Fink) Sie sollten %{ni} und %{Ni} verwenden, um Verwechslungen mit den Erweiterungen %n und %N zu verhindern.

Nur in den Feldern PatchScript, CompileScript und InstallScript gültig. Es enthält den voreingestellten Inhalt dieser Felder. Der Wert hängt oft vom Feld Type ab und ist immer definiert (Er kann aber leer sein). Wird diese Erweiterung im InstallScript eines SplitOff (oder SplitOffN) verwendet, gibt sie die Voreinstellung der Eltern zurück, selbst wenn die Voreinstellung für das InstallScript in einem SplitOff-Paket leer ist. (Eingeführt in Fink-0.20.6)

Der vollständige Pfad zu der Datei, die im Feld PatchFile angegeben ist. (Eingeführt in Fink-0.24.12)

Der vollständige Pfad zu der Datei, die im Feld PatchFileN angegeben ist. (Eingeführt in Fink-0.30.0)

Ist der Type: -64bit als -64bit definiert, wird dies unter der PowerPC-Architektur zu lib/ppc64 erweitert und zu lib/x86_64 unter der i386-Architektur (Der korrekte Speicherort für 64-bit Bibliotheken auf einem 32-bit System); anderfalls wird es zu lib erweitert. (Eingeführt in Fink-0.26.0)

Beachten sie, dass %lib im Feld ConfigureParams nicht erlaubt ist, außer wenn die InfoN-Ebene mindestens 4 ist.

Dynamische Bibliotheken

Header-Dateien

Binärprogramme, usw.

Dynamische Bibliotheken

Header-Dateien

Binärprogramme, usw.

Dieses Verzeichnis ist für allgemeine ausführbare Programme. Es hat keine weiteren Unterverzeichnisse.

Dieses Verzeichnis ist für Programme, die nur von Administratoren ausgeführt werden. Daemon-Programme, die im Hintergrund laufen, gehören hier her. Es hat keine weiteren Unterverzeichnisse.

Dieses Verzeichnis ist für C und C++ Header-Dateien. Unterverzeichnisse können je nach Bedarf angelegt werden. Installiert ein Paket Header-Dateien, die mit Standard C Header-Dateien verwechselt werden könnten, müssen diese Header-Dateien in ein Unterverzeichnis.

Dieses Verzeichnis ist für Daten-Dateien und Bibliotheken, die von der Architektur abhängen. Statische und dynamische Bibliotheken gehören direkt in /opt/sw/lib, außer es gibt sehr gute Gründe. Ebenso gehören Programme hierher, die nicht direkt vom Nutzer ausgeführt werden (üblicherweise befinden sich solche Programme in libexec).

Ein Paket darf Unterverzeichnisse für private Daten oder ladbare Module anlegen. Achten sie darauf, dass die Namen der Unterverzeichnisse sinnvoll sind und der Kompatibilität dienen. Es ist durchaus sinnvoll, den Namen des Verzeichnisses umd die Hauptversion des Pakets zu erweitern oder zusätzliche Unterverzeichnisse einzufügen, z. B. /opt/sw/lib/perl5 oder /opt/sw/lib/apache/1.3. Aufpassen muss man, wenn der Typ des Rechners im Namen verwendet wird. Ein Verzeichnis mit dem Namen powerpc-apple-darwin1.3.3 kann leicht zu Kompatibilitätsproblemen führen, die sich durch powerpc-apple-darwin1.3 oder powerpc-apple-darwin leicht vermeiden lassen.

Dieses Verzeichnis ist für 64-bit-Bibliotheken auf 32-bit-Systemen, mit /opt/sw/lib/ppc64 für die PowerPC-Architektur und /opt/sw/lib/x86_64 für die i386-Architektur. Bibliotheken, die als "fat" erzeugt wurden, sollten aber in /opt/sw/lib abgespeichert werden und ein '32-64' in ihrem Feld Shlibs eingetragen haben. Beachten sie, dass unter der x86_64-Architektur 64-bit-Bibliotheken in /opt/sw/lib werden.

Dieses Verzeichnis ist für architektur-unabhängige Daten-Dateien. Es gelten die selben Regeln wie für /opt/sw/lib. Einige Unterverzeichnisse werden im folgenden beschrieben.

Dieses Verzeichnis enthält Dokumentationen als man-Pages. Es ist weiter in die üblichen Abschnitte unterteilt. Zu jedem Programm in /opt/sw/bin und /opt/sw/sbin sollte es hier eine entsprechende man-Page geben.

Dieses Verzeichnis enthält Dokumentationen im Info format (erstellt aus Texinfo Quellen). Die Pflege der Datei dir ist automatisiert und erfolgt mit Debians Version von install-info (Teil des Pakets dpkg). Verwenden sie das Feld InfoDocs, um entsprechenden Code für die Skripte postinst und prerm automatisch zu erzeugen. Fink kümmert sich darum, dass kein Paket eine eigene Datei dir erzeugt. Es gibt keine Unterverzeichnisse.

Dieses Verzeichnis enthält Dokumentationen, die weder als man-Page noch als Info-Dokument vorliegen. Die Dateien README, LICENSE und COPYING gehören z. B. hier her. Jedes Paket muss hier sein eigenes Unterverzeichnis anlegen, das wie das Paket benannt wird. Die Namen der Unterverzeichnisse dürfen keine Versionsnummern enthalten, außer wenn diese Nummern Teil des tatsächlichen Paketnamens sind. Tipp: Verwenden sie einfach %n.

Dieses Verzeichnis enthält Kataloge mit Meldungen für die Internationalisierung.

In Verzeichnis opt werden "add-on" Programmpakete abgespeichert, die aus irgendeinem Grund nicht die Standard-Verzeichnisse /opt/sw/bin, /opt/sw/lib, /opt/sw/include, usw. nicht verwenden können. Ein Paket, das in /opt/sw/opt installiert wird, muss seine statischen Dateien in einem separaten Unterverzeichnis /opt/sw/opt/<package> abspeichern, wobei <package> ein Name ist, der das Programmpaket beschreibt. (Verfügbar ab Fink 0.29.7 oder später.)

Im Verzeichnis var werden veränderliche Daten gespeichert. Das umfasst Spool-Verzeichnisse, Lock-Dateien, Status-Datenbanken, Punktestände von Spielen und Log-Dateien.

Diese Verzeichnis enthält Konfigurationsdateien. Gehören zu einem Paket mehr als ein oder zwei Dateien, sollte ein Unterverzeichnis angelegt werden. Der Name des Unterverzeichnis muss den Namen des Pakets oder Programms enthalten, damit es zugeordnet werden kann.

In diesem Verzeichnis werden die Quell-Dateien gespeichert und erfolgt die Codeerstellung. Vom den Paketen sollte hier nicht weiter installiert werden.

In diesem Verzeichnis werden Programm mit einer graphischen Oberfläche im Stil von OS X abgespeichert, die man normalerweise mit einem Doppelklick startet und nicht von der Kommandozeile.

In diesem Verzeichnis werden Frameworks im OS X-Stil abgespeichert. Sie werden manchmal von Programmen im OS X-Stil genutzt.

Der Paketname. Er kann Kleinbuchstaben, Zahlen und die Sonderzeichen '.', '+' und '-' enthalten, aber keine Unterstriche ('_') oder Grossbuchstaben. Ein Pflichtfeld.

Eine Prozenterweiterung wird in diesem Feld nur für %N, %{Ni}, %type_raw[], und %type_pkg[] vorgenommen.

Gemäß den Richtlinien für Finkpakete, muss ein Paket immer mit den gleichen Optionen übersetzt werden. Bei verschiedenen Varianten eines Pakets (siehe die Dokumentation zum Feld Type) muss man die jeweilige Variante in das Feld Package einpflegen (siehe die Dokumentation für die Prozenterweiterung %type_pkg[]). Auf diese Weise erhält jede Variante einen eindeutigen Namen und die Namen zeigen, welche Varianten zur Verfügung stehen. Beachten sie, dass die Prozenterweiterung %type_pkg[] und %type_raw[] relativ neu sind und total inkompatibel mit älteren Versionen von Fink. Deshalb müssen solche Paketbeschreibungen in ein Feld InfoN mit N ≥ 2 eingebettet werden.

Die upstream-Versionsnummer. Es gelten die gleichen Einschränkungen wie für das Feld Package Ein Pflichtfeld.

Beachten sie, dass einige Programm seltsame Schemen für ihre Versionsnummern verwenden, die die Sortierung durcheinander bringen oder Zeichen enthalten, die nicht erlaubt sind. In diesen Fällen muss sie den upstream-Wert so umwandeln, dass er nur erlaubte Zeichen enthält und eine korrekte Sortierung ermöglicht. Wenn sie sich über die Sortierung von Zeichenketten nicht sicher sind, können sie das Kommando dpkg für einen Test verwenden. Im folgenden Beispiel

  dpkg --compare-versions 1.2.1 lt 1.3 && echo "true"

wird "true" ausgegeben, weil die Zeichenkette "1.2.1" vor "1.3" kommt. Mehr Details gibt es auf der man-Page von dpkg.

Die Revision des Pakets. Erhöhen sie diese Zahl, wenn sie eine neue Paketbeschreibung für dieselbe upstream-Version erstellen. Revisionsnummern beginnen mit 1. Ein Pflichtfeld.

Finks Richtlinien verlangen, dass die Revisionsnummer jedes Mal erhöht werden muss, wenn Änderungen in der Datei .info Änderungen in der binären (kompilierten) Form des Pakets (die Datei .deb) zur Folge haben. Beispiele sind Änderungen im Feld Depends oder in anderen Paketlisten, Hinzufügen, Entfernen oder Umbenennen von SplitOff-Paketen oder Dateien zwischen diesen hin und her schieben. Erfordert die Migration eines Paket in einen neuen Baum (z. B. von 10.2 nach 10.3) solche Änderungen, sollten sie die Revision um 10 oder mehr im neuen Baum erhöhen, damit noch Platz für Änderungen im alten Baum bleibt.

Dies ist Komma-separierte Liste der Architekturen, für die das Paket (und jedes SplitOff-Paket in der Beschreibung) vorgesehen ist. Die gültigen Architekturen sind ab Fink-0.29.5 powerpc, i386 und x86_64. Ist dieses Feld vorhanden und auch nach Auswertungen von Bedingungen nicht leer, ignoriert Fink die Paketbeschreibung, wenn die lokal vorhandene Architektur nicht aufgelistet ist. Ist das Feld weg gelassen oder der Wert leer, werden alle Architekturen akzeptiert.

Ein häufiger Grund für dieses Feld ist, dass ein Paket einen Compiler vor gcc-4.0 benötigt (oder auch Pakete, die von solchen Paketen abhängen) und für die Architektur powerpc ist.

Diese Feld unterstützt auch die Standardsyntax für Bedingungen für jeden Wert in der Werteliste. Ebenso können Prozenterweiterungen verwendet werden (Beim Feld Depends werden weitere Details beschrieben). Damit können bestimmte Varianten auf bestimmte Architekturen beschränkt werden. Im folgenden Beispiel:

  Package: foo-pm%type_pkg[perl]
  Type: perl (5.8.8 5.10.0)
  Architecture: (%type_pkg[perl] = 5100) x86_64

ist die Variante foo-pm5100 für x86_64 und bei der Varianten foo-pm588 bleibt das Feld leer, d. h. diese Variante ist für alle Architekturen.

Das Beispiel oben zeigt eine recht verbreitete Verwendung des Felds: Da einige Module auf 10.6 nicht mit dem System-Perl 5.10.0 als 32-bit (i386) erstellt werden können, schränkt dieses Feld die Perl-Pakete mit mehreren Typen auf bestimmte Systeme ein.

Dies ist Komma-separierte Liste der Distributionen für die das Paket (und jedes SplitOff-Paket in der Beschreibung) vorgesehen ist. Derzeit sind die gültigen Distributionen 10.4, 10.5, 10.6, 10.7, 10.8, 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, and 10.15 . Ist dieses Feld vorhanden und auch nach Auswertungen von Bedingungen nicht leer, ignoriert Fink die Paketbeschreibung, wenn die lokal vorhandene Distribution nicht aufgelistet ist. Ist das Feld weg gelassen oder der Wert leer, werden alle Distributionen akzeptiert. (Eingeführt in Fink 0.26.0.)

Seit den Fink-Distributionen für 10.9 durch 10.14.5 teilen sie sich ein gemeinsames Set an finkinfo-Dateien. Eine übliche Verwendung des Felds ist, die Distributionen auszuklammern, für die das Paket nicht erstellt werden kann.

Diese Feld unterstützt auch die Standardsyntax für Bedingungen für jeden Wert in der Werteliste. Ebenso können Prozenterweiterungen verwendet werden (Beim Feld Depends werden weitere Details beschrieben). Damit können bestimmte Varianten auf bestimmte Distributionen beschränkt werden. Im folgenden Beispiel:

  Package: foo-pm%type_pkg[perl]
  Type: perl (5.12.3 5.12.4)
  Distribution: (%type_pkg[perl] = 5123) 10.7, (%type_pkg[perl] = 5123) 10.8

ist die Variante foo-pm5123 für die Distributionen 10.7, 10.8 und bei der Varianten foo-pm5124 bleibt das Feld leer, d. h. diese Variante ist für alle Distributionen.

Da die Python-Version 2.5 für die Distributionen 10.7+ nicht zur Verfügung steht und die Perl-Versionen von Distrivution zu Distribution variieren, wird diese Feld in diesen Paketen häufig vor. Als Referenz beschreiben wir hier die Verfügbarkeit verschiedener Perl-Versionen für die Distributionen 10.3 bis 13.0 (Fett-gedruckte Systeme zeigen die Version von Sytem-Perl an):

    perl 5.6.0:  10.3
    perl 5.8.0:  10.3
    perl 5.8.1:  10.3, 10.4
    perl 5.8.4:  10.3, 10.4
    perl 5.8.6:  10.3, 10.4, 10.5
    perl 5.8.8:        10.4, 10.5, 10.6
    perl 5.10.0:             10.5, 10.6
    perl 5.12.3:                         10.7, 10.8, 10.9
    perl 5.12.4:                         10.7, 10.8, 10.9
    perl 5.16.2:                         10.7, 10.8, 10.9, 10.10, 10.11, 10.12, 10.13
    perl 5.18.2:                         10.7, 10.8, 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, 10.15, 11.0, 11.3, 12.0, 13.0, 14.0, 14.4, 15.0
    perl 5.18.4:                                     10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, 10.15, 11.0, 11.3, 12.0, 13.0, 14.0, 14.4, 15.0
    perl 5.28.2:                                     10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, 10.15, 11.0, 11.3, 12.0, 13.0, 14.0, 14.4, 15.0
    perl 5.30.2:                                     10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, 10.15, 11.0, 11.3, 12.0, 13.0, 14.0, 14.4, 15.0
    perl 5.30.3:                                     10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, 10.15, 11.0, 11.3, 12.0, 13.0, 14.0, 14.4, 15.0
    perl 5.34.1:                                     10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, 10.15, 11.0, 11.3, 12.0, 13.0, 14.0, 14.4, 15.0

Eine Möglichkeit, alle unterstützten Varianten in einer einzigen finkinfo-Datei einzuschließen, ist diese:

  Package: foo-pm%type_pkg[perl]
  Type: perl (5.8.8 5.10.0 5.12.3 5.12.4 5.16.2)
  Distribution: <<
   (%type_pkg[perl] = 588) 10.6,
   (%type_pkg[perl] = 5100) 10.6,
   (%type_pkg[perl] = 5123) 10.7, (%type_pkg[perl] = 5123) 10.8, (%type_pkg[perl] = 5123) 10.9,
   (%type_pkg[perl] = 5124) 10.7, (%type_pkg[perl] = 5124) 10.8, (%type_pkg[perl] = 5124) 10.9,
   (%type_pkg[perl] = 5162) 10.7, (%type_pkg[perl] = 5162) 10.8, (%type_pkg[perl] = 5162) 10.9
  <<

Beachten sie, dass wir alte Distributionen, wie 10.2 oder 10.4-transitional, nicht einschließen, denn die Finkversionen für diese Distributionen unterstützen dieses Feld nicht.

Eingeführt in Fink 0.12.0. Diese optionale Feld kann dazu benutzt werden, die Epoche eines Pakets zu beschreiben. (Ist es nicht angegeben, ist die Voreinstellung 0). Weitere Details stehen im Debian Policy Manual. Da Fink und die dahinter stehenden Debian-Tools als eindeutigen Bezeichner für ein Paket die Abfolge Name-Version-Revision nehmen, darf man keine Pakete definieren, die sich lediglich in der Epoche unterscheiden.

In einer Zeichenkette für die Version kommt die Epoche vor der Version, abgetrennt durch ein Semikolon (1:3.14-2). Beachten sie, dass das Feld Epoche weder in %v noch in %f enthalten ist. Fügt man das Feld Epoche in einer Paketbeschreibung hinzu, muss man auch die Abhängigkeiten aktualisieren. Fügt man z. B. in einem Paket Epoch: 1 hinzu und das Splitoff foo-dev deklariert Depends: foo-shlibs (= %v-%r), muss man das zu Depends: foo-shlibs (= %e:%v-%r) aktualisieren.

Eine kurze Beschreibung des Pakets (Was ist es?). Diese Beschreibung ist einzeilig und wird in Überscihtslisten verwendet. Deshalb muss es kurz und informativ sein. Die Becshreibung soll kürzer als 45 Zeichen sein und muss kürzer als 60 Zeichen sein. Der Paketname muss in diesem Feld nicht vorkommen - diese Beschreibung wird immer im entsprechenden Kontext verwendet. Ein Pflichtfeld.

Dieses Feld kann auf bundle gesetzt werden. Bundle-Pakete werden dazu benutzt, einen Satz von Paketen in einer Gruppe zusammen zu fassen. Ein Bundle-Paket hat nur Abhängigkeiten, aber keinen Code oder installierte Dateien. Die Felder Source, PatchScript, CompileScript, InstallScript und verwandte Felder werden für Bundle-Pakete ignoriert.

Das Feld nosource ist ähnlich. Es bedeutet, dass es keinen Quellcode-Tarball gibt, nichts herunter geladen wird und die Auspack-Phase nur ein leeres Verzeichnis erzeugt. Die Phasen Patch, Compile und Install werden aber normal ausgeführt. Man kannn also den ganzen Code in der Patchphase erzeugen und im InstallSkript einige Verzeichnisse erzeugen. Ab Fink 0.18.0 kann man das selbe Verhalten auch mit den Feld Source: none erzeugen. Dann kann man ds Feld Type für andere Zwecke benutzen(Type: perl, usw.)

Ab Fink 0.9.5 gibt es den Typ perl, durch den alternative Voreinstellungen in den Compile- und Install-Skripten verwendet werden. Ab Fink 0.13.0 gibt es eine weitere Variante diesen Typs perl $version, bei dem $version ein bestimmte Version von Perl ist die aus 3 Zahlen besteht, die mit Punkten getrennt werden, z. B. perl 5.6.0.

Seit einer CVS-Version von Fink nach Fink-0.19.2 wurde die Verwendung von Sprache/Sprachenversion verallgemeinert, so dass Paketbetreuer Typen und Subtypen definieren können und ein Paket mehr als einen Typ haben können. Typ und Subtyp sind beliebige Zeichenketten ohne Leerzeichen (Klammern, Kommata und Prozentzeichen sollten ebenfalls nicht benutzt werden); die Prozenterweiterung wird NICHT angewendet und der Typ (aber nicht der Subtyp) wird in Kleinbuchstaben konvertiert. Mehrere Typen (jeder mit einem optionalen, leerzeichen-separierten Subtyp) werden komma-separiert aufgelistet.

Zusätzlich existiert das Konzept von "variants", bei dem in einer einzigen .info-Datei eine Familie von Paketen beschrieben werden, bei denen verschiedene Optionen eingeschaltet sind. Der Schlüssel zu dem ganzen Prozess ist eine Liste von Subtypen. Statt einer einzigen Zeichenkette nutzt man eine Leerzeichen-separierte Liste von Zeichenketten in Klammern. Fink erzeugt für jeden Subtyp in der Liste einen Klon und ersetzt die Liste mit dem jeweiligen Subtyp, z. B.:

Type: perl (5.12.3 5.12.4)

ergibt zwei Paketbeschreibungen, eine die sich verhält als ob Type: perl 5.12.3 und eine andere als ob Type: perl 5.12.4 gesetzt ist. Die spezielle Subtypliste "(boolean)" steht für eine Liste, die den Typ selbst und einen Punkt enthält. Folgende zwei Formen sind identisch:

Type: -x11 (boolean)
Type: -x11 (-x11 .)

Die Erweiterung der Subtyp-Liste und das Klonieren der Pakete ist rekursiv. Stehen mehrere Typen in der Subtyp-Liste erhält man alle Kombinationen:

Type: -ssl (boolean), perl (5.12.3 5.12.4)

Man kann eine bestimmte Subtyp-Variante in anderen Felder mit %type_raw[] und %type_pkg[] verwenden. Im folgenden zwei Beispiele mit .info-Fragmenten:

Info2: <<
Package: foo-pm%type_pkg[perl]
Type: perl (5.12.3 5.12.4)
Depends: perl%type_pkg[perl]-core
 <<

Info2: <<
Package: bar%type_pkg[-x11]
Type: -x11 (boolean)
Depends: (%type_raw[-x11] = -x11) x11
CompileScript:  <<
  #!/bin/bash -ev
  if [ "%type_raw[-x11]" == "-x11" ]; then
    ./configure %c --with-x11
  else
    ./configure %c --without-x11
  fi
  make
<<
<<

Ab Fink 0.26.0 gibt es den speziellen Type: -64bit, der die neue Prozenterweiterung %lib einführt und auch die Voreinstellung für LDFLAGS ändert. Kombiniert mit der neuen Konstruktion %type_num[] kann man so in einer einzigen .info-Datei sowohl 32-bit als auch 64-bit Versionen einer Bibliothek erzeugen. Hier ein Beispiel:

Info2: <<
Package: foo%type_pkg[-64bit]
Type: -64bit (boolean)
Depends: (%type_raw[-64bit] = -64bit) 64bit-cpu
ConfigureParams: --libdir='${prefix}/%lib'
SplitOff: <<
 Package: %N-shlibs
 Files: %lib/libfoo.*.dylib
 Shlibs: <<
    %p/%lib/libfoo.1.dylib 1.0.0 %n (>= 1.0-1) %type_num[-64bit]
  <<
<<
<<

Beachten sie, dass Type: -64bit für die x86_64-Architektur nicht angemessen ist, denn dafür ist die Voreinstellung, dass 64-bit Bibliotheken erstellt und in %i/lib abgespeichert werden.

Dieses Feld spezifiziert die Lizenz, unter der das Paket vertrieben werden kann. Der Wert muss einer aus dem Kapitel Packet-Lizensen weiter oben in diesem Dokument sein. Zusätzlich darf dieses Feld nun verwendet werden, wenn das Paket auch tatsächlich die Richtlinien dafür einhält, d. h. eine Kopie der Lizenz im Verzeichnis doc des Pakets installiert.

Name und Email-Adresse der Person, die für das Paket verantwortlich ist Das Feld ist ein pflichtfeld und es darf nue ein Name und eine Adresse im folgenden Format angegeben werden:

Vorname Familienname <Nutzer@host.domain.com>

Diese Feld erlaubt Fink Syntaxänderungen in den Paketbeschreibungen zu implementieren, die nicht rückwärtskompatibel sind. Eine gegebene Version von Fink ist auf die maximale Zahl "N" gesetzt, die für sie machbar ist. Pakete mit einem höheren N werden ignoriert. Deshalb sollte dieser Mechanismus nur verwendet werden, wenn es notwendig ist. Ansonsten werden Nutzer mit älteren Finkversionen unnötigerweise ausgeschlossen. Verwenden sie diesen Mechanismus, indem sie die gesamte Paketbeschreibung in das Feld InfoN einschließen. Sie können bei Datei-Format weiter oben nachschauen, wie die Syntax für mehrzeilige Felder aussieht. Es folgen die Features des jeweiligen InfoN-Niveau und die erste Version von Fink, die es unterstützt:

• Info2 (fink ≥ 0.20.0): Die Möglichkeit, Prozenterweiterung im Hauptfeld Package der .info-Datei und die Prozenterweiterung %type_* im Feld Package von SplitOff- (und SplitOffN-)Paketen zu nutzen.
• Info3 (fink ≥ 0.25.0): Schönes Einrücken in .info-Dateien, keine Unterstützung für Mehrfachzeilen nach RFC-822 und Kommentare in den Feldern pkglist.
• Info4 (fink ≥ 0.26.2): fügt die Erweiterung %V hinzu und erlaubt %lib im Feld ConfigureParams.

Dieses Feld enthält die Liste der Pakete, die installiert werden müssen, bevor das Paket erstellt werden kann. Die Prozenterweiterung kann in diesem Feld verwendet werden (genau wie auch in den anderen Feldern dieser Sektion: BuildDepends, RuntimeDepends, Provides, Conflicts, Replaces, Recommends, Suggests und Enhances). Normalerweise ist es eine Komma-separierte Liste mit den Paketnamen, aber Fink unterstützt in der gleichen Syntax wie dpkg auch Alternativen und Versionen. Ein Beispiel mit allen Varianten:

Depends: <<
	daemonic (>= 20010902-1),
	emacs | xemacs
<<

Das Layout ist das bevorzugte Format für das Feld Depends und ähnliche Felder. Das Feld benutzt die Zeichen << für Mehrfachzeilen. Jedes Paket steht in alphabetischer Ordnung in einer separaten, eingerückten Zeile. Hat das Feld nur einen einzigen Eintrag, kann auch das vereinfachte Format Field: value verwendet werden.

Beachten sie, dass es keine Möglichkeit für optionale Abhängigkeiten gibt. Funktioniert ein Paket sowohl mit als auch ohne ein anderes Paket, dann müssen sie sicher stellen, dass das Paket auch nicht verwendet wird, auch wenn es vorhanden ist. Andernfalls müssen sie das Paket in das Feld Depends aufnehmen. Wollen sie beide Optionen anbieten, müssen sie zwei separate Pakete erstellen, z. B. wget und wget-ssl.

Ausführungsreihenfolge der Operationen: Ein logisches "OR" (Liste der Alternativen) hat höhere Priorität (verknüpft enger) als ein logisches "AND" zwischen den Paketen (oder einem Satz an Alternativen) in der Komma-separierten Liste. Anders als die Verwendung von Klammern in arithmetischen Ausdrücken gibt es im Feld Depends und verwandten Feldern keine Möglichkeit für alternative Paketgruppen oder für die eine Änderungen der Ausführungsreihenfolge der Operationen.

Beginnend mit einer post-0.18.2 CVS-Version of Fink kann man bedingte Abhängigkeiten verwenden. Diese kann man dadurch ausdrücken, dass man (Zeichenkette1 op Zeichenkette2) vor den Paketnamen platziert. Die Prozenterweiterung wird wie gewohnt ausgeführt und dann werden die beiden Zeichenketten, von denen keine leer sein kann, mit Hilfe eines der Operatoren op (<<, <=, =, !=, >>, >=) verglichen. Das folgende Paket wird nur berücksichigt, wenn der Vergleich wahr ist.

Sie können dieses Format nutzen, um die Pflege mehrerer ähnlicher Pakete zu vereinfachen. Beide Pakete elinks und elinks-ssl könnten z. B. folgendes auflisten:

Depends: <<
	expat-shlibs,
	(%n = elinks-ssl) openssl097-shlibs
<<

Das hätte den gleichen Effekt, wie wenn elinks folgendes auflisten würde:

Depends: expat-shlibs

und elinks-ssl dieses:

Depends: expat-shlibs, openssl097-shlibs

In einer alternativen Syntax, könnenten sie auch eine (Zeichenkette) angeben, womit sie wahr ist, wenn die Zeichenkette nicht leer ist, z. B.:

Package: nethack%type_pkg[-x11]
Type: -x11 (boolean)
Depends: (%type_pkg[-x11]) x11

Dies würde das Paket x11 als Abhängigkeit für die Variante nethack-x11 setzen, aber nicht die Variante nethack.

Beachten sie folgendes: Verwenden sie die Felder Depends/BuildDepends für dynamische Bibliothekspakete, für die es mehrere Hauptversionen gibt, dürfen sie folgendes nicht deklarieren:

  Package: foo
  Depends: id3lib3.7-shlibs | id3lib4-shlibs
  BuildDepends: id3lib3.7-dev | id3lib4-dev

auch wenn ihr Paket mit jeder Bibliothek funktionieren sollte. Sie müssen eine auswählen (vorzugsweise die mit der höchsten Version, die verwendet werden kann) und verwenden sie in ihrem Paket diese Version durchgängig.

Wie im Kapitel über die Richtlinien über dynamische Bibliotheken erklärt, kann immer nur ein Paket -dev installiert sein und jedes hat Links mit dem gleichen Namen, die auf verschiedene Dateinamen im zugehörigen Paket -shlibs zeigen können. Kompiliert man das Paket foo, wird der tatsächliche Dateiname (im Paket -shlibs) fest in das Binärprogramm foo übernommen. Dies bedeutet, dass das Paket genau dieses bestimmte Paket -shlibs benötigt, das zu dem Paket -dev gehört, das zur Compile-Zeit installiert war. Deshalb kann das Feld Depends nicht so aussehen, dass irgendeines ausreicht.

In der Vergangenheit hingen nicht-eseentielle Pakete implizit von essentiellen ab; dies ist nicht mehr der Fall.

Eingeführt in Fink 0.9.0. Eine Liste mit Abhängigkeiten, die nur für die Erstellungsphase gilt. Man kann sie nutzen, um Tools aufzulisten (z. B. flex), die man für das Erstellen des Pakets benötigt, aber nicht zur Laufzeit. Es hat die gleiche Syntax wie das Feld Depends. Sind die Test-Suites beim Erstellen eines Pakets aktiviert, werden die Abhängigkeiten des Felds TestDepends dem Feld BuildDepends hinzu gefügt.

Eingeführt in Fink 0.32.0. Eine Liste mit Abhängigkeiten, die nur für die Laufzeit gilt, also wenn das Paket installiert ist. Dieses Feld kann genutzt werden, um Pakete aufzulisten, die man zur Laufzeit benötigt, aber nicht beim Erstellen des Pakets. Es hat die gleiche Syntax wie das Feld Depends.

Eine komma-separierte Liste von Paketnamen, die dieses Paket zur Verfügung stellt. Wenn ein Paket namens "pine" Provides: mailer deklariert, dann ist jede Abhängigkeit von einem Paket "mailer" erfüllt, wenn "pine" installiert ist. Meisten wird man diese Pakete auch in den Feldern Conflicts und Replaces auflisten.

Beachten sie bitte, dass im Feld Provides keine Versionen verwendet werden können. Die Pakete erben weder die Version des Elternpakets noch ist eine Syntax für die Angabe einer Version definiert. Darüber hinaus gilt eine Abhängigkeit mit einer bestimmten Version als nicht erfüllt. Damit ist es relativ gefährlich, wenn mehrere Varianten dasselbe Paket in Provides deklarieren, weil die Versionsabhängigkeit nicht berücksichtigt werden kann. Deklarieren z. B. sowohl das Paket foo-gnome als auch das Paket foo-nognome ein Provides: foo, ist die Abhängigkeit Depends: foo (> 1.1) in einem anderen Paket nicht erfüllt.

Eine komma-separierte Liste von Paketnamen, die nicht gleichzeitig mit diesem Paket installiert sein dürfen. Virtuellen Pakete ist es erlaubt, Pakete aufzulisten, die auch im Feld Provides stehen; sie werden entsprechend behandelt. Dieses Feld unterstützt auch versionierte Abhängigkeiten wie das Feld Depends, aber keine Alternativen (das wäre auch nicht sinnvoll). Ist ein Paket in seinem eigenen Feld Conflicts aufgelistet, wird es ohne eine Meldung aus der Liste entfernt (eingeführt in einer post-0.18.2 CVS-Version von Fink.).

Bitte beachten: Fink selbst ignoriert dieses Feld, aber es wird an dpkg weitergegeben und entsprechend ausgewertet. Damit gilt es nur für die Laufzeit und nicht während der Erstellungszeit von Fink.

Eine Liste von Paketnamen, die nicht installiert sein dürfen, während dieses Paket compiliert wird. Man kann es dazu benutzten, dass ./configure oder der Compiler unerwünschte Bibliotheks-Header erkennt oder um zu verhindern, dass eine Version eines Tools verwendet wird, von dem bekannt ist, dass es fehlerhaft ist (z. B. ein Fehler in einer bestimmten Version von sed). Sind bei der Erstellung eines Pakets die Test-Suites aktiviert, werden zu dieser Liste die Pakete vom Feld TestConflicts hinzugefügt.

Dieses Feld wird zusammen mit dem Feld Conflicts benutzt, wenn ein Paket nicht nur die Funktion eines anderen Pakets übernimmt, sondern auch einige gemeinsamen Dateien hat. Ohne dieses Feld erzeugt dpkg bei der Installation einen Fehler, weil die Dateien immer noch Besitz eines anderen Pakets sind. Es ist auch ein Hinweis, dass die zwei Pakete echte Alternativen sind und eines gegen das andere ausgetauscht werden kann. Ist ein Paket in seinem eigenen FeldReplaces aufgelistet, wird es ohne eine Meldung aus der Liste entfernt (eingeführt in einer post-0.18.2 CVS-Version von Fink.).

Bitte beachten: Fink selbst ignoriert dieses Feld, aber es wird an dpkg weitergegeben und entsprechend ausgewertet. Damit gilt es nur für die Laufzeit und nicht während der Erstellungszeit von Fink.

Diese Felder deklarieren zusätzliche Beziehungen im selben Stil wie die anderen Felder. Diese drei Beziehungen haben auf die tatsächliche Installation mit dpkg oder apt-get keinen Einfluss. Sie werden aber von dselect und ähnlichen Frontends genutzt, um dem Nutzer sinnvolle Vorschäge anzubieten.

Eine spezielle Variante des Felds Depends mit strengerer Semantik. Dieses Feld darf nur benutzt werden, wenn der Fall auf der Developer-Email-Liste diskutiert wurde und Konsens erreicht wurde, dass es wirklich notwendig ist.

Ein boolscher Wert, der essentielle Pakete markiert. Essentielle Pakete werden im Bootstrap-Prozess installiert. dpkg weigert sich essentielle Pakete von dem System zu entfernen, so lange keine speziellen Flags gesetzt sind, um dies zu übergehen. In der Vergangenheit hingen nicht-essentielle Pakete implizit von den essentiellen ab; dies ist aber nicht mehr der Fall.

Eingeführt in Fink 0.9.9. Ein boolscher Wert, der anzeigt, dass kein anderes Paket von diesem abhängen darf, zulässig ist nur ein BuildDepend. Im Unterschied zu den üblichen boolschen Feldern, gibt es für BuildDependsOnly drei Zustände. Undefiniert (überhaupt nicht angegeben) unterscheidet sich von einer Deklarierung als falsch. Weitere Details sind im Kapitel Dynamische Bibliotheken beschrieben.

Ab Fink 0.20.5 werden die Präsenz/Absenz des Felds und wenn der Wert gesetzt ist, der Wert in die .deb Datei aufgenommen, wenn das Paket erstellt wird. Deshalb muss man die Revisionsnummer des Pakets erhöhen, wenn man den Wert von BuildDependsOnly ändert oder das Feld hinzufügt oder löscht.

Eine Liste der Spiegelserver: Jeder Spiegelserver steht im folgenden Format in einer separaten Zeile: <location>: <url>. location kann ein Kontinent-Code (z. B. nam), ein Länder-Code (z. B. nam-us) oder irgendetwas anderes sein; Die Spiegelserver werden in der gegebenen Reihenfolge ausprobiert. Ein Beispiel:

CustomMirror: <<
nam-US: ftp://ftp.fooquux.com/pub/bar
asi-JP: ftp://ftp.qiixbar.jp/pub/mirror/bar
eur-DE: ftp://ftp.barfoo.de/bar
Primary: ftp://ftp.barbarorg/pub/
<<

Die Standard-Codes für Kontinent und Land stehen in der Datei /opt/sw/lib/fink/mirror/_keys, Teil der Pakete fink oder fink-mirrors.

Eine URL zu dem Quell-Tarball. Es sollte eine HTTP- oder eine FTP-URL sein, aber Fink kümmert sich nicht weiter darum, sondern reicht die URL an wget weiter. Diese Feld unterstützt ein spezielles URL-Schema für Spiegelserver: mirror:<Spiegelname>:<Relativpfad>. Daraufhin wird der Spiegelname in Finks Konfiguration nachgeschaut, der Teil Relativpfad angehängt und als tatsächliche URL verwendet. Die bekannten Spiegelnamen sind in der Datei /opt/sw/lib/fink/mirror/_list aufgelistet, die Teil des Pakets fink oder fink-mirrors ist. Alternative dazu kann auch custom als Spiegelname verwendet werden und dann wird Fink das Feld CustomMirror dazu auswerten. Bevor die URL verwendet wird, kommt die Prozenterweiterung zum Tragen. Bedenken sie, dass %n alle Datenvarianten %type_ einschließt. Es kann deshalb günstiger sein, hier %{ni} zu verwenden (eventuell mit einigen spezifischen %type_ Erweiterungen).

Ab Fink 0.18.0 hat Source: none die spezielle Bedeutung, dass es keine Quelldateien zum Herunterladen gibt. Weitere Details dazu stehen in der Beschreibung des Felds Type. Der Wert gnu ist eine Abkürzung für mirror:gnu:%n/%n-%v.tar.gz und gnome für mirror:gnome:stable/sources/%n/%n-%v.tar.gz. Die Voreinstellung ist %n-%v.tar.gz (also manuelles Herunterladen). Diese Form einer implizit-definierten Source is obsolet (explizit angegebene einfach Namen für manuelles herunterladen ist immer noch in Ordnung).

Quellen, die nur für die Testsuite benötigt werden, sollten im Feld TestSource und verwandten Felder im Block InfoTest aufgelistet werden.

Enthält ein Paket mehrere Tarballs, muss man sie mit diesen zusätzlichen Feldern aufführen, beginnend mit N = 2. Der erste Tarball (der auch als der Haupt-Tarball betrachtet werden kann) steht also im Feld Source, der 2. im Feld Source2 und so weiter. Die Regeln sind die gleichen wie für Source, nur dass die Abkürzungen "gnu" und "gnome" nicht ausgewertet werden, denn das wäre sowieso nutzlos. Beginnend mit einer CVS-Version von Fink nach 0.19.2 können sie beliebige (und nicht notwendigerweise aufeinander folgende) Werte mit N ≥ 2 verwenden, aber keine Dubletten.

Diese Feld wird benötigt, wenn der Tarball in ein einziges Verzeichnis ausgepackt wird, dessen Namen sich aber vom Rumpf des Tarball-Namens unterscheidet. Ein Tarball mit dem Namen "foo-1.0.tar.gz" wird normalerweise in ein Verzeichnis "foo-1.0" ausgepackt. Ist das nicht der Fall, so kann man den Namen mit diesem Feld angeben. Prozenterweiterung wird in diesem Feld ausgeführt.

Setzen sie diesen boolschen Parameter auf wahr (true), wenn der Tarball nicht in ein einziges Verzeichnis ausgepackt wird. Ein Tarball mit dem Namen "foo-1.0.tar.gz" wird normalerweise in ein Verzeichnis "foo-1.0" ausgepackt. Werden aber die Dateien des Tarballs nur in das aktuelle Verzeichnis ausgepackt, nutzen sie dieses Feld und setzen sie den Wert auf wahr (true).

Normalerweise wird ein zusätzlicher Tarball in dasselbe Verzeichnis wie der Haupt-Tarball ausgepackt. Muss er aber in ein spezifisches Unterverzeichnis ausgepackt werden, können sie dies in diesem Fald angeben. Source2ExtractDir bezieht sich erwartungsgemäß auf den Tarball in Source2. Beispiele dafür sind in den Paketen ghostscript, vim und tetex.

Mit diesem Feld kann man eine Quell-Tarball umbenennen. Das ist vor allem dann nützlich, wenn die Version der Quelle im Namen des Verzeichnis des Servers steht, der Tarball aber für alle Versionen gleich heißt, z. B. http://www.foobar.org/coolapp/1.2.3/source.tar.gz. Die damit verbundenen Probleme kann man wie folgt umgehen:

SourceRename: %n-%v.tar.gz

In diesem Beispiel würde z. B. der Tarball unter dem Namen /opt/sw/src/coolapp-1.2.3.tar.gz abgespeichert werden, genau so wie man es erwarten würde.

Dieses Feld erfüllt die gleiche Funktion, nur dass es sich auf Tarballs bezieht, die in den entsprechenden Feldern SourceN stehen. Beispiele dafür finden sie in den Paketbeschreibungen context oder hyperref.

Eingeführt in Fink 0.10.0. In diesem Feld müssen sie die MD5 Checksum der Quelldatei eintragen. Fink benutzt diese Information um falsche Quelldateien zu entdecken, d. h. Tarballs, die nicht mit denen übereinstimmen, die der Paket-Betreuer verwendet hat. Häufige Ursachen für dieses Problem sind: unvollständig herunter geladene Dateien, Austausch des Tarball Upstream ohne Ankündigung, Trojanerangriff oder ähnliches und alles mögliche andere.

Ein typisches Beispiel sieht so aus:

Source-MD5: 4499443fa1d604243467afe64522abac

Für die Berechnung der Checksum kann man das Tool md5sum verwenden. Die Checksum des Tarball /opt/sw/src/apache_1.3.23.tar.gz kann man mit dem folgenden Kommando berechnen (einschließlich der Ausgabe):

fingolfin% md5sum /opt/sw/src/apache_1.3.23.tar.gz 
4499443fa1d604243467afe64522abac  /opt/sw/src/apache_1.3.23.tar.gz

Wie man sieht ist der Wert links genau die Summe, die man braucht.

Eingeführt in Fink 0.10.0. Dieses Feld hat denselben Zweck wie das Feld Source-MD5, mit dem Unterschied, dass es für die MD5 Checksum der Tarballs der entsprechenden Felder SourceN ist.

Alternative method to list the checksum for a source file. This field takes a hash type, followed by the actual checksum. For example:

Source-Checksum: SHA256(5048f1c8fc509cc636c2f97f4b40c293338b6041a5652082d5ee2cf54b530c56)

Current valid checksums are MD5, SHA1, and SHA256. The shasum tool can be used to calculate SHA checksums:

$ shasum -a 256 /opt/sw/src/libexif-0.6.22.tar.xz 
5048f1c8fc509cc636c2f97f4b40c293338b6041a5652082d5ee2cf54b530c56  /opt/sw/src/libexif-0.6.22.tar.xz

The Source-Checksum field should only be used once per .info file. If both the Source-MD5 and Source-Checksum fields are present, Source-Checksum takes precedence.

This is just the same as the Source-Checksum field, except that it is used to specify the checksum of the tarball specified by the corresponding SourceN field.

Eingeführt in Fink 0.10.0. Dieses Feld bezieht sich nur auf Quelldateien im tar-Format.

Mit diesem Feld kann man Dateien in einem gegebenen Quell-Tarball während des Auspackens umbenennen. Dies behebt die Probleme, die damit zusammenhängen, dass das HFS+ Dateisystem Groß- und Kleinschreibung nicht unterscheidet und z. B. die Dateien install und INSTALL auf dem Standard Mac OS X eine Kollission verursachen. Mit diesem Feld kann man dieses Problem beheben ohne dass man einen neuen Tarball erstellen muss (was in der Vergangenheit die einzige Lösung war.).

In diesem Feld können sie einfach eine Liste an Dateien aufführen, die umbenannt werden sollen. Man kann auch Wildcards benutzen. Standard ist einfach eine Umbennung mit angehängtem _tmp. Dies kann man mit derselben Syntax wie in den Feldern Files und DocFiles überschreiben, nämlich mit dem alten Dateinamen, gefolgt von einem : und dann dem neuen Dateinamen. Ein Beispiel:

TarFilesRename: foo bar.* qux:quux
Tar2FilesRename: directory/INSTALL:directory/INSTALL.txt

Eingeführt in Fink 0.10.0. Dieses Feld ist genau wie das Feld TarFilesRename mit dem Unterschied, dass es auf den Tarball angewendet wird, der im entsprechenden Feld SourceN steht.

Ein boolscher Wert. Ist er auf wahr (true) gesetzt, werden die Dateien config.guess und config.sub im Verzeichnis build durch Versionen ersetzt, die Darwin kennen. Dies erfolgt in der Patch-Phase bevor das PatchSkript ausgeführt wird. Benutzen sie dies NUR, wenn sie sich sicher sind, dass es benötigt wird, d. h. wenn das configure-Skript mit der Fehlermeldung "unknown host" abbricht.

Eingeführt in einer post-0.9.0 CVS-Version. Eine Liste von Unterverzeichnissen. Es macht das gleiche wie das Feld UpdateConfigGuess, aber für Pakete mit veralteten config.guess-Dateien in mehreren Verzeichnissen überall im Baum der Quellen. Früher musste man die Dateien von Hand im Patchskript an die richtigen Stellen kopieren. Mit diesem Feld muss man nur noch die Verzeichnisse auflisten. Benutzen sie ., um auch die Dateien im Verzeichnis build zu ersetzen.

Ein boolscher Wert. Ist er auf wahr (true) gesetzt, werden die Dateien ltconfig und ltmain.sh im Verzeichnis build durch Versionen ersetzt, die Darwin kennen. Dies erfolgt in der Patch-Phase bevor das PatchSkript ausgeführt wird. Benutzen sie dies NUR, wenn sie sich sicher sind, dass es benötigt wird. Einige Pakete kann man beschädigen, wenn man die libtool-Skripte mit unpassenden Versionen überschreibt. Für weitere Details lesen sie die Seiten über libtool.

Eingeführt in einer post-0.9.0 CVS-Version. Eine Liste von Unterverzeichnissen. Es macht das gleiche wie das Feld UpdateLibtool, aber für Pakete mit veralteten libtool-1.3.x-Skripten in mehreren Verzeichnissen überall im Baum der Quellen. Früher musste man die Dateien von Hand im Patchskript an die richtigen Stellen kopieren. Mit diesem Feld muss man nur noch die Verzeichnisse auflisten. Benutzen sie ., um auch die Dateien im Verzeichnis build zu ersetzen.

Ein boolscher Wert. Ist er auf wahr (true) gesetzt, wird die Datei Makefile.in.in im Unterverzeichnis po durch eine angepasste Version ersetzt. Dies erfolgt in der Patch-Phase bevor das PatchSkript ausgeführt wird.

Die angepasste Version respektiert DESTDIR sorgt dafür, dass Kataloge mit Meldungen im Verzeichnis /opt/sw/share/locale landen und nicht in /opt/sw/lib/locale. Bevor sie dieses Feld benutzen, überprüfen sie, dass das Paket nicht beschädigt wird und überhaupt notwendig ist. Sie können sich mit dem Tool diff die Unterschiede zwischen der V ersion des Pakets und der in Fink (in /opt/sw/lib/fink/update) anzeigen lassen.

Der Dateiname eines Patch, der mit dem Kommando patch -p1 <patch-file angewendet wird. Dies sollte einfach ein Dateiname sein. Der zugehörige Pfad (das gleiche Verzeichniss, in dem die .info-Datei steht) wird automatisch davor gestellt. Prozenterweiterung wird in diesem Feld ausgeführt. Ein typischer Wert ist einfach %f.patch oder %n.patch. Der Patch wird in einem separaten Schritt angewandt, bevor das Patch-Skript (wenn vorhanden) ausgeführt wird.

Beachten sie, dass %n allen Datenvarianten %type_ einschließt. Es kann deshalb günstiger sein, hier %{ni} zu verwenden (eventuell mit einigen spezifischen %type_ Erweiterungen). Es ist einfacher, eine einzige Patchdatei zu pflegen und dann variantenspezifische Änderungen im Patch-Skript zu machen als separate Patchdateien für jede Variante zu pflegen.

Ab Fink-0.29.0 sollte dieses Feld nicht benutzt werden. Nutzen sie statt dessen das Feld PatchFile. Die Unterstützung für das Feld Patch wird in Zukunft entfernt werden.

Syntax für dieses Feld ist die gleiche wie für das Feld Patch. Der komplette Pfad für diese Datei erhält man über die Prozenterweiterung %{PatchFile}. Sie sollten %a nicht verwenden. Im Unterschied zum Feld Patch, wird PatchFile im Patch-Skript verwendet. Fink überprüft, ob die Datei existiert, lesbar ist und seine Checksum mit dem Wert im Feld PatchFile-MD5 übereinstimmt.

Man kann die Felder Patch und PatchFile in der gleichen Paketbeschreibung verwenden. Jedes Paket, das das Feld PatchFile verwendet, muss auch wenigstens BuildDepends: fink (>= 0.24.12) deklarieren. Muss man aus anderen Gründen eine höhere Version angeben, ist dies auch in Ordnung.

Hat ein Paket mehrere Patch-Dateien, muss man sie in zusätzlichen Feldern deklarieren, mit N = 2 anfangend. Die erste Patch-Datei steht als in PatchFile, die zweite in PatchFile2 uns so weiter. Jedes Paket, das das Feld PatchFileN verwendet, muss auch wenigstens BuildDepends: fink (>= 0.30.0) deklarieren. Muss man aus anderen Gründen eine höhere Version angeben, ist dies auch in Ordnung.

Hier steht die MD5-Checksum einer Datei des Felds PatchFile. Dieses Feld ist obligatorisch, wenn man das Feld PatchFile benutzt. (Eingeführt in Fink-0.24.12)

Hier steht die MD5-Checksum einer Datei des Felds PatchFileN. Dieses Feld ist obligatorisch, wenn man das Feld PatchFile benutzt. (Eingeführt in Fink-0.30.0)

Eine Liste von Kommandos, die in der Patch-Phase ausgeführt werden. Hierhin gehören Kommandos, mit denen man die Paketquellen patched oder irgendwie modifiziert. Weitere Details dazu stehen weiter unten im Abschnitt Anmerkungen zu Skripten. Bevor die Kommandos ausgeführt werden, wird die Prozenterweiterung ausgeführt. Existiert das Feld PatchFile, ist das Standard-PatchScript:

patch -p1 < %{PatchFile}

Bei einem oder mehreren Feldern PatchFileN, wird entsprechend dem Bedarf folgendes an das Skript angehängt:

patch -p1 < %{PatchFileN}

Gibt es kein Feld PatchFile, ist das Standardskript leer. Bei einem expliziten Feld PatchScript muss man auch die PatchFile(s) explizit anwenden.

Hiermit kann man Umgebungsvariablen für die Compile- und Installations-Phase setzen. Damit kann man Compiler-Flags z. B. an Configure-Skripte und Makefiles übergeben. Derzeit werden folgende Variablen unterstützt: CC, CFLAGS, CPP, CPPFLAGS, CXX, CXXFLAGS, DYLD_LIBRARY_PATH, JAVA_HOME, LD, LDFLAGS, LIBRARY_PATH, LIBS, MACOSX_DEPLOYMENT_TARGET, MAKE, MFLAGS, MAKEFLAGS. Für den angegebenen Wert kann die Prozenterweiterung aus dem letzten Kapitel genutzt werden: Ein häufiges Beispiel:

SetLDFLAGS: -Wl,-strip_dead_dylibs

Einige Umgebungsvariablen haben einen Standardwert. Gibt man für diese einen Wert an, werden sie dem Standardwert voran gestellt. Die vorbesetzten Variablen und ihre Standardwerte sind:

CPPFLAGS: -I%p/include
LDFLAGS: -L%p/lib

Beginnend mit Fink 0.26.0, gibt es eine Ausnahme von diesen Standards: Ist der Type: -64bit auf -64bit gesetzt, dann ist der Standardwert von LDFLAGS auf -L%p/%lib -L%p/lib gesetzt.

MACOSX_DEPLOYMENT_TARGET ist auf einen Standardwert gesetzt, der von der Version von OS X abhängt, aber setzt man es für ein Paket auf einen anderen Wert, so wird der Standardwert überschrieben.

Setzt man dies auf wahr (true), dann werden die Standardwerte für die Variablen mit Voreinstellungen (wie CPPFLAGS, LDFLAGS, CXXFLAGS) nicht gesetzt. Soll zum Beispiel LDFLAGS nicht gesetzt werden, erreicht man dies mit NoSetLDFLAGS: true .

Wenn auf wahr (true) gesetzt, wird -jN für das Compile-Skript und das Test-Skript an die Umgebungsvariable MAKEFLAGS angehängt. N ist der Wert des Felds MaxBuildJobs in der Datei fink.conf. Dieser Wert wird an die Variable MAKEFLAGS auch angehängt, wenn das Feld NoSetMAKEFLAGS: true gesetzt ist. Ab der Fink-Version 0.31.2 ist die Voreinstellung True, wenn das Feld nicht angegeben oder leer ist.

Ab Version 0.33.0 wird Fink als root und nicht als Nutzer fink-bld mit wenigen Privilegien ausgeführt, wenn das Feld BuildAsNobody auf false gesetzt ist. Ist das Feld nicht vorhanden, ist die Voreinstellunge für den Wert wahr true, das Paket wird also als Nutzer fink-bld erstellt.

In früheren Versionen von Fink bleibt dieses Feld folgenloss.

Zusätzliche Parameter, die an das Configure-Skript durchgereicht werden. (Weitere Details dazu gibt es beim Compile-Skript) Außer für Pakete des Typs Type: Perl wird der Parameter --prefix=%p dem Wert vorangestellt. Ab Fink > 0.13.7 funktioniert dieses Feld auch für Perlmodule mit dem Feld Type: Perl; der Perl-Standard Makefile.PL wird dem Wert des Felds ConfigureParams voran gestellt.

Sind bei der Paketserstellung die Test-Suites aktiviert wird der Wert des Felds TestConfigureParams den normalen ConfigureParams Werten angehängt.

Beginnend mit Fink-0.22.0 unterstützt dieses Feld auch Bedingungen. Die Syntax ist die gleiche wie im Feld Depends und anderen Feldern mit Paketlisten. Die Bedingungen gilt nur für das leerzeichenbegrenzte "Wort" hinter der Bedingung. Ein Beispiel:

Type: -x11 (boolean)
ConfigureParams: --mandir=%p/share/man (%type_pkg[-x11]) --with-x11 --disable-shared

reicht die Parameter --mandir und --disable-shared immer weiter, --with-x11 aber nur für die -x11 Variante.

Dieses Feld unterstützt, Parameter in mehreren Zeilen mit einer Mehrzeilen-Deklaration zu schreiben. Dieses Feld wird wie eine Shell-Kommandozeile behandelt und benutzt \, um Zeilen zu trennen:

ConfigureParams: <<
	--mandir=%p/share/man \
	(%type_pkg[-x11]) --with-x11 \
	--disable-shared
<<

Beachten sie: Stellen sie bei mehreren Zeilen bedingte Parameter nicht in die letzte Zeile. Ist die Bedingung falsch, dann wird der darauf folgende Parameter nicht ausgewertet. Dieses führt dann zum Absturz der Shell.

Dieses Feld deklariert die GCC-ABI, die in diesem Paket von C++ Code genutzt wird. (Es ist notwendig, weil sich die ABI zweimal änderte und jede Bibliothek, die sie in ihrem C++ Code verlinken, muss mit der selben ABI kompiliert werden wie ihr Code.)

Die erlaubten Werte sind: 2.95.2 (oder 2.95), 3.1, 3.3 und 4.0. So weit uns bekannt, wollen die Autoren von GCC die GCC-ABI irgendwann stabil halten; wir können nur hoffen, dass sie sich nicht erneut ändert.

Das Feld GCC hat keine Voreinstellung an sich, denn es wird ignoriert, wenn es nicht gesetzt ist. Es gibt aber für jeden Baum einen erwarteten Wert für GCC, der dem g++ Compiler für diesem Baum entspricht. Die erwarteten Werte für die verschiedenen Paketbäume sind: 2.95 im Baum 10.1, 3.1 im Baum 10.2, 3.3 in den Bäumen 10.2-gcc3.3, 10.3 und 10.4-transitional und 4.0 in den Bäumen 10.4 und 10.7.

Beachten sie, dass der Compiler im Paket angegeben werden muss, wenn er von dem erwarteten abweicht. Typischerweise wird der Compiler durch Setzen der Flags CC oder CXX geändert. Es sollte auch eine Abhängigkeit von einem der (virtuellen) gcc-Pakete angegeben werden.

Ab Version 0.13.8 von Fink wird die Version von gcc mit gcc_select überprüft, wenn dieses Feld gesetzt ist. Liegt eine falsche Version vor, bricht Fink mit einem Fehler ab.

Dieses Feld wurde in Fink eingerichtet, um Betreuern zu helfen, den Übergängen zwischen den gcc Compilern zu folgen, die binäre Inkompatibilitäten zwischen Bibliotheken einführte, die C++ Code enthalten, die aber nicht durch aus Versionen erkannt werden kann.

Eine Liste von Kommandos, die in der Compile-Phase ausgeführt wird. Hierhin gehören Kommandos, die ein Paket konfigurieren und compilieren. Weitere Details dazu stehen weiter unten im Abschnitt Anmerkungen zu Skripten. Bevor die Kommandos ausgeführt werden, wird die Prozenterweiterung ausgeführt. Der Standard ist:

./configure %c
make

Dies ist für Pakete angemessen, die GNU autoconf benutzen. Für Pakete des Typs perl (deklariert über das Feld Type) ohne Angabe der Perl-Version ist der Standard ab Fink 0.13.4 folgender:

perl Makefile.PL PREFIX=%p \
  INSTALLPRIVLIB=%p/lib/perl5 \
  INSTALLARCHLIB=%p/lib/perl5/darwin \
  INSTALLSITELIB=%p/lib/perl5 \
  INSTALLSITEARCH=%p/lib/perl5/darwin \
  INSTALLMAN1DIR=%p/share/man/man1 \
  INSTALLMAN3DIR=%p/share/man/man3 \
  INSTALLSITEMAN1DIR=%p/share/man/man1 \
  INSTALLSITEMAN3DIR=%p/share/man/man3 \
  INSTALLBIN=%p/bin \
  INSTALLSITEBIN=%p/bin \
  INSTALLSCRIPT=%p/bin
make
make test

Ist der Typ perl $version mit angegebener Perl-Version ($version könnte beispielsweise 5.6.0 sein), dann wird der Standard dieses:

perl$version Makefile.PL \
  PERL=perl$version PREFIX=%p \
  INSTALLPRIVLIB=%p/lib/perl5/$version \
  INSTALLARCHLIB=%p/lib/perl5/$version/$perlarchdir \
  INSTALLSITELIB=%p/lib/perl5/$version \
  INSTALLSITEARCH=%p/lib/perl5/$version/$perlarchdir \
  INSTALLMAN1DIR=%p/share/man/man1 \
  INSTALLMAN3DIR=%p/share/man/man3 \
  INSTALLSITEMAN1DIR=%p/share/man/man1 \
  INSTALLSITEMAN3DIR=%p/share/man/man3 \
  INSTALLBIN=%p/bin \
  INSTALLSITEBIN=%p/bin \
  INSTALLSCRIPT=%p/bin
make
make test

wobei $perlarchdir für Versionen 5.8.0 und früher "darwin" ist und "darwin-thread-multi-2level" für Versionen 5.8.1 und später.

Eingeführt in Fink > 0.13.7. Ein boolscher Wert speziell für Pakete mit Perl-Modulen. Wenn auf wahr gesetzt, wird der Teil make test im CompileScript für dieses bestimmte Perl-Modul-Paket ignoriert.

Eingeführt in Fink 0.25. Dieses Feld umfasst Informationen, die nur ausgeführt werden, wenn bei der Erstellung eines Pakets die Test-Suites aktiviert sind. Es enthält andere Felder. Ist es vorhanden, muss das Feld TestScript enthalten sein. Alle anderen Felder sind optional. Die folgenden Felder sind innerhalb InfoTest erlaubt:

• TestScript: Ein Skript, das die Test-Suite ausführt. Dieses Skript sollte mit einem Status 0 enden, wenn die Suite erfolgreich endet, mit einem Status 1 um Warnungen anzuzeigen oder jeder andere Wert, der Fehler anzeigt, die ernst genug für einen fatalen Abbruch sind. Wegen der Dreifach-Logik des Ausgangswert sollte er auf jeden Fall gesetzt werden. make check ist zum Beispiel ein schlechtes Skript, weil es mit dem Status 1 endet, wenn das Check-Ziel nicht existiert. make check || exit 2 wäre schon ein besseres Skript.
• TestConfigureParams: Ein Wert, der an die ConfigureParams angehängt wird.
• TestDepends und TestConflicts: Listen der Pakete, die an Listen in BuildDepends oder BuildConflicts angehängt wird.
• TestSource: Extra Quellen, die für die Test-Suites benötigt werden. Alle verwandten Felder werden auch unterstützt. Man muss also auch TestSource-MD5 oder TestSource-Checksum deklarieren. Die Felder TestSourceN und die entsprechenden Felder TestSourceN-MD5, TestSourceN-Checksum, TestTarFilesRename usw. können ebenfalls vorhanden sein.
• TestSuiteSize: Beschreibt ungefähr wie lange das Ausführen der Test-Suites dauern wird. Erlaubte Werte sind small, medium und large. Gegenwärtig wird dieses Feld ignoriert.
• Jedes andere Standardfeld. Ist ein Feld sowohl innerhalb als auch außerhalb von InfoTest deklariert, wird der Werte innerhalb von InfoTest den Wert von außerhalb ersetzen, wenn die Test-Suites aktiviert sind.

Hier ein Beispiel:

InfoTest: <<
    TestScript: make check || exit 2
    TestConfigureParams: --enable-tests
<<

Eingeführt in Fink 0.9.5. Ein boolscher Wert speziell Perl-Modul-Pakete. Ist er auf wahr (true) gesetzt, wird Code zu den Skripten install, postrm und postinst hinzu gefügt, der die .pod-Dateien aus den Perl-Paketen pflegt. Dies schließt ein, das .pod-Datum in der zentralen Datei /opt/sw/lib/perl5/darwin/perllocal.pod hinzu zu fügen oder zu entfernen. (Ist der Typ als perl $version mit einer bestimmten Perl-Version wie 5.6.0 deklariert, werden diese Skripte angepasst, um die zentrale .pod-Datei /opt/sw/lib/perl5/$version/perllocal.pod zu bearbeiten.)

Die Liste der Kommandos, die in der Installationsphase ausgeführt werden. Hier stehen die Kommandos, die alle notwendigen Dateien in das temporäre dpkg-Verzeichnis für das Paket kopieren. Weitere Details dazu stehen weiter unten im Abschnitt Anmerkungen zu Skripten. Bevor die Kommandos ausgeführt werden, wird die Prozenterweiterung ausgeführt. Normalerweise ist der Standard:

make install prefix=%i

Dies ist für Pakete angemessen, die GNU autoconf benutzen. Für Pakete des Typs perl (deklariert über das Feld Type) ohne Angabe der Perl-Version ist der Standard ab Fink 0.13.4 folgender:

make install INSTALLPRIVLIB=%i/lib/perl5 \
  INSTALLARCHLIB=%i/lib/perl5/darwin \
  INSTALLSITELIB=%i/lib/perl5 \
  INSTALLSITEARCH=%i/lib/perl5/darwin \
  INSTALLMAN1DIR=%i/share/man/man1 \
  INSTALLMAN3DIR=%i/share/man/man3 \
  INSTALLSITEMAN1DIR=%i/share/man/man1 \
  INSTALLSITEMAN3DIR=%i/share/man/man3 \
  INSTALLBIN=%i/bin \
  INSTALLSITEBIN=%i/bin \
  INSTALLSCRIPT=%i/bin

Ist der Typ perl $version mit angegebener Perl-Version ($version könnte beispielsweise 5.6.0 sein), dann wird der Standard dieses:

make install INSTALLPRIVLIB=%i/lib/perl5/$version \
  INSTALLARCHLIB=%i/lib/perl5/$version/$perlarchdir \
  INSTALLSITELIB=%i/lib/perl5/$version \
  INSTALLSITEARCH=%i/lib/perl5/$version/$perlarchdir \
  INSTALLMAN1DIR=%i/share/man/man1 \
  INSTALLMAN3DIR=%i/share/man/man3 \
  INSTALLSITEMAN1DIR=%i/share/man/man1 \
  INSTALLSITEMAN3DIR=%i/share/man/man3 \
  INSTALLBIN=%i/bin \
  INSTALLSITEBIN=%i/bin \
  INSTALLSCRIPT=%i/bin

wobei $perlarchdir für Versionen 5.8.0 und früher "darwin" ist und "darwin-thread-multi-2level" für Versionen 5.8.1 und später.

Wenn das Paket es unterstützt, ist es besser, stattdessen make install DESTDIR=%d auzuführen.

Eingeführt in einer Version nach 0.23.1. Dieses Feld installiert das angegebene Applicationbundle bzw. mehrere im Verzeichnis %p/Applications. Es wird auch ein Symlink im Verzeichnis /Applications/Fink erzeugt. Beispiel:

AppBundles: build/*.app Foo.app

Eingeführt in Fink 0.10.0. Das Feld ist irgendwie ähnlich wie das Feld DocFiles. Damit werden die angegebenen jar-Dateien ins Verzeichnis %p/share/java/%n installiert. Beispiel:

JarFiles: lib/*.jar foo.jar:fooBar.jar

Damit werden alle jars im Verzeichnis lib installiert; die Datei foo.jar als fooBar.jar.

Es bewirkt auch, dass diese jar-Dateien (genau: alle Dateien in %p/share/java/%n mit der Endung .jar) an die Umgebungsvariable CLASSPATH angehängt werden. Damit können Tools wie configure oder ant die installierten jar-Dateien feststellen.

Dieses Feld deklariert eine bequehme Art, Dateien wie README oder COPYING für das Paket im doc-Verzeichnis %p/share/doc/%n zu installieren. Der Wert ist eine leerzeichenseparierte Liste der Dateien. Man kann Dateien aus Unterverzeichnissen des build-Verzeichnisses kopieren, aber sie werden im doc-Verzeichnis und nicht einem Unterverzeichnis stehen. Shell Wildcards sind erlaubt. Es ist auch möglich, einzelne Dateien umzubenennen, indem man den neuen Namen mit einem Doppelpunkt (:) anhängt, z. B. libgimp/COPYING:COPYING.libgimp. Dieses Feld funktioniert, indem entsprechende install-Kommandos im Installations-Skript angehängt werden.

Eingeführt in Fink 0.11.0. Diess Feld deklariert dynamische Bibliotheken, die in dem Paket installiert werden. Jede Bibliotheke steht in einer separaten Zeile die den install_name der Bibliothek und Informationen über ihre binäre Kompatibilität enthalten. Ist die Bibliothek öffentlich, steht in der Zeile auch die -compatibility_version, Informationen zur Abhängigkeit mit Version darüber, welches Fink-Paket die Bibliothek mit dieser compatibility_version enthält und die Architektur der Bibliothek. (Die Architektur der Bibliothek kann "32", "64" oder "32-64" sein oder ganz fehlen. Ist sie nicht explizit angegeben, wird die Voreinstellung genommen, d.h. "32" für PowerPC und i386 und "64" für x86_64.) Die Abhängigkeit sollte in der Form foo (>= version-revision) angegeben sein, wobei sich foo (>= version-revision) auf die erste Version des Finkpakets bezieht, das diese Bibliothek (mit der compatibility version) zur Verfügung stellte. Außerdem impliziert die Deklaration, dass der Betreuer versichert, dass auch in späteren Versionen des Pakets eine Bibliothek mit diesem Namen und dieser -compatibility_version angeboten wird. Dem Namen von dynamischen Bibliotheken, die "privat" sein sollen, wird ein Ausrufezeichen vorangestellt und keine Informationen zu Kompatibilität oder Version werden angegeben. Weitere Details dazu stehen im Abschnitt dynamische Bibliotheken.

Eingeführt in Fink 0.10.0. Dieses Feld deklariert eine bequehme Art, Umgebungsvariablen für die Laufzeit einen statischen Wert zuzuweisen (Benötigen sie mehr Flexibilität, schauen sie im Abschnitt profile.d Skripte nach). Solange das Paket installiert ist, werden diese Variablen im Skript /opt/sw/bin/init.[c]sh gesetzt.

Der Wert ihrer Variablen kann Leerzeichen enthalten (Leerzeichen am Ende werden abgeschnitten); Prozenterweiterung wird ausgeführt. In diesem Beispiel

RuntimeVars: <<
  SomeVar: %p/Value
  AnotherVar: foo bar
<<

werden zwei Umgebungsvariablen 'SomeVar' und 'AnotherVar' erzeugt und ihre Werte auf '/opt/sw/Value' (oder wasauch immer ihr Präfix ist) und 'foo bar' gesetzt.

Dieses Feld funktioniert, in dem es die entsprechenden Kommandos im Installations-Skript angehängt. Diese Kommandos fügen eine Zeile mit setenv/export im Paket-Skript profile.d hinzu, so dass sie ihre eigenen hinzufügen können, ohne dass sie überschrieben werden. Die Zeilen werden den Skripten voran gestellt, so dass man die Variablen auch in den Skripten verwenden kann.

Eingeführt in Fink 0.9.9. Erzeugen sie ein zweites Paket vom selben compile/install-Lauf. Schauen sie für weitere Details im separaten Abschnitt Splitoff nach.

Eingeführt in Fink 0.9.9. Dies ist genau so wie SplitOff, um dritte, vierte usw. Pakete vom selben compile/install-Lauf zu erzeugen. Beginnend mit einer CVS-Version von Fink nach 0.19.2 können sie beliebige (und nicht notwendigerweise aufeinander folgende) Werte mit N ≥ 2 verwenden, aber keine Dubletten.

Eingeführt in Fink 0.9.9. Dieses Feld wird nur in den Feldern SplitOff oder SplitOffN verwendet. Es deklariert die Dateien und Verzeichnisse, die vom Installationsverzeichnis des Pakets %I in das aktuelle Installationsverzeichnis %i verschoben werden. Beachten sie, dass dies nach dem Installations-Skript und dem Feld DocFiles des Elternpakets ausgeführt wird, aber vor dem Installations-Skript und dem Feld DocFiles des aktuellen Pakets.

Diese Felder enthalten Shell-Skripte, die ausgeführt werden, wenn ein Paket installiert, aktualisiert oder entfernt wird. Fink fügt automatisch den Shell-Skript-Header #!/bin/sh ein und ruft set -e auf, so dass ein Fehler eines Kommandos zum sofortigen Abbruch des Skripts führt. Fink fügt auch ein exit 0 am Ende ein. Will man einen Fehler anzeigen, sollte man das Skript mit einem anderen Wert als Null beenden. Der erste Parameter ($1) ist auf einen Wert gesetzt, der anzeigt, welche Aktion ausgeführt wird. einige der möglichen Werte sind install, upgrade, remove und purge. Beachten sie, dass es noch andere Werte gibt, die benutzt werden, um Fehler zurück zu verfolgen und wenn Pakete gegenseitig ausgetauscht werden müssen.

Die Skripte werden zu folgenden Zeitpunkten ausgerufen:

• PreInstScript: Wenn das Paket zum ersten mal installiert wird und bevor es auf diese Version aktualisiert wird.
• PostInstScript: Nach dem Auspacken und Einrichten des Pakets.
• PreRmScript: Bevor das Paket entfernt oder auf eine neue Version aktualisiert wird.
• PostRmScript: Nachdem das Paket entfernt oder auf eine neue Version aktualisiert wird.

Klarstellung: Bei einer Aktualisierung werden sowohl die ...Inst-Skripte der neuen Version als auch die ...Rm-Skripte der alten Version ausgeführt. Details dazu kann man im Debian Policy Manual nachlesen, im To make it more clear, an upgrade invokes both the ...Inst scripts of the new version and the ...Rm scripts of the old version. Kapitel 6.

Prozenterweiterungen werden in diesen Skripten ausgeführt. Kommandos können ohne den kompletten Pfad ausgeführt werden.

Eine leerzeichengetrennte list an Dateien von Konfigurationsdateien, die vom Nutzer geändert werden können. Prozenterweiterungen werden ausgeführt. Die Dateien müssen mit einem absoluten Pfad angegeben werden, d. h. %p/etc/%n.conf. Die genannten Dateien werden von dpkg besonders behandelt. Wird ein Paket aktualisiert und die Datei wurde sowohl auf der Festplatte als auch im Paket geändert, wird der Nutzer gefragt, welche Version genutzt werden soll. Von den Dateien werden Sicherungskopien (backups) angelegt. Wird ein Paket entfernt (removed), bleiben die Konfigurationsdateien auf der Festplatte erhalten. Nur ein "purge" entfernt auch die Konfigurationsdateien.

Listet die Namen der Info-Dokumente, die das Paket in %p/share/info installiert. Es wird entsprechender Code zu den Skripten postinst und prerm hinzugefügt, um die Info-Verzeichnis-Datei dir zu aktualisieren.

Anmerkung: Nutzen sie nur die nicht-numerierten Dateien, wenn Info-Dokumente ausgespalten werden. Hat z. B. ein Paket die Dateien

foo.info
foo.info-1
foo.info-2

sollten sie nur diese aufführen:

InfoDocs: foo.info

Dieses Feature ist immer noch im Fluss. Es können in Zukunft durchaus weitere Felder für eine feinere Steuerung hinzu gefügt werden.

Liefert Service-beschreibungen für daemonic. daemonic wird von Fink benutzt, um StartupItems für daemon-Prozesse (z. B. Web-Server) einzurichten oder zu entfernen. Die Beschreibung wird dem Paket als Datei mit dem Namen %p/etc/daemons/Name.xml hinzu gefügt, wobei Name im Feld DaemonicName angegeben wird und als Standard den Paketnamen hat. Prozenterweiterungen werden für dieses Feld ausgeführt. Beachten sie, dass sie daemonic zur Liste im Feld dependency hinzu fügen müssen, wenn ihr Paket es benutzt.

Ein Name für die Datei der daemonic-Service-Beschreibung. Weitere Details stehen in der Beschreibung ders Felds DaemonicFile.

Die URL der Upstream-Homepage des Pakets.

Eine ausführlichere Beschreibung des Pakets als im Feld Description (was ist es und für was kann man es benutzen?). Mehrfachzeilen sind hier erlaubt. Dieses Feld wird ohne Zeilenumbruch dargestellt. Deshalb sollten sie manuell Zeilenenden einführen, um die Zeilenlänge, wenn möglich, unter 79 Zeichen zu halten.

Dieses Feld ist für Informationen, die man für die Benutzung des Pakets benötigt (Wie benutze ich es?), z. B. "Führen sie wmaker.inst einmal aus, bevor sie WindowMaker benutzen". Mehrfachzeilen sind hier erlaubt. Dieses Feld wird ohne Zeilenumbruch dargestellt. Deshalb sollten sie manuell Zeilenenden einführen, um die Zeilenlänge, wenn möglich, unter 79 Zeichen zu halten.

Anmerkungen zum Erstellen der Paketbeschreibung. Sachen wie "Patches im Makefile, damit alles an die richtige Stelle gepackt wird." kommen in dieses Feld. Mehrfachzeilen sind hier erlaubt.

Anmerkungen spezifisch für die Portierung des Pakets nach Darwin. Sachen, wie "config.guess und libtool Skripte aktualisiert, -no-cpp-precomp ist nötig" gehören hier her. Mehrfachzeilen sind hier erlaubt.