Available Languages: | Deutsch | English | Français | 日本語 (Nihongo) | 中文 (简) (Simplified Chinese) |

Ein Fink-Paket erstellen

Diese Anleitung beschreibt, wie man eine Paketbeschreibung für den Paketmanager Fink erstellt. Es beschreibt ebenso die Richtlinien für die Fink-Distribution. Sowohl das Format der Paketbeschreibung als auch die Distributionspolitik sind in Entwicklung. Achten sie also auf "Last changed"-Informationen und CVS Tipps zu dieser Seite, wenn es um Aktualisierungen geht. Diese Beschreibung hier bezieht sich auf Formate und Richtlinien für Version 0.9.0 und höher des Paketmanagers Fink.

Beabsichtigen sie Pakete für Fink zu erstellen, ist es sinnvoll die Mailing-Liste fink-devel zu abonnieren. Wenn sie einfach bei Fink mithelfen wollen und sie sich fit fühlen, können sie ein Paket aus dieser Liste übernehmen, das derzeit ohne Betreuer ist.

Contents

1 Einführung

1.1 Was ist ein Paket?

Ein Paket besteht aus Software, die eine abgeschlossene Einheit bildet. Ein typisches Paket enthält ein Program, dafür benötigte Dateien und Kataloge mit Meldungen für die Internationalisierung und Dokumentation. In Fink können Pakete in zwei Formen vorliegen: Die Paketbeschreibung und die binäre, direkt installierbare Paket-Datei.

Die Paketbeschreibung ist eine lesbare Textdatei, die alles enthält, um das Paket zu erstellen, d. h. die binäre Paket-Datei zu erzeugen. Die Paketbeschreibung enthält Meta-Daten (Paketnamen und Beschreibungsprosa), die URL des Quell-Codes und die Instruktionen für die Konfiguration, das Compilieren und das "Einpacken" des Pakets. Zu der Paketbeschreibung kann auch eine Patch-Datei gehören.

Die binäre Paket-Datei is ein Dateiarchiv, das die eigentlichen Dateien des Pakets enthält, also das Binärprogram, Dateien, Kataloge mit Meldungen, Bibliotheken, Include-Dateien, usw. Die Paket-Datei enthält auch Meta-Daten über das Paket. Installation eines binären Pakets bedeutet im wesentlichen Auspacken des Inhalts, weil alles bereits vorbereitet ist. Fink nutzt den Paketmanager dpkg. Deshalb haben die binären Paket-Datei das Format dpkg und den Datei-Suffix .deb.

1.2 Identifikation eines Pakets

Die Identifikation eines Pakets ergibt sich aus drei Zeichnfolgen: Paketname, Version und Revision. Alle können Kleinbuchstaben, Zahlen, Bindestriche (nicht in der Revision), Pluszeichen und Punkte enthalten. Andere Zeichen sind nicht erlaubt. Insbesondere Großbuchstaben und Unterstriche sind nicht erlaubt.

Der Paketname is einfach der Name der Software, z. B. openssh. Die Version, auch Upstream-Version genannt, ist die Version des ursprünglichen Software-Pakets. Buchstaben sind in der Version erlaubt, z. B. 2.9p1. Sowohl Fink als auch dpkg wissen, wie man diese richtig sortiert. Die Revision ist ein Zähler, der erhöht wird, wenn sich die Paketbeschreibung ändert. Sie beginnt mit 1 und sollte auf 1 zurückgesetzt werden, wenn sich die Upstream-Version ändert. Die Revision darf keine Bindestriche enthalten. Der vollständige Name ergibt sich aus der Verkettung der drei mit Bindestrichen dazwischen, z. B. openssh-2.9p1-2.

2 Paketbeschreibungen

2.1 Verzeichnis-Layout

Paketbeschreibungen werden aus dem Verzeichnis finkinfo gelesen, der sich im Verzeichnis /sw/fink/dists befindet. Die Einstellung "Trees" in der Datei /sw/etc/fink.conf bestimmt, welche Verzeichnisse gelesen werden. Der Name der Paketbeschreibungsdatei besteht aus dem vollständigen Paketnamen und dem Suffix ".info". Ab Fink 0.26.0 gibt es mehre Möglichkeiten für den Dateinamen: Empfohlen wird der kürzeste Name, der konsistent mit anderen Paketen ist, die benötigt werden. Der Dateiname hat folgende Form: der unveränderliche Paketname, optional die Architektur, optional die Distribution, optional Version oder Version-Revision, alle durch Bindestriche getrennt und abgeschlossen mit ".info". Die Komponenten "Architektur" und "Distribution" sind nur erlaubt, wenn die entsprechenden Felder auch in der Beschreibung vorkommen und exakt einen Wert zugewiesen haben.

Der Baum der Paketveschreibungen ist in mehreren Ebenen von Verzeichnissen organisiert. Die Verzeichnisse von oben nach unten:

2.2 Datei-Format

Die Paketbeschreibungsdateien sind einfache Listen von Schlüssel-Wert-Paaren, auch Felder genannt. Jede Zeile beginnt mit einem Schlüssel, der mit einem Doppelpunkt (:) abgeschlossen wird. Darauf folgt direkt der Wert, also so:

Schlüssel: Wert

Es gibt zwei Schreibweisen für Felder, die sich über mehrere Zeilen erstrecken.

Die bevorzugte Schreibweise is so wie die here-document-Syntax in Shell-Skripten. Bei dieser Syntax beginnt die erste Zeile mit dem Schlüssel, gefolgt von << als Wert. Alle nachfolgenden Zeilen werden als eigentlicher Wert behandelt bis eine Zeile folgt, die nur << enthält. Das Beispiel von oben sieht nun so aus:

InstallScript: <<
mkdir -p %i/share/man
make install prefix=%i mandir=%i/share/man
mkdir -p %i/share/doc/%n
install -m 644 COPYING %i/share/doc/%n
<<

Einrückungen in diesem Format sind optional, können aber für eine erhöhte Lesbarkeit verwendet werden.

Die here-document-Syntax kann verschachtelt sein. Dies wird oft in den Feldern SplitOff oder SplitOffN verwendet. Diese Felder enthalten weitere Felder (mehrere Zeilen) und diese Syntax erlaubt, dass auch diese Unterfelder ihrerseits mehrere Zeilen hat. Derselbe Abschluss mit << wird bei dem sub-here-document benutzt. Hier ein Beispiel:

SplitOff: <<
  Package: %N-shlibs
  InstallScript: <<
    ln -s %p/lib/libfoo.2.dylib %i/lib/libfoo.%v.dylib
  <<
<<

In diesem Format werden Leerzeilen und Zeilen mit einem Hash (#) am Zeilenanfang ignoriert. Groß-und Kleinschreibung wird beim Schlüssel (Feldnamen) nicht beachtet, d. h. man kann InstallScript, installscript oder INSTALLSCRIPTschreiben, wie man will. Allerdings wird die erste Form mit Großbuchstaben wegen Lesbarkeit empfohlen. Einige Felder akzeptieren boolesche Werte. Hier werden "true", "yes", "on" und "1" (auch in Großschreibung) als wahr interpretiert, alle anderen Werte als falsch.

2.3 Prozent-Erweiterungen

Zur Vereinfachung unterstützt Fink einen Satz an Erweiterungen, die in einigen Feldern angewendet werden. Mehrdeutigkeiten kann man verhinder, indem man mit geschweiften Klammern genau anzeigt, welche Buchstaben für eine Prozent-Erweiterung genommen werden sollen. %{n} hat zum Beispiel die gleiche Bedeutung wie %n. Folgende Erweiterungen stehen zur Verfügung:

%n

Der name des Pakets

%N

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

%e

Die epoche des Pakets

%v

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

%V

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.

%r

Die revision des Pakets

%f

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

%p, %P

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

%d

Im Verzeichnis destination wird der Baum für ein Paket erstellt, z. B. in /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 /sw/etc/fink.conf ändern.

%D

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

%i

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

%I

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

%a

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.

%b

Das Verzeichnis build, also /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 /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.

%c

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

%m

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)

