Fink

Paket erstellen - 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 /opt/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 /opt/sw/lib/perl5 und/oder /opt/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. /opt/sw/lib/perl5/5.12.3 und /opt/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 /opt/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.

Weiter: 4. Dateisystem-Layout