%type_raw[type], %type_pkg[type], %type_num[type]

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

%{ni}, %{Ni}

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.

%{default_script}

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)

%{PatchFile}

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

%{PatchFileN}

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

%lib

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.

3 Richtlinien zur Estellung von Paketen

3.1 Paket-Lizenzen

Die Pakete in Fink stehen unter sehr verschiedenen Lizenzen. Die meisten beinhalten Restriktionen im Hinblick auf Weiterverteilung der kompletten Quellen und vor allem der Binärprogramme. Einige Pakete können wegen solcher Restriktionen nicht Teil von Finks Binär-Distribution sein. Deshalb ist es sehr wichtig, dass man als Betreuer eines Pakets die Lizenzen seines Pakets sorgfältig prüft.

Jedes Paket, das als Binärpaket verteilt werden soll, muss eine Kopie der Lizenz enthalten. Die Kopie muss im Verzeichnis doc installiert werden, also in %p/share/doc/%n. (Im InstallScript muss natürlich %i anstelle von %p verwendet werden. Das Feld DocFiles erledigt dies automatisch.) Gibt es keine explizite Lizenz in den originalen Quellen, fügen sie eine kleine Textdatei bei, in der sie die Situation des pakets beschreiben. Die meisten Lizenzen verlangen, dass jede Distribution die Lizenz enthält. Finks Richtlinien ist, dies immer zu tun, auch wenn es nicht explizit verlangt wird.

Für die automatische Verwaltung der binären Distributions ist es erforderlich, dass jedes Paket, das damit verteilt werden soll, auch das Feld License gesetzt hat. Dieses Feld beschreibt die Art der Lizenz und entscheidet darüber, ob ein Paket in die binäre Distribution aufgenommen wird oder zurück gehalten wird. Das Feld soll auch nur präsent sein, wenn das binäre Paket auch den eigentlichen Text der Lizenz enthält, wie oben beschrieben.

Das Feld License ist nur brauchbar, wenn einer der folgenden vordefinierten Werte benutzt wird. Erstellen sie ein Paket, das nicht in eine dieser Kategorien fällt, dann fragen sie auf der developer Mailing-Liste um Hilfe.

3.2 Die GPL und OpenSSL

(Änderung der Richtlinien ab April 2005.)

Wegen einer offensichtlichen Inkompatibilität zwischen der OpenSSL-Lizenz und den GPL- und LGPL-Lizenzen werden Pakete, die OpenSSL-Bibliotheken linken aber unter der GPL- oder LGPL-Lizenz stehen, als "Restrictive" klassiert. Als Konsequenz davon wird das Fink-Projekt solche Pakete nicht als Binär-Pakete anbieten, obwohl es Nutzern frei steht, die Pakete aus den Quellen zu erstellen.

Paket-Betreuer sind aufgefordert, die Original-Lizenz des Pakets im Feld DescPackaging zu vermerken.

3.3 Störungen des Basis-Systems

Fink ist eine zusätzliche Distribution, die in einem extra Verzeichnis, getrennt vom Basis-System (OS X) installiert wird. Es ist von von entscheidender Bedeutung, dass ein Paket keine Dateien außerhalb von Finks Verzeichnis installiert.

Ausnahmen können nur dann gemacht werden, wenn es wirklich nicht anders möglich ist, z. B. bei XFree86. In diesen Fällen muss das Paket vor der Installation überprüfen, ob Dateien vorhanden sind und die Installation verweigern, wenn es vorhandene Dateien überschreiben würde. Das Paket muss auch sicher stellen, dass alle Dateien, die außerhalb von Finks Verzeichnis installiert werden, auch wieder gelöscht werden, wenn das Paket entfernt wird oder dass sie keinen Schaden verursachen, wenn sie verbleiben (d. h., dass sie die Präsenz von Programmen überprüfen müssen, bevor sie sie aufrufen und ähnliches).

3.4 Dynamische Bibliotheken

Im Februar 2002 traten Finks Richtlinien zu dynamischen Bibliotheken in Kraft. Dieser Abschnitt der Dokumentation beschreibt die Version 4 dieser Richtlinien (die mit der Veröffentlichung von Finks 0.5.0 Distribution zusammen fällt.), wie im Dezember 2006 modifiziert um 64-bit Bibliotheken und im Januar 2008 um private Bibliotheken zu behandeln. (Außerdem wurde die Diskussion im Juni 2008 aktualisiert, um veraltete Referenzen zu löschen, die aus einer Übergangszeit stammte, in der die Richtlinien zu dynamischen Bibliotheken implementiert wurde.) Wir beginnen mit einer kurzen Zusammenfassung und werden die Details danach diskutieren.

Jedes Paket, das dynamische Bibliotheken erstellt, sollte Finks Richtlinien dazu einhalten. Das bedeutet:

Beachten sie bitte, dass ein Paket auch private dynamische Bibliotheken installieren kann, die nicht von andern Paketen verlinkt werden sollen. In diesem Fall müssen die Bibliotheken in ein extra Paket, das aver ebenfalls das Feld Shlibs haben muss. Außerdem sollte man vermeiden, einen finalen Link von der libfoo.dylib in das Haupt-Bibliotheksverszeichnis %i/lib (oder seinem 64-bit Äquivalenz) zu legen. So soll verhindert werden, dass diese Bibliothek unabsichtlich verlinkt wird.

Sollte ein Paketbetreuer gute Gründe haben, von dieser Richtlinie abzuweichen, sollten diese im Feld DescPackaging: eingetragen werden.

Für einige Pakete kann alles mit einem Hauptpaket und einem -shlibs-Paket gelöst werden. In anderen Fällen braucht man noch mindestens ein drittes Paket. Mit dem neuen Feld SplitOff geht das recht leicht.

Werden drei Pakete benötigt, kann man sie auf zwei Arten benennen, je nachdem ob die Bibliotheken (Option 1) oder die Binärprogramme (Option 2) das wichtigste am Paket sind. Bei Option 1 sieht das Layout so aus:

PackageContents
foo-shlibs

Dynamische Bibliotheken

foo

Header-Dateien

foo-bin

Binärprogramme, usw.

während bei Option 2 das Layout so aussieht:

PackageContents
foo-shlibs

Dynamische Bibliotheken

foo-dev

Header-Dateien

foo

Binärprogramme, usw.

Die Richtlinien im Detail

Wir werden nun die Dinge im Detail diskutieren. Als Beispiel können sie sich die Pakete libpng, libjpeg und libtiff anschauen.

Software, die nach Darwin oder OS X portiert wird, sollte wenn immer auch möglich dynamische Bibliotheken erstellen. (Paketbetreuern steht es frei, auch statische Bibliotheken zu erstellen, wenn das für ihr Paket angemessen ist oder auch ein Paket zu erstellen, das nur statische Bibliotheken enthält.) Immer wenn dynamische Bibliotheken erzeugt werden, von denen man erwartet, dass sie von anderen Paketen benutzt werden, sollten zwei Pakete mit den Namen foo und foo-shlibs erstellt werden. Die dynamische Bibliotheke gehört in foo-shlibs und die Header-Dateien in foo. Beide Pakete können in einer Datei foo.info mit Hilfe des Felds SplitOff erzeugt werden, wie weiter unten beschrieben. (Tatsächlich müssen oft mehr als zwei Pakete aus den Quellen erzeugt werden. Das kann leicht über die Felder SplitOff2, SplitOff3 usw. erreicht werden.)

Jedes Softwarepaket mit dynamischen Bibliotheken braucht eine Hauptversionsnummer N, die in den Namen der Bibliothek eingefügt wird (z. B. libbar.N.dylib). Diese Hauptversionsnummer soll sich nur ändern, wenn sich die API der Bibliothek so ändert, dass sie nicht mehr rückwärts-kompatibel ist. Fink benutzt folgende Konvention für die Namensgebung: Ist der Upstream-Name bar, erhalten die Fink-Pakete die namen barN und barN-shlibs. (Diese Regel gilt streng nur für neue Pakete und Pakete, bei denen sich die Hauptversionsnummer ändert.) Ist z. B. die Hauptversionsnummer des vorliegenden Pakets libpng eine 2 und die Nummer der neuen Version eine 3, dann macht man daraus folgende vier Pakete: libpng, libpng-shlibs, libpng3 und libpng3-shlibs. Nur jeweils eines der Pakete libpng oder libpng3 kann installiert sein. (Beachte, dass nur zwei2 .info-Dateien für die vier Pakete benötigt werden.)

Die eigentliche dynamische Bibliothek und einige dazu gehörige Dateien kommen in das Paket barN-shlibs. Die "include" und andere Dateien kommen in das Paket barN. Diese beiden Paketen haben keine gemeinsamen Dateien und alle Dateien in barN-shlibs müssen die Hauptversionsnummer in Namen ihres Pfades haben. In vielen Fällen braucht das Paket zur Laufzeit Dateien, die typischerweise in %i/lib/bar/ oder %i/share/bar/ installiert sind. Sie sollten deshalb die Installationspfade auf %i/lib/bar/N/ oder %i/share/bar/N/ einstellen.

Alle anderen Pakete, die von bar mit der Hauptversionsnummer N abhängen, brauchen folgende Felder:

  Depends: barN-shlibs
  BuildDepends: barN

Es ist für andere Pakete nicht erlaubt, direkt von barN abzuhängen. (Auch wenn es noch einige Pakete mit solchen Abhängigkeiten aus der Zeit vor Februar 2002 geben kann). Dies wird in der Paketbeschreibung von barN mit dem boolschen Feld BuildDependsOnly an die Betreuer anderer Pakete signalisiert:

  BuildDependsOnly: True

Enthält ihr Paket sowohl dynamische Bibliotheken und Binärdateien und die Binärdateien werden zur Laufzeit benötigt und nicht nur bei der Erzeugung des Pakets, dann müssen die Binärdateien zusätzlich zum Paket barN-shlibs in ein drittes Paket mit dem Namen barN-bin gepackt werden.

Erstellt man eine dynamische Bibliothek mit der Hauptversionsnummer N, ist es wichtig, dass der "install_name" der Bibliothek %p/lib/libbar.N.dylib ist. (Sie können den "install_name" mit dem Befehl otool -L oder otool64 -L für 64-bit Bibliotheken auf 10.4 heraus finden.) Die tatsächliche Bibliothek kann an einer anderen Stelle installiert sein.

  %i/lib/libbar.N.x.y.dylib

und ihr Paket erzeugt symbolische Links:

  %i/lib/libbar.N.dylib -> %p/lib/libbar.N.x.y.dylib
  %i/lib/libbar.dylib -> %p/lib/libbar.N.x.y.dylib

aus dem install_name-Pfad und vom linking-Pfad zu der tatsächlichen Bibliothek. (Das erste wird nicht benötigt, wenn die Bibliotheke tatsächlich beim install_name-Pfad installiert ist, was zunehmend der Fall ist.)

Wird auch eine statische Bibliothek erzeugt, wird sie hier installiert:

  %i/lib/libbar.a

Verwendet das Paket libtool, wird dies alles automatisch erledigt, aber man sollte auf jeden Fall überprüfen, dass dies auch korrekt gemacht wurde. Sie sollten auch überprüfen, ob die current_version und die compatibility_version für ihre dynamischen Bibliotheken richtig definiert wurden. (Diese werden ebenso mit den Abfragen otool -L oder otool64 -L für 64-bit Bibliotheken angezeigt.)

Die Dateien wird wie folgt zwischen den beiden Paketen aufgeteilt:

Beachten sie, dass beide Pakete die Dokumentation zu ihren Lizenzen benötigen, die Verzeichnisse mit den DocFiles aber unterschiedlich sind.

Das macht man in der Praxis am einfachsten mit dem Feld SplitOff. Das folgende Beispiel zeigt die wichtigsten Teile:

Package: barN
Version: N.x.y
Revision: 1
License: GPL
Depends: barN-shlibs (= %v-%r)
BuildDependsOnly: True
DocFiles: COPYING
SplitOff: <<
  Package: barN-shlibs
  Files: lib/libbar.N.x.y.dylib lib/libbar.N.dylib lib/bar/N
  DocFiles: COPYING
<<

Bei der Bearbeitung des Felds SplitOff werden die angegebenen Dateien und Verzeichnisse aus dem Installationsverzeichnis %I des Hauptpakets in das Installationsverzeichnis %i des SplitOff-Pakets verschoben. (Die Konvention für Namen ist ähnlich: %N ist der Name des Hauptpakets und %n der Name des aktuellen Pakets.) Das Feld/Kommando DocFiles kopiert die Dokumentationsdateien in das Verzeichnis %i/share/doc/barN-shlibs.

Beachten sie, dass die exakte Version von barN-shlibs als Abhängigkeit im Hauptpaket barN steht (das mit %N-shlibs (= %v-%r) abgekürzt werden kann). Damit wird sicher gestellt, dass die Versionen passen und dass das Paket barN automatisch alle Abhängigkeiten von barN-shlibs "erbt".

Das Feld BuildDependsOnly

Werden Bibliotheken im Laufe der Zeit aktualisiert, ist es oft notwendig, zwei Versionen der Header-Dateien während der Übergangsphase zur Verfügung zu haben. Eine Version für das Übersetzen von dem einen und eine für das Übersetzen von etwas anderem. Deshalb muss man bei der Erstellung der Pakete etwas aufpassen. Enthalten die Pakete foo-dev und bar-dev überlappende Header, dann muss in foo-dev folgendes deklariert werden:

  Conflicts: bar-dev
  Replaces: bar-dev

und genau so, aber umgekehrt, in bar-dev.

Darüber hinaus sollten beide Pakete das Feld BuildDependsOnly gesetzt haben.

  BuildDependsOnly: True

Dies verhindert, dass man Pakete erstellt, die von foo-dev oder bar-dev abhängen, denn so etwas würde das problemlose Funktionieren des Methode Conflicts/Replaces verhindern.

Es gibt manche Pakete mit Header-Dateien, für die es nicht in Ordnung ist, BuildDependsOnly als wahr zu setzen. In diesen Fällen sollten sie das Feld explizit auf falsch setzen:

  BuildDependsOnly: False

und den Grund dafür im Feld DescPackaging angeben.

Das Feld BuildDependsOnly sollte nur bei solchen Paketen stehen, die Header-Dateien in %i/include (oder einem Unterverzeichnis) installieren.

Ab Fink 0.20.5 erzeugt der Befehl "fink validate" eine Warnung für jede .deb-Datei, die Header-Dateien und mindestens eine dynamische Bibliothek enthält und das Feld BuildDependsOnly weder auf wahr noch falsch setzt. (Es ist durchaus möglich, dass Fink in Zukunft dies auf Fälle von .deb-Dateien ausdehnt, die Header-Dateien und statische Bibliotheken enthält.)

Das Ziel der Reichtlinien über dynamische Bibiliotheken ist, dass die Kompatibilität zwischen den Bibliotheken un dProgrammen in verschiedenen Paketen gewährleistet ist. Manche Pakete können Bibliotheken enthalten, die gar nicht dafür gedacht sind, von anderne Programmen benutzt zu werden. Ein häufige Situation ist, dass eine Gruppe von Programmen eine Backend-Bibliothek mit Hilfsprogrammen haben oder ein Programm, das mehrere Plugins für bestimmte Features hat. Da diese Bibliotheken quasi privat für das Paket sind, braucht man dafür kein extra SplitOff -shlibs und auch kein BuildDependsOnly.

Das Feld Shlibs

Zusätzlich dazu, dass dynamische Bibliotheken in ein extra Paket gehören, müssen ab Version 4 dieser Richtlinien alle dynamische Bibliotheken im Feld Shlibs eingetragen werden. Dieses Feld hat für jede dynamische Bibliothek nur eine Zeile mit dem -install_name der Bibliothek. 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. Das folgende Beispiel

  Shlibs: <<
  %p/lib/libbar.1.dylib 2.1.0 bar1 (>= 1.1-2) 32
  <<

ist eine (32-bit) Bibliothek mit dem -install_name %p/lib/libbar.1.dylib und der -compatibility_version 2.1.0, die in der Version 1.1-2 des Pakets bar1 zum ersten Mal angeboten wurde. Außerdem impliziert die Deklaration, dass der Betreuer versichert, dass auch in späteren Versionen des Pakets bar1 eine 32-bit Bibliothek mit diesem Namen und einer Kompatibilitätsversion von mindestens 2.1.0 angeboten wird.

Beachten sie die Verwendung von %p im Pfad der Bibliothek. Dadurch wird der richtige -install_name von allen Finknutzern gefunden, egal ob sie /sw oder einen anderen Präfix für Fink ausgewählt haben.

Wird ein Paket aktualisiert, kann meistens das Feld Shlibs einfach in die nächste Version/Revision des Pakets kopiert werden. Nur wenn sich die Kompatibilitätsversion erhöht, muss die Versionsnummer in der Abhängigkeit auf die aktuelle Version/Revision geändert werden, denn hier muss die Version/Revision stehen, in der die neue Kompatibilitätsversion der Bibliothek zum ersten Mal angeboten wird.

Für private Bibliotheken ist die Syntax für den Eintrag im Feld Shlibs eine andere:

  Shlibs: <<
    !%p/lib/%N/libbar.1.dylib
  <<

Das Ausrufungszeichen am Anfang steht für private Bibliothek. Weitere Informationen über die Bibliothek sind nicht relevant und werden deshalb weg gelassen.

Beachten sie, dass in diesem Beispiel die private Bibliothek in ein eigenes Unterverzeichnis %N (das nach dem Namen des Pakets benannt wurde) des Verzeichnisses %i/lib verschoben wird. Dies ist unsere Empfehlung als zusätzlicher Schutzmechanismus, der verhindert, dass andere Pakete diese Bibliothek aus Versehen verlinken.

Was muss ich machen, wenn sich die Nummer der Hauptversion ändert?

Ändert sich die Nummer der Hauptversion von N auf M, muss man zwei neue Pakete barM und barM-shlibs erstellen. Das Paket barM-shlibs darf keine gemeinsamen Dateien mit dem Paket barN-shlibs haben, weil viele Nutzer die beiden Pakete gleichzeitig installieren werden. Im Paket barM sollte man folgende Abhängigkeiten deklarieren:

  Conflicts: barN
  Replaces: barN

Im Paket barN muss man in entsprechender Weise, also umgekehrt, folgendes einfügen

  Conflicts: barM
  Replaces: barM

Bei der Erstellung von anderen Paketen werden die Pakete barN und barM ausgetauscht, je nachdem, welches von den beiden benötigt wird. Die Pakete barN-shlibs und barM-shlibs bleiben hingegen die ganze Zeit installiert.

Pakete mit Bibliotheken und Binärdateien:

Enthält eine Upstream-Paket gleichzeitig Binärdateien und öffentliche Bibliotheken, muss man bei der Erstellung der Finkpakete aufpassen. Manchmal sind die Binärdateien lediglich foo-config, die nur in der Erstellungs-Phase des Pakets benötigt werden und nie zur Laufzeit. In solchen Fällen können diese Dateien zusammen mit den Header-Dateien in das Paket foo.

In anderen Fällen werden die Binärdateien von anderen Paketen auch zur Laufzeit benutzt. Dann müssen sie in ein separates Finkpaket abgetrennt werden, das man z. B. foo-bin nennen kann. Das Paket foo-bin sollte vom Paket foo-shlibs abhängen. Betreuer anderer Pakete sollten aufgefordert werden, die Abhängigkeit von foo-bin in ihrem Paket zu deklarieren:

  Depends: foo-bin
  BuildDepends: foo

Damit ist die Abhängigkeit von foo-shlibs implizit enthalten.

Allerdings ist die Aktualisierung in dieser Situation ein Problem, denn ein Nutzer wird nicht aufgefordert werden, das Paket foo-bin zu installieren. Eine Lösung, bis alle anderen Paketbetreuer ihre Pakete wie oben beschrieben aktualisiert haben, können sie folgende Abhängigkeit in ihrem Paket foo deklarieren:

  Depends: foo-shlibs (= exact.version), foo-bin

Dies erzwingt die Installation des Paket foo-bin auf den meisten Systemen, solange bis die anderen Paketbetreuer ihre Pakete, die von foo abhängen, aktualisiert haben.

Ab Fink 0.28.0 (veröffentlich im Januar 2008) hat sich das Format für einen Eintrag im Feld Shlibs für private dynamische Bibliotheken geändert. (Beachten sie bitte die obigen Erläuterungen zu den Unterschieden zwischen privaten und öffentlichn dynamischen Bibliotheken.) Die Richtlinien für dynamische Bibliotheken war schon immer so, dass alle dynamische Bibliotheken aufgezählt werden müssen. Die Änderung betrifft nur das Feld Shlibs. Da private Bibliotheken nicht von anderen Paketen benutzt werden, ist es auch nicht notwendig, die Kompatibilitätsversion oder andere Versionsinformationen anzugeben. Statt dessen wird ein Ausrufungszeichen verwendet. Ist z. B. libquux.3.dylib der install_name einer privaten dynamischen Bibliothek, würde sie so aufgelistet werden:

  Shlibs: <<
    !%p/lib/libquux.3.dylib
  <<

3.5 Perl-Module

Die erste Version von Finks Richtlinien zu Perl-Modulen wurde im Mai 2003 implementiert und erhielt im April 2004 die erste Revision.

Ursprünglich hatten Fink-Pakete für Perl-Module den Suffix -pm und wurden mit der Direktive Type: perl erstellt. Damit wurden die Dateien der Module in /sw/lib/perl5 und/oder /sw/lib/perl5/darwin abgespeichert. Nach den aktuellen Richtlinien gilt dies nur noch für Module, die unabhängig von der Perlversion übersetzt wurden und die auch nicht von anderen versionsabhängigen Modulen abhängen.

Versionsabhängige Perl-Module sind die sogenannten XS-Module, die oft übersetzten C Code und Perl-Routinen enthalten. Man kann sie auf verschiedene Weisen erkennen, z. B. daran, die sie eine datei mit dem Suffix .bundle enthalten.

Ein versionsabhängiges Perl-Modul muss mit einer bestimmten binären Version von Perl erstellt werden, z. B. perl5.12.3. Die erzeugten Dateien müssen dann in einem versionierten Unterverzeichnis des Standard-Perlverzeichnisses abgespeichert werden, z. B. /sw/lib/perl5/5.12.3 und /sw/lib/perl5/5.12.3/darwin. Es ist Konvention, die Pakete mit dem Suffix -pm5123 zu benennen, wenn sie für die Version 5.12.3 von Perl erstellt wurden. Entsprechende Konventionen für das Abspeichern und die Namen von Modulen sind perl 5.10.0 (nur für 10.6), perl 5.12.4 (but für 10.7) und perl 5.16.2 (nur für 10.7).

Die Direktive Type: perl 5.12.3 führt automatisch dazu, dass das versionierte binäre Perl verwendet wird und speichert die Dateien in den richtigen Unterverzeichnissen ab. (Diese Direktive steht in Fink ab der Version 0.13.0 zur Verfügung.)

Die Richtlinien vom Mai 2003 erlaubten es, ein Paket -pm zu erstellen, das eigentlich ein Paket-"Bündel" ist, das die Variante -pm560 oder je nach Verfügbarkeit eine andere lädt. Die Richtlinien vom April 2004 raten davon ab und nach einer Übergangsphase wurde diese Möglichkeit komplett verboten.

Ab der Version 0.20.2 von Fink stellt das Paket system-perl automatisch bestimmte Perl-Module zur Verfügung, je nach Version von system-perl. Der Code, mit der die Liste erstellt wird, steht in der Datei VirtPackage.pm, die Bestandteil des Pakets fink ist.

Da verschiedene system-perl unterschiedliche Module zur Verfügung stellen, wird Paketbetreuern empfohlen, dass sie die Liste überprüfen, wenn sie eines der Perl-Module verwerden.

Ab der Version 0.13.0 von Fink überprüft das Kommando fink validate bei einer .deb-Datei, ob das Finkpaket ein XS-Module ist, das in einem nichtversionierten Verzeichnis abgespeichert ist und gibt eine entsprechende Warnung aus.

Nutzer können mehrere Versionen von Perl gleichzeitig installiert haben. Deshalb müssen versionsabhängige Modulpakete so geschireben sein, dass mehrere Versionen des Pakets installiert sein können. Besondere aufpassen muss man bei der Installation von man-Pages und binären oder anderen Programmen, damit wegen Namenskollissionen keine Installationskonflikte auftreten. Man darf in einem Paket, dessen Namen auf -pmXYZ endet, keine Dateien haben, die für verschiedene XYZ die gleichen Pfadnamen haben. Auch ein Replaces für das einfache Überschreiben der Dateien wird nicht mehr akzeptiert. Ab März 2005 definiert Fink als einfache Lösung zusätzliche Plätze im MANPATH: %p/lib/perl5/X.Y.Z/man für jedes perl-X.Y.Z. Deshalb muss man keine extra SplitOff-Pakete -man oder -doc mehr erstellen, die sich jeweils gegenseitig ausschließen. Die Konflikte zwischen uri-pm5124 und uri-pm5162 werden z. B. so aufgelöst, dass die gleich man-Page URI.3pm jeweils unter %p/lib/perl5/5.12.4/man/man3/URI.3pm oder %p/lib/perl5/5.16.2/man/man3/URI.3pm abgespeichert wird. Beachten sie bitte, dass sich die Standard-Skripte für Type: perl X.Y.Z nicht geändert haben und man deshalb die man-Pages selbst im InstallScript suchen muss. Ist das Skript nicht hochgradig kompliziert, dann kann man das Standard-Skript verwenden und die Dateien einfach mit mv verschieben:

%{default_script}
mv %i/share/man %i/lib/perl5/5.12.4

Dies verschiebt alle man-Pages. Will man nur einen Abschnitt der man-Pages verschieben (z. B. nur Abschnitt 3, die man-Pages für die Module und nicht die man-Pages für Skripte in Abschnitt 1), funktioniert folgendes:

%{default_script}
mkdir -p %i/lib/perl5/5.12.4/man
mv %i/share/man/man3 %i/lib/perl5/5.12.4/man

Hat man Programme, z. B.Demo- und Hilfs-Skripte, in %p/bin, gibt es mehrere Optionen. Eine ist, die Dateien zusammen mit den dazugehörigen man-Pages und so weiter in ein SplitOff-Paket %N-bin zu packen. Mit den Feldern Conflicts und Replaces muss man für den gegenseitigen Austausch bei der Installation der Dateien für verschiedene Perlversionen sorgen. Der Nutzer kann viele verschiedene Perlversionen der Laufzeit-Module installieren und dann zu einer bestimmten Zeit die gewünschte Perlversion des Skripts auswählen. Das Paket Tk.pm kommt z. B. mit dem Programm ptksh. Der Satz an tk-pm* Paketen kann man wie folgt erzeugen:

Info2: <<
Package: tk-pm%type_pkg[perl]
Type: perl (5.12.3 5.12.4 5.16.2)
InstallScript: <<
  %{default_script}
  mkdir -p %i/lib/perl5/%type_raw[perl]/man
  mv %i/share/man/man3 %i/lib/perl5/%type_raw[perl]/man
<<
SplitOff: <<
  Package: %N-bin
  Depends: %N
  Conflicts: %{Ni}5.12.3, %{Ni}5.12.4, %{Ni}5.16.2
  Replaces: %{Ni}5.12.3, %{Ni}5.12.4, %{Ni}5.16.2
  Files: bin share/man/man1
<<
<<

Die andere Option ist die Skripte und ihre man-Pages so umzubenennen, dass die Namen die Perlversion enthalten. Bei dieser Optione kommt es erst gar nicht zu einem Namenskonflikt, so dass die %N-bin SplitOffs sich nicht gegenseitig ausschließen müssen:

Info2: <<
Package: tk-pm%type_pkg[perl]
Type: perl (5.12.3 5.12.4 5.16.2)
InstallScript: <<
  %{default_script}
  mkdir -p %i/lib/perl5/%type_raw[perl]/man
  mv %i/share/man/man3 %i/lib/perl5/%type_raw[perl]/man
  mv %i/bin/ptksh %i/bin/ptksh%type_raw[perl]
  mv %i/share/man/man1/ptksh.1 %i/share/man/man1/ptksh%type_raw[perl].1
<<
<<

Der Nutzer kann jederzeit das ptksh für ein bestimmtes Perl benutzen. Besonders komfortabel für die Nutzer ist es, mit update-alternatives den Aufruf auch mit dem allgemeinen Namen ohne Perlversion zu ermöglichen.

Ab März 2005 wurde auch der Platz für die man-Pages und die Module, die vom Finkpaket für Perl selbst (also die Pakete perlXYZ und perlXYZ-core mit Versionen, die vom der von Apple abweichen) geändert. Deshalb sollten andere Finkpakete die aktualisierte Versionen von core-Perl-Modulen anbieten, die Pakete perlXYZ oder perlXYZ-core nicht in ihrem Feld Replaces auflisten.

3.6 Emacs-Richtlinien

Das Finkprojekt hat entschieden, den Richtlinien des Debianprojekts zu Emacs zu folgen mit wenigen kleinen Unterschieden. (Das Dokument zu den Debian-Richtlinien gibt es hier: http://www.debian.org/doc/packaging-manuals/debian-emacs-policy.) Es gibt zwei Unterschiede bei den Richtlinien von Fink. Erstens gelten die Richtlinien derzeit nur für die Pakete emacs21, emacs22 und emacs23 und nicht für das Paket xemacs. (Dies kann sich eines Tages ändern.) Zweitens dürfen Finkpakete im Gegensatz zu den Debian-Richtlinien Dateien direkt im Verzeichnis /sw/share/emacs/site-lisp installieren

3.7 Quelldateien-Richtlinien

Quelldateien sollen normalerweise von da herunter geladen werden, wo Upstream-Entwickler sie anbieten. Jegliche Modifikation für das Finkpaket sollte mit Patch-Dateien und/oder Patch-Skripten erfolgen. Man sollte also nicht die Quelldateien abändern und im Finkpaket ein Archiv mit den geänderten Dateien als Source verwenden.

Wird ein vcs Checkout verwendet (z. B. git oder svn), weil z. B. das Projekt keine formalen Releases veröffentlicht oder eine wichtige Problemlösung zwischen den Releases eingepflegt wurde, kann eine akzeptable Quelle auf folgende Art und Weise erzeugt werden:

  1. Führen sie ein Checkout des Pakets durch, vorzugsweise zu einer dezidierten Revision des VCS.
  2. Erstellen sie ein Archiv aus dem VCS-Checkout (z. B. ein zip, tar, tar.gz oder tar.bz2).

    Geben sie dem Tarball eine eindeutige Version. Sie können die VCS-Revision verwenden, wenn es überhaupt keine Releases des Pakets gibt, z. B. foo-0svn1234.tar.gz oder bar-1.2.3+svn4567.tar.bz2 für eine Version zwischen zwei Releases.

  3. Nutzen sie die gleiche Version in ihrer .info-Datei.
  4. Es ist äußerst hilfreich, die Kommandos für die Erzeugung des Quelldatei-Tarballs im Feld DescPackaging zu dokumnetieren.
  5. Laden sie den Tarball auf eine öffentliche Download-Seite hoch, wo Nutzer sie mit fink herunter laden können. Haben sie keinen entsprechenden Zugang, fragen sie in der Fink developers Mailing-Liste oder im IRC channel #fink. nach und ihnen wird sicher geholfen werden.

3.8 Datei-Download-Richtlinien

Pakete dürfen in den Phasen unpack, patch, compile, install oder den build Phasen während des build-Prozess keinerlei Dateien herunter laden. Alle größeren Patches (also alles, was man nicht in einer üblichen Patchdatei unterbringen kann) sollten als zusätzliche Quelldateien entsprechend den Quelldatei-Richtlinien aufgesetzt werden.

Unter bestimmten, eng umrissenen Umständen dürfen Pakete im PostInstScript Dateien herunter laden, nachdem sie installiert sind:

Sind sie sich nicht sicher, dann schicken sie eine Email an das Fink Core Team.

4 Dateisystem-Layout

Die folgenden Richtlinien für das Layout der Dateiverzeichnisse sind Bestandteil der Paket-Richtlinien von Fink.

4.1 Hierarchie-Standard für Dateiverzeichnisse

Fink folgt dem Geist des Hierarchie-Standards für Dateiverzeichnisse, abgekürzt als FHS (Filesystem Hierarchy Standard). Es kann diesen Standard nur nachempfinden, denn er setzt die Kontralle über / und /usr voraus. Fink ist aber ein Zusatz, der nur die Kontrolle über sein eigenes Installationsverzeichnis hat. Die Beispiele verwenden den voreingestellten Präfix /sw.

4.2 Die Verzeichnisse

Dateien sollten in den Verzeichnissen wie folgt abgespeichert werden:

FieldValue
/sw/bin

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

/sw/sbin

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.

/sw/include

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.

/sw/lib

Dieses Verzeichnis ist für Daten-Dateien und Bibliotheken, die von der Architektur abhängen. Statische und dynamische Bibliotheken gehören direkt in /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. /sw/lib/perl5 oder /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.

/sw/lib/ppc64 /sw/lib/x86_64

Dieses Verzeichnis ist für 64-bit-Bibliotheken auf 32-bit-Systemen, mit /sw/lib/ppc64 für die PowerPC-Architektur und /sw/lib/x86_64 für die i386-Architektur. Bibliotheken, die als "fat" erzeugt wurden, sollten aber in /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 /sw/lib werden.

/sw/share

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

/sw/share/man

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

/sw/share/info

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.

/sw/share/doc

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.

/sw/share/locale

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

/sw/opt

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

/sw/var

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

/sw/etc

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.

/sw/src

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

/sw/Applications

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.

/sw/Library/Frameworks

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

4.3 Was sollte man vermeiden?

Außer den oben genannten Unterverzeichnissen sollte es keine anderen im Verzeichnis /sw geben. Insbesondere die folgenden sind explizit nicht erlaubt: /sw/man, /sw/info, /sw/doc, /sw/libexec und /sw/lib/locale.

5 Compiler

Fink verwendet die gcc-Familie an Compilers wie sie Apple durch die Apple Developer Connection zur Verfügung stellt. Es gibt mehrere Versionen von gcc und normalerweise stehen auf einem Mac OS X System mehr als eine Version zur Verfügung.

Dieses Kapitel erläutert, wie Fink mit den verschiedenen Versionen von gcc umgeht. Weitere Details können in dieser Email an die Fink mailing list nachgelesen werden.

5.1 Compilerversionen

So wie sich gcc entwickelt hat, gab es verschiedene "Distributionen" von Fink, um die damit verbundenen Änderungen und Probleme abzufangen.

Jede Fink-Distribution hat eine Voreinstellung für die gcc und g++ Compiler, von denen jeder Nutzer normalerweise erwartet, dass sie installiert sind. Jeder kann erwarten, dass bei einem direkten Aufruf von "gcc" und "g++" diese Versionen starten. Benötigt man andere Version (z. B. beim Übergang auf eine neue Distribution) muss das Paket in der .info-Datei die benötigte Version des Apple-Compiler explizit angeben. Im Details hängt das von dem Build-System des Pakets ab, aber in dem meisten Fällen können dafür die Felder SetCC und SetCXX verwendet werden. Will man z. B. auf die Version 3.3 des Compiler g++ wechseln dann muss man SetCXX: g++-3.3 eintragen. Überprüfen sie die Ausgabe beim Erstellen des Pakets, ob die richtige Version verwendet wird.

Die Distribution 10.1 geht von der Version 2.95 des Compiler aus, die Distribution 10.2 von der Version 3.2, die Distributionen 10.2-gcc3.3 und 10.3 von der Version 3.3. Für die Distribution 10.4-transitional ist es kompliziert, weil g++-3.3 zusammen mit gcc-4.0 verwendet wird. Die Distributionen 10.4 und 10.5 verwenden gcc-4.0 und g++-4.0. Die Distribution 10.6 verwendet gcc-4.2, während 10.7 bis 10.9 clang and clang++ als Voreinstellung verwenden. Bei 10.9 kommt eine weitere Änderung durch den Übergang von libstdc++ nach libc++ dazu.

Mit der Distribution 10.4-transitional wurde eine neute Methode eingeführt, mit der sicher gestellt wird, dass der richtige g++ Compiler verwendet wird. Während des Compilierens wird das Verzeichnis /sw/var/lib/fink/path-prefix-g++-XXX (wobei xxx die Versionsnummer ist) in der Pfadvariablen PATH eingetragen. In diesem Verzeichnis befinden sich Shellskripte, die dafür sorgen, dass die richtige Version des g++ Compiler aufgerufen wird.

5.2 Die g++ ABI

Die g++ Abi hat sich in der Zeit von OS X dreimal geändert: Sie ist für die Versionen 2.95, 3.1, 3.3 and 4.0 unterschiedlich. Sie sind untereinander nicht kompatibel und jede Bibliothek mit C++ Code, die sie in ihrem Projekt verlinken, muss mit der selben ABI compiliert sein, wie das, was sie gerade compilieren.

Fink dokumentiert die g++ ABI mit dem Feld GCC. Dieses Feld sollte in allen Paketen definiert sein, die die g++ oder c++ Compiler aufrufen. (Es sollte NICHT in Paketen definiert sein, die diese Compiler nicht aufrufen.) Sobald es eine Aktualisierung in der ABI gibt, müssen alle abhängigen Pakete auf ihr GCC Feld überprüft werden. Erst wenn die alle aktualisiert sind, kann auch das Paket selbst aktualisiert werden. Die Versionen der Pakete müssen erhöht werden, damit Nutzer wirklich die richtige, aktualisierten Abhängigkeiten installieren, bevor sie versuchen ihr Paket zu erstellen.

Eine kleine Gruppe an Paketen, die nur von sich selbst abhängen, können auch bei einer Änderung der ABI bei der alten Version bleiben, wenn sie z. B. noch nicht aktualisiert werdden. Werden sie dann aktualisiert, müssen sie alle zusammen mit der richtigen Version der ABI ersetzt werden. Deshalb ist es am besten, dass man die meisten Pakete sofort dann aktualisiert, wenn sich die Distribution ändert.

Fink benutzt das Feld GCC um sicher zu stellen, dass die richtiger Version des g++ Compiler installiert ist. Ist das Feld GCC in einem Paket definiert, überprüft Fink ob der Wert dazu passt, was man für die Version von OS X erwartet, aso 3.3 für die OS X Versionen 10.2 und 10.3 und 4.0 für OS X 10.4 bis OS X 10.9.

6 Referenz

6.1 Der Build-Prozess

Für das Verständnis einiger Felder, muss man einige Details über den Build-Prozess von Fink wissen: Der Build-Prozess besteht aus fünf Phasen: Auspacken, patchen, compilieren, installieren und erstellen (build). Die Pfade des nachfolgenden Beispiel sind für eine Installation in /sw und für das Paket gimp-1.2.1-1.

In der Auspack-Phase wird das Verzeichnis /sw/src/fink.build/gimp-1.2.1-1 erzeugt und der Quell-Tarball oder mehrere darin ausgepackt. Das erzeugt meistens ein Verzeichnis gimp-1.2.1, das die Quellen enthält. Alle folgenden Schritte erfolgen in diesem Verzeichnis, also in /sw/src/fink.build/gimp-1.2.1-1/gimp-1.2.1. Details dieser Phase können über die Felder SourceDirectory, NoSourceDirectory und SourceNExtractDir kontrolliert werden.

In der Patch-Phase werden die Quelldateien gepacht, so dass das Paket auf Darwin/Mac OS X erstellt werden kann. Die Aktionen werden über die Felder UpdateConfigGuess, UpdateLibtool, Patch und PatchScript genau in dieser Reihenfolge ausgeführt.

In der Compile-Phase werden die Quelldateien konfiguriert und compiliert. Normalerweise bedeutet dies, dass das Skript configure mit einigen Parametern und dann das Kommando make ausgeführt werden. Details dazu stehen in der Beschreibung des Felds CompileScript. Sind Tests für die Erstellung aktiviert (ein neues Feature in Fink 0.25, derzeit wird es im Betreuer-Modus aktiviert), wird das Test-Skript direkt nach dem Compile-Skript ausgeführt.

In der Installationsphase wird das Paket in einem temporären Verzeichnis, /sw/src/fink.build/root-gimp-1.2.1-1 (= %d), installiert. (Beachten sie den Teil "root-" im Namen.) Alle Dateien, die normalerweise in /sw installiert würden, werden stattdessen in /sw/src/fink.build/root-gimp-1.2.1-1/sw (= %i = %d%p) installiert. Weitere Details stehen in der Beschreibung des Felds InstallScript.

(In Fink 0.9.9 eingeführt. Man kann mit einer einzigen Paketbeschreibung mehrere Pakete erzeugen, indem man das Feld SplitOff benutzt. Gegen Ende der Installationsphase wird für jedes Paket ein separates Installationsverzeichnis erzeugt und die Dateien dann in das jeweilige Verzeichnis verschoben.)

In der Erstellungsphase wird eine binäre Datei (.deb) aus dem temporären Installationsverzeichnis erzeugt. Diese Phase kann nicht direkt beeinflusst werden, aber diverse Informationen aus der Paketbeschreibung werden verwendet um eine Datei control für dpkg zu erstellen.

6.2 Felder

Die Felder wurden in mehrere Kategorien eingeteilt. Es kann auch sein, dass das eine oder andere Feld nicht beschrieben ist. :-)

Start Daten:

FieldValue
Package

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.

Version

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.

Revision

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.

Architecture

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.

Distribution

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 und 10.9. 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.7, 10.8 und 10.9 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 10.9 (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
    perl 5.18.2:                         10.7, 10.8, 10.9, 10.10

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.

Epoch

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.

Description

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.

Type

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.

License

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.

Maintainer

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>
InfoN

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.

Abhängigkeiten:

FieldValue
Depends

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.

BuildDepends

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.

RuntimeDepends

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.

Provides

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.

Conflicts

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.

BuildConflicts

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.

Replaces

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.

Recommends, Suggests, Enhances

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.

Pre-Depends

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.

Essential

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.

BuildDependsOnly

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.

Auspack-Phase:

FieldValue
CustomMirror

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 /sw/lib/fink/mirror/_keys, Teil der Pakete fink oder fink-mirrors.

Source

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 /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.

SourceN

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.

SourceDirectory

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.

NoSourceDirectory

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

SourceNExtractDir

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.

SourceRename

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 /sw/src/coolapp-1.2.3.tar.gz abgespeichert werden, genau so wie man es erwarten würde.

SourceNRename

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.

Source-MD5

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 /sw/src/apache_1.3.23.tar.gz kann man mit dem folgenden Kommando berechnen (einschließlich der Ausgabe):

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

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

SourceN-MD5

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.

TarFilesRename

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
TarNFilesRename

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.

Patch-Phase:

FieldValue
UpdateConfigGuess

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.

UpdateConfigGuessInDirs

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.

UpdateLibtool

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.

UpdateLibtoolInDirs

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.

UpdatePoMakefile

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 /sw/share/locale landen und nicht in /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 /sw/lib/fink/update) anzeigen lassen.

Patch

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.

PatchFile

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.

PatchFileN

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.

PatchFile-MD5

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)

PatchFileN-MD5

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)

PatchScript

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.

Compile-Phase:

FieldValue
SetENVVAR

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.

NoSetENVVAR

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 .

UseMaxBuildJobs

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.

BuildAsNobody

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.

ConfigureParams

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.

GCC

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.

CompileScript

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.

NoPerlTests

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.

Test-Suites:

FieldValue
InfoTest

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 deklarieren. Die Felder TestSourceN und die entsprechenden Felder TestSourceN-MD5, 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
<<

Installationsphase:

FieldValue
UpdatePOD

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 /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 /sw/lib/perl5/$version/perllocal.pod zu bearbeiten.)

InstallScript

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.

AppBundles

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
JarFiles

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.

DocFiles

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.

Shlibs

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.

RuntimeVars

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 /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 '/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.

SplitOff

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.

SplitOffN

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.

Files

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.

Erstellungsphase:

FieldValue
PreInstScript, PostInstScript, PreRmScript, PostRmScript

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.

ConfFiles

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.

InfoDocs

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.

DaemonicFile

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.

DaemonicName

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

Zusätzliche Angaben:

FieldValue
Homepage

Die URL der Upstream-Homepage des Pakets.

DescDetail

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.

DescUsage

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.

DescPackaging

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.

DescPort

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.

6.3 SplitOffs

Ab Fink 0.9.9 kann eine einzige .info-Datei benutzt werden, um mehrere Pakete zu erstellen. Die Installationsphase beginnt wie üblich mit der Ausführung der Kommandos InstallScript und DocFiles. Ist ein Feld SplitOff oder SplitOffN vorhanden, werden weitere Installationsverzeichnisse angelegt. In den Feldern SplitOff oder SplitOffN werden die neuen Installationsverzeichnisse mit %i abgekürzt, das Installationsverzeichnis des Elternpakets mit %I.

In jedem Feld SplitOff und SplitOffN müssen bestimmte Felder vorhanden sein. Tatsächlich wird eine komplette Beschreibung gespiegelt, bei der nur wenige Felder fehlen. Im folgenden die Felder, die in den Unterbeschreibungen vorkommen können, nach Kategorien sortiert:

%n-%v-%r wird als eindeutiger Bezeichner für ein Paket interpretiert. Deshalb kann man das selbe Paket (mit der gleichen Version und Revision) nicht als SplitOff (oder SplitOffN) deklarieren. Benutzen sie Varianten, müssen sie beachten, dass jede Variante als unabhängiges Paket betrachtet wird. Die folgende Konstruktion ist deshalb verboten:

Package: mime-base64-pm%type_pkg[perl]
Type: perl (5.12.3 5.12.4)
SplitOff: <<
  Package: mime-base64-pm-bin
<<

Während der Installationsphase werden zuerst die Felder InstallScript und DocFiles des Elternpakets ausgeführt. Danach werden die Felder SplitOff und SplitOffN prozessiert. In jedem SplitOff wird seinerseits das Installscript ausgeführt. Das Feld Files bewirkt dann, dass die aufgelisteteten Dateien und Verzeichnisse vom Installationsverzeichnis %I des Elternpakets in das Installationsverzeichnis %i des SplitOff-Pakets. Danach werden die Felder DocFiles und andere Installationsphasen-Felder der SplitOff oder SplitOffN Pakete ausgeführt.

Zu diesem Zeitpunkt wird SplitOff ausgeführt (falls vorhanden) und dann jedes Feld SplitOffN, in der Reihenfolge der Zahl N. Dies kann sich aber in Zukunft ändern. Folgendes Beispiel

SplitOff: <<
  Description: Some header files
  Files: include/foo.h include/bar.h
<<
SplitOff2: <<
  Description: All other header files
  Files: include/*
<<

funktioniert nur weil SplitOff vor SplitOff2 ausgeführt wird. Es ist deshalb besser, die Dateien explizit auf zu listen (oder detailiertere Wildcards benutzen).

Während der Erstellungsphase werden die pre/post install/remove Skripte für jedes SplitOff während der Erstellungsphase des jeweiligen SplitOff konstruiert, je nachdem wie die Skripte für das SplitOff deklariert wurden.

Von jedem erstellten Paket wird verlangt, dass seine Lizenzierung im Verzeichnis %i/share/doc/%n (das %n nimmt für jedes Paket einen anderen Wert an) dokumentiert wird. Beachten sie, dass DocFiles die Dateien kopiert und nicht verschiebt, so dass man identische Kopien der Dokumentation in jedes Paket mehrfach installieren kann.

6.4 Skripte

In den Feldern PatchScript, CompileScript und InstallScript kann man Shell-Skripte deklarieren, die dann ausgeführt werden. Das build-Verzeichnis (%b) ist das aktuelle Verzeichnis, in dem die Skripte ausgeführt werden. Sie sollten immer relative Pfadnamen oder Prozenterweiterungen für Dateien und Verzeichnisse in der Fink-Hierarchie angeben und keine absoluten Pfadnamen. Zwei Formen werden unterstützt.

Dieses Feld kann ein einfache List von Kommandos sein, ähnlich zu einem Shell-Skripte. Die Kommandos werden jedoch mit system() Zeile für Zeile ausgeführt. Setzt man Variablen oder wechselt das Verzeichnis, wirkt sich dies nur für eben diese eine Zeile aus. Beginnend mit einer CVS-Version nach Fink-0.18.2 kann man lange Zeilen wie in Shell-Skripten auf mehrere umbrechen: Ein Backslash (\) am Ende der Zeile ist das Zeichen für die Fortsetzung in der nächsten Zeile.

Alternativ dazu kann man ein komplettes Skript mit einem Interpreter eigener Wahl hier einfügen. Wie in jedem Unix-Skript muss die erste Zeile mit #! anfangen, gefolgt vom kompletten Pfadnamen für den Interpreter und alle benötigten Flags (z. B. #!/bin/csh, #!/bin/bash -ev, usw.). In diesen Fällen wird das komplette Feld *Script in eine temporäre Datei kopiert und dann ausgeführt.

6.5 Patches

Braucht das Paket einen Patch, um für Darwin kompiliert zu werden (oder um mit Fink zu funktionieren), benennen sie die Patch-Datei so wie die Paketbeschreibung nur mit der Extension ".patch" statt ".info" und speichern sie im gleichen Verzeichnis wie der .info-Datei. Geben sie den Namen der Patch-Datei mit einer Zeile wie die folgende an:

PatchFile: %n.patch

(Für Pakette mit Varianten, kann es günstiger sein, %{ni}.patch zu verwenden.) Sie müssen auch die MD5-Summe der Patch-Datei im Feld PatchFile-MD5 angeben und folgendes deklarieren: BuildDepends: fink (>= 0.24.12) (oder eine spätere Finkversion).

Wird das Feld PatchFileN verwendet, ist es üblich, die Datei %n-Zweck-des-Patch.patch zu benennen, damit man das leichter verfolgen kann. Man muss auch das Feld PatchFileN-MD5 angeben und folgendes deklarieren: BuildDepends: fink (>= 0.30.0) (oder eine spätere Finkversion).

Gibt es das Feld PatchFile, wird folgendes Standard-PatchScriptSkript ausgeführt:

PatchScript: patch -p1 < %{PatchFile}

Mit PatchFileN wird folgendes an das obige Standard-PatchScript angehängt:

patch -p1 < %{PatchFileN}

Dieses Standard-PatchScript wird überschrieben, wenn man ein eigenes PatchScript deklariert (z. B. um eine Änderung in der Patchdatei vorzunehmen, bevor sie angewandt wird).

Benötigt man in der Patch-Datei den vom Nutzer gewählten Präfix, wird empfohlen, statt /sw eine Variable wie @PREFIX@ zu deklarieren und so zu verwenden:

PatchScript: sed 's|@PREFIX@|%p|g' < %{PatchFile} | patch -p1

Patches sollten im unidiff-Format sein und werden normalerweise mit folgendem Kommandoerzeugt:

diff -urN <originalsourcedir> <patchedsourcedir>

Verwendet man emacs zum Edditieren der Dateien, kann man die Option -x'*~' an das diff-Kommando anhängen, um automatisch erzeugte Backup-Dateien zu unterdrücken.

Beachten sie bitte, dass sehr große Patches nicht in das CVS-Repository hoch geladen werden sollten. Sie sollten auf einen web/ftp-Server hoch geladen und in einem Feld SourceN: deklariert werden. Haben sie keinen Webserver, können Administratoren von Fink die Datei auf der eigenen Seite von Fink zur Verfügung stellen. Auch wenn ihr Patch größer als 30 KB ist, sollten sie überlegen, einen separaten Downlaod zu erstellen.

6.6 Profile.d scripts

Benötigt ihr Paket einige Initialisierungen zur Laufzeit (z. B. Setzen von Umgebungsvariablen), können sie profile.d-Skripte verwenden. Diese Skript-Fragmente werden durch die Skripte /sw/bin/init.[c]sh "sourced". Normalerweise werden alle Fink-Nutzer diese Skripte in ihren Shell-Startup-Skripte (.cshrc und ähnliche Dateien) laden. Ihr Paket muss jedes Skript in zwei Varianten zur Verfügung stellen: Eine für sh-kompatible Shells (sh, zsh, bash, ksh, ...) und eine für csh-kompatible Shells (csh, tcsh). Sie müssen als /sw/etc/profile.d/%n.[c]sh installiert werden (wobei %n wie üblich für den Paketnamen steht). Es müssen auch ihre executable und read Bits gesetzt werden (d. h. sie müssen mit -m 755 installiert werden). Ansonsten werden sie nicht korrekt geladen werden.

Muss man nur einige Umgebungsvariablen setzen (z. B. QTDIR auf '/sw'), kann man das Feld RuntimeVars benutzen; eine bequehme Art, genau dies zu erreichen.


Copyright Notice

Copyright (c) 2001 Christoph Pfisterer, Copyright (c) 2001-2015 The Fink Project. You may distribute this document in print for private purposes, provided the document and this copyright notice remain complete and unmodified. Any commercial reproduction and any online publication requires the explicit consent of the author.


Generated from $Fink: packaging.de.xml,v 1.1 2015/03/10 22:52:23 k-m_schindler Exp $