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

Création de paquets Fink

Ce document explique comment créer des descriptions de paquets pour le gestionnaire de paquets de Fink. Il fournit aussi des règles et un fil conducteur pour la distribution Fink. Le format des fichiers de description et les règles de distribution sont en constante évolution. Il faut donc regarder en bas de page la ligne "Dernière mise à jour..." et la balise cvs pour détecter les changements. Les informations contenues dans ce document correspondent à la description du format et des règles utilisées dans les versions de développement postérieures à la version 0.9.0 du gestionnaire de paquets fink.

Si vous créez des paquets pour Fink, vous avez tout intérêt à vous abonner à la liste de diffusion fink-devel. Si vous cherchez un moyen d'aider Fink et que vous avez des compétences dans ce domaine, vous pouvez aussi adopter un paquet sans mainteneur.

Contents

1 Introduction

1.1 Qu'est-ce qu'un paquet ?

Un paquet est un logiciel qui forme une unité atomique. Un paquet contient en général un programme exécutable, les fichiers de données dont il a besoin et des catalogues de message pour l'internationalisation et la documentation. Dans Fink, les paquets peuvent exister sous deux formes : la description de paquet et le paquet binaire prêt à installer.

La description de paquet est un fichier texte compréhensible par un être humain qui contient tout ce qui est nécessaire pour construire le paquet, c'est-à-dire pour créer le paquet binaire. Les informations contenues dans la description de paquet comprennent des métainformations (comme le nom du paquet et une description de son objet), l'URL du source code et les instructions nécessaires à la configuration, compilation et construction du paquet. La description peut être accompagnée d'une rustine.

Un paquet binaire est une archive qui contient effectivement les fichiers qui constituent le paquet, c'est-à-dire les exécutables, les fichiers de données, les catalogues de messages, les bibliothèques, les fichiers include, etc... Le paquet peut aussi contenir des métainformations pour le paquet lui-même. L'installation d'un paquet binaire consiste simplement à le dépaqueter, puisqu'il est déjà dans un format prêt à l'emploi. Comme Fink construit les paquets avec le gestionnaire de paquets dpkg, les paquets binaires ont le format dpkg et ont une extension .deb.

1.2 Identification d'un paquet

Un paquet est identifié par trois éléments : le nom du paquet, la version et la révision. Tous ces éléments peuvent contenir des lettres minuscules (a-z), des nombres (0-9), des tirets (-) sauf les numéros de révision, des signes plus (+) et des points (.). Les autres caractères sont interdits. En particulier, on ne peut utiliser de majuscules et de tiret de soulignement.

Le nom du paquet est tout simplement le nom du logiciel, par exemple openssh. La version, aussi appelée version en amont, est l'identifiant de version du paquet original. On peut utiliser des lettres dans la version, par exemple 2.9p1. fink et dpkg les trient correctement. La révision est un compteur qui est incrémenté quand la description du paquet change. Il démarre à 1 et doit être remis à 1 quand la version en amont change. La révision ne doit pas contenir de tiret. Le nom complet du paquet est constitué de la concaténation de ces trois éléments, séparés par des tirets, par exemple openssh-2.9p1-2.

2 Descriptions de paquets

2.1 Arborescence

Les descriptions de paquets sont lues à partir des répertoires finkinfo situés dans le répertoire /sw/fink/dists. La valeur de la variable "Trees" dans /sw/etc/fink.conf contrôle quels répertoires sont lus. Le nom des fichiers de description de paquets doit être identique au nom complet du paquet suivi de l'extension ".info". À partir de fink 0.26.0, il existe plusieurs façons de spécifier le nom du fichier ; il est recommandé d'utiliser le nom le plus court compatible avec les autres paquets nécessaires. Le nom du fichier est de la forme : nom invariant du paquet, suivi éventuellement d'un tiret et de l'architecture, suivi éventuellement d'un tiret et de la distribution, suivi éventuellement d'un tiret et de la version ou du couple version-révision, et terminé par ".info". Les éléments "architecture" et "distributtion" ne sont autorisés que si leurs champs sont présents dans le paquet et qu'ils fournissent une seule et unique valeur.

L'arborescence des descriptions de paquets comprend plusieurs niveaux de répertoires. En voici la liste de la racine au bas de l'arborescence :

2.2 Format de fichier

Les fichiers de description sont de simples listes de paires clés-valeurs, appelés également "champs". Chaque ligne commence par une clé, suivie de deux-points et d'une espace, puis de la valeur de clé :

clé: valeur

Il y a deux notations pour les champs qui peuvent s'étendre sur plusieurs lignes.

La notation recommandée est basée sur la syntaxe "here-document" - "données ci-après", utilisée dans les scripts shell. Dans cette syntaxe, la première ligne est composée de la clé, suivie du symbole redoublé << comme valeur. Toutes les lignes suivantes sont considérées comme valeurs, jusqu'à la rencontre d'une ligne ne contenant que <<. L'exemple ci-dessus ressemble maintenant à :

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

Avec ce format, l'indentation est optionnelle, mais vous pouvez l'utiliser pour améliorer la lisibilité.

On peut imbriquer plusieurs "here-document". Cela arrive souvent dans un champ SplitOff ou SplitOffN. Ces champs contiennent d'autres champs (à lignes multiples), et cette syntaxe permet aux sous-champs de contenir eux mêmes des lignes multiples. Le même code de terminaison << est utilisé pour les sous-champs utilisant la syntaxe "here-document". En voici un exemple :

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

Une notation plus ancienne, obsolète, est basée sur la méthode de pliage des headers du RFC 822. Une ligne commençant par une espace est traitée comme la continuation de la ligne précédente. Exemple :

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

Notez l'indentation obligatoire des lignes.

Dans les deux formats, les lignes vides ainsi que celles débutant avec un dièse (#) sont ignorées. Dans Fink, les clés (noms des champs) ne sont pas sensibles à la casse, vous pouvez donc écrire indifféremment : InstallScript, installscript ou INSTALLSCRIPT. Cependant, on conseille la première forme, où chaque initiale de mot est mise en majuscules, pour des raisons de lisibilité. Certains champs prennent une valeur booléenne ; sont traitées comme vraies, les valeurs suivantes : "true", "yes", "on", "1" (toutes insensibles à la casse) ; toute autre valeur est traitée comme fausse.

2.3 Raccourcis %

Pour vous rendre la vie plus facile, Fink gère un jeu de raccourcis sur certains champs. Pour lever toute ambiguïté, vous pouvez utiliser des accolades autour des caractères qui doivent être considérés comme des raccourcis. Par exemple, %{n} a la même signification que %n. Les raccourcis disponibles sont les suivants :

RaccourcisSignification
%n

le nom du paquet actif

%N

Nom du paquet parent (le même que %n à moins d'être dans un SplitOff)

Note : si le champ Package d'un paquet parent contient %type_*[], la valeur de ces raccourcis sera incluse dans %N dans un bloc SplitOff (étant donné qu'elle est incluse dans %n dans le paquet parent).

%e

ère du paquet

%v

version du paquet. Notez que l'ère ne fait partie de %v.

%V

the full package Version, which automatically includes the Epoch if present. Note that this percent expansion is only available for packages whose InfoN level is at least 4.

%r

révision du paquet

%f

nom complet du paquet, c'est-à-dire : %n-%v-%r. Notez que l'ère ne fait partie de %f.

%p, %P

préfixe d'installation de Fink, par exemple : /sw. Vous ne devez pas partir du principe que Fink est installé dans /sw, utilisez %p pour obtenir le bon chemin.

%d

répertoire dans lequel le paquet est construit, par exemple : /sw/src/fink.build/root-gimp-1.2.1-1. Ce répertoire temporaire sert de racine d'arborescence lors de la phase d'installation de la compilation d'un paquet. Vous ne devez pas partir du principe que root-%f est dans %p/src, car l'utilisateur peut changer ce répertoire en utilisant le champ Buildpath de /sw/etc/fink.conf.

%D

répertoire Dans lequel le paquet parent est construit (le même que %d à moins d'être dans un SplitOff)

%i

préfixe complet de la phase d'installation, équivalent à %d%p

%I

préfixe d'Installation du paquet parent, équivalent à %D%P (identique à %i à moins d'être dans un SplitOff)

%a

chemin des rustines

%b

répertoire de compilation, exemple : /sw/src/fink.build/gimp-1.2.1-1/gimp-1.2.1. Vous ne devez pas partir du principe que %f est dans %p/src, car l'utilisateur peut changer ce répertoire en utilisant le champ Buildpath de /sw/etc/fink.conf. Le dernier sous-répertoire tire son nom du champ Source, ou du champ SourceDirectory (si ce champ existe), ou bien n'existe pas si le champ NoSourceDirectory a pour valeur true (vrai).

Note : ne l'utilisez que s'il n'y a pas d'autres possibilités. Le répertoire de compilation est le répertoire actif lorsque les scripts sont exécutés ; vous devez utiliser des chemins relatifs dans les commandes.

%c

paramètres pour configure : --prefix=%p plus tout autre élément spécifié avec ConfigureParams. Dans le cas d'un paquet qui comporte le Type: perl, les drapeaux par défaut de construction d'un paquet perl sont utilisés à la place de --prefix=%p.

%m

chaîne spécifiant l'architecture de la machine. Identique au résultat de la commande uname -p. Les valeurs habituelles sont 'powerpc' pour les machines ppc and 'i386' pour les machines x86. Introduit dans les versions CVS de fink postérieures à la version 0.12.1.

%%

signe pourcentage (%) (ce signe n'est pas interprété en fonction de ce qui le suit). L'interprétation se fait de gauche à droite, si bien que %%n n'a rien à voir avec le nom du paquet, mais représente la chaîne %n. (Introduit dans fink-0.18.0).

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

fonction de pseudo-hachage retournant le sous-type du type donné. Voir la documentation sur le champ Type plus bas. La forme _raw correspond à la chaîne précise du sous-type, tandis que la forme _pkg correspond à la même chaîne dont tous les points auraient été enlevés (suivant les conventions de nommage des paquets - language-version - de Fink et pour d'autres usages réservés aux experts). (Introduit dans une version CVS de Fink ultérieure à la version 0.19.2). La forme _num a été introduit dans la version 0.26.0 de fink et supprime tous les caractères non numériques du champ Type.

%{ni}, %{Ni}

la partie invariante du nom du paquet. Identiques à %n et %N, à l'exception près que tous les %type_pkg[] et %type_raw[] sont occultés. (Introduit dans une version CVS de Fink ultérieure à la version 0.19.2). Vous devez utiliser %{ni} et %{Ni} pour éviter de possibles confusions avec les raccourcis %n et %N.

%{default_script}

Uniquement valide dans les champs PatchScript, CompileScript et InstallScript. Correspond au contenu par défaut de ce type de champ. Sa valeur dépend souvent du champ Type et est toujours définie (même si elle vide). Lorsque ce raccourci est utilisé dans le champ InstallScript d'un SplitOff ou d'un SplitOffN, son interprétation correspond à la valeur par défaut du champ parent, bien que la valeur par défaut de InstallScript dans un SplitOff soit vide. (Introduit dans fink-0.20.6)

%{PatchFile}

Chemin complet du fichier indiqué dans le champPatchFile. Introduit dans la version 0.24.12 de fink.

%lib

Si le champ Type: -64bit a pour valeur -64bit, ce raccourci permet de définir le répertoire des bibliothèques comme étant le répertoire lib/ppc64 sur machines powerpc, ou lib/x86_64 sur machines intel (répertoires standards pour les bibliothèques 64-bit). Dans le cas contraire, le raccourci définit le répertoire lib comme répertoire pour les bibliothèques. Introduit dans la version 0.20.6 de fink.

Note that %lib is not permitted in the ConfigureParams field unless the InfoN level is at least 4.

3 Règles de distribution des paquets

3.1 Licences de paquets

Les paquets inclus dans Fink ont différents types de licences. La plupart d'entre elles stipulent une restriction sur la redistribution des sources complètes et particulièrement sur la distribution des binaires. Certains paquets ne peuvent être inclus dans la distribution binaire de Fink à cause de ces licences restrictives. C'est pourquoi il est essentiel que les mainteneurs de paquets vérifient, scrupuleusement, les licences de leurs paquets.

Chaque paquet distribué en tant que binaire doit contenir une copie de la licence. Elle doit être installée dans le répertoire de documentation, c'est à dire dans %p/share/doc/%n. (Dans InstallScript, il faut, évidemment, utiliser %i au lieu de %p. Le champ DocFiles gère les détails automatiquement). S'il n'y a pas de licence explicite dans le source original, placez un fichier texte contenant une note à propos du statut du paquet. La plupart des licences requièrent que celle-ci accompagne toute distribution. La règle de Fink est de toujours faire ainsi, même si ce n'est pas explicitement requis.

Pour automatiser le plus possible la maintenance de la distribution binaire, tout paquet distribué doit avoir un champ License. Ce champ indique la nature de la licence et est utilisé pour décider quels paquets font partie de la distribution et quels paquets doivent en être exclus. Le champ ne peut exister que si les termes réels de la licence sont inclus dans le paquet binaire, comme expliqué ci-dessus.

Pour que le champ License ait une utilité, n'utilisez qu'une seule des valeurs prédéfinies suivantes. Si vous construisez un paquet qui ne rentre pas dans ces catégories, demandez de l'aide sur la liste des développeurs.

3.2 La licence GPL et OpenSSL

(Changement de règle à dater d'avril 2005).

En raison d'une incompatibilité manifeste entre la licence d'OpenSSL et les licences GPL et LGPL, les paquets de Fink sous licence originale GPL ou LGPL qui sont liés à openssl doivent avoir une licence "Restrictive". En conséquence, le projet Fink ne distribuera pas les binaires de ces paquets. Toutefois les utilisateurs sont libres de les compiler à partir du source.

Nous encourageons les mainteneurs à indiquer la licence originale du paquet dans le champ DescPackaging.

3.3 Interférence avec le système de base

Fink est une distribution additionnelle qui est installée dans un répertoire distinct du système de base. Il est essentiel qu'un paquet n'installe aucun fichier en dehors du répertoire de Fink.

Il peut y avoir des exceptions quand on ne peut faire autrement, par exemple avec XFree86. Dans ce cas, le paquet doit tester l'existence de fichiers avant l'installation et refuser de s'installer si cela amène à écraser des fichiers déjà existants. Le paquet doit s'assurer que tous les fichiers qu'il aura installés en dehors du répertoire de Fink seront supprimés lorsque le paquet lui-même sera éliminé, ou que ces fichiers ne causeront aucun problème s'ils sont laissés sur place (c'est-à-dire qu'ils devront tester l'existence des binaires avant de les appeler, etc...).

3.4 Bibliothèques partagées

Fink a de nouvelles règles en ce qui concerne les bibliothèques partagées, règles qui prennent effet à compter de février 2002. Cette partie de la documentation donne des explications sur la version 4 de ces règles, qui coïncide avec la publication de la distribution 0.5.0 de Fink, as modified in December, 2006 to handle 64bit libraries and from January, 2008 to handle private shared libraries. (In addition, the discussion was updated in June, 2008 to eliminate obsolete references to a transitional period for implementing the shared libraries policy.) We begin with a quick summary, and then discuss things in more detail. Nous commencerons par un bref résumé, puis nous passerons à une revue de détails.

Tout paquet qui construit des bibliothèques partagées et qui doit gérer ses bibliothèques partagées conformément aux règles de Fink. Ceci signifie :

Note that a package may also install private shared libraries, which are not intended to be linked from any other package. In this case, the libraries need not go into a separate package, but a Shlibs field must still be part of the package containing shared libraries. Also, maintainers should try to avoid storing a final link from libfoo.dylib in the main library directory %i/lib (or its 64-bit equivalent), to prevent other programs from accidentally linking to this library.

Un mainteneur, qui a de bonnes raisons de s'écarter de ces règles et ne scinde pas le paquet, devra expliquer pourquoi dans le champ DescPackaging.

Pour certains paquets, tout peut être fait avec un paquet principal et un paquet -shlibs ; dans d'autres cas, vous aurez besoin d'un troisième paquet. Le nouveau champ SplitOff facilite ce processus.

Quand trois paquets sont nécessaires, il y a deux façons différentes de les nommer, suivant que les bibliothèques (option 1) ou les binaires (option 2) sont les fonctionnalités les plus importantes du paquet. Pour l'option 1, utilisez le schéma suivant :

PaquetContenu
foo-shlibs

Librairies partagées

foo

Headers

foo-bin

Binaires, etc...

Pour l'option 2, utilisez :

PaquetContenu
foo-shlibs

Librairies partagées

foo-dev

Headers

foo

Binaires, etc...

Règles détaillées

Nous allons désormais discuter de tout cela en détails. Comme exemples des règles en action, voir les paquets libpng, libjpeg et libtiff.

Les logiciels portés sur Darwin doivent, autant que possible, construire des bibliothèques partagées. (Les mainteneurs de paquets sont libres de construire des bibliothèques statiques, si cela s'avère plus approprié pour leurs paquets ; ils peuvent aussi soumettre des paquets contenant uniquement des bibliothèques statiques, s'ils le souhaitent). Quand on construit des bibliothèques partagées deux paquets - nommés foo et foo-shlibs -, étroitement liés, doivent être construits. Les bibliothèques partagées vont dans foo-shlibs, et les headers dans foo. Ces deux paquets peuvent être réalisés avec un seul fichier .info, en utilisant le champ SplitOff, comme indiqué ci-dessous. (En fait, il est souvent nécessaire de construire plus de deux paquets à partir du source, et cela peut être fait en utilisant SplitOff2, SplitOff3, etc...)

Each software package for which public shared libraries are built must have a major version number N, which is included in the shared library's filename (for example, libbar.N.dylib). Le numéro de version majeure n'est censé changer que lorsqu'un changement irréversible se produit dans l'API de la bibliothèque. Fink utilise la convention de nommage suivante : si le nom en amont du paquet est bar, alors les paquets fink sont appelés barN et barN-shlibs. (Ceci n'est appliqué rigoureusement qu'à de nouveaux paquets ou lorsque le numéro de version majeure change). Par exemple, le numéro de version majeure pour le paquet pré-existant libpng était 2, mais les versions récentes de la bibliothèque ont pour numéro de version majeure 3. Il y a donc, maintenant, 4 paquets fink pour gérer ceci : libpng, libpng-shlibs, libpng3, libpng3-shlibs. Seul libpng ou libpng3 peut être installé à un moment donné, mais libpng-shlibs et libpng3-shlibs peuvent être installés en même temps. (Notez que deux fichiers .info suffisent à construire ces quatre paquets).

La bibliothèque partagée elle-même et certains fichiers liés seront placés dans le paquet barN-shlibs ; les fichiers "include" et un certain nombre d'autres fichiers seront placés dans le paquet barN. Il ne peut y avoir de recouvrement de fichiers entre ces deux paquets, et tout ce qui est placé dans barN-shlibs doit avoir un nom chemin qui, d'une façon ou d'une autre, contienne le numéro de version majeure N. Dans de nombreux cas, votre paquet aura besoin de certains fichiers à l'exécution, fichiers qui sont généralement installés dans %i/lib/bar/ ou %i/share/bar/ ; vous devrez adapter les chemins d'installation à %i/lib/bar/N/ ou %i/share/bar/N/.

Tous les autres paquets dépendant de bar, version majeure N, devront utiliser les dépendances :

  Depends: barN-shlibs
  BuildDepends: barN

It is not be permitted for another package to depend on barN itself. (Although there may still be a few such dependencies involving packages which were in place prior to February, 2002.) This is signaled to other developers by a boolean field

  BuildDependsOnly: True

dans la description du paquet barN.

Si votre paquet inclut à la fois des bibliothèques partagées et des binaires, et si les binaires doivent être présents à l'exécution (et pas seulement à la compilation), alors les binaires doivent être regroupés dans un troisième paquet, qui peut être appelé barN-bin. Les autres paquets peuvent dépendre de barN-bin comme de barN-shlibs.

Lors de la construction de bibliothèques partagées de version majeure N, il est important que le "nom d'installation" soit %p/lib/libbar.N.dylib. Vous trouverez le nom d'installation en exécutant otool -L (ou otool64 -Lpour les bibliothèques 64bit) sur votre bibliothèque. Le fichier bibliothèque réel doit être installé sous le nom de :

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

et votre paquet doit créer des liens symboliques :

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

from the install_name path and from the linking path to the actual library. (The first will not be needed if the library is in fact installed at the install_name path, which is becoming more common.)

Si la bibliothèque statique est aussi construite, elle doit être installée sous le nom de :

  %i/lib/bar.a

Si le paquet utilise libtool, ceci est généralement géré automatiquement, mais, dans tous les cas, vous devez vérifier que tout s'est passé correctement. Vous devez aussi vérifier que la version courante et la version de compatibilité sont définies de façon appropriée à vos bibliothèques partagées. On peut trouver les numéros de version avec la commande otool -L (ou la commande otool64 -L pour les bibliothèques 64bit).

Les fichiers sont scindés entre les deux paquets comme suit :

Notez que les deux paquets doivent contenir des informations sur la licence, mais que les répertoires contenant les fichiers de documentation (DocFiles) sont différents.

Tout ceci est facile à réaliser en utilisant le champ SplitOff. Voici comment l'exemple ci-dessus serait (partiellement) implémenté :

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

Durant l'exécution du champ SplitOff, les fichiers et les répertoires spécifiés sont déplacés du répertoire d'installation %I du paquet principal vers le répertoire d'installation %i du paquet splitoff. (Il y a une convention similaire pour les noms : %N est le nom du paquet principal, et %n est le nom du paquet actif). La commande DocFiles place ensuite une copie de la documentation dans %i/share/doc/barN-shlibs.

Notez que nous avons inclus la version courante exacte de barN-shlibs comme dépendance du paquet principal barN (qui peut être abrégé en %N-shlibs (= %v-%r) ). Ceci assure que les versions correspondent, et garantit aussi que barN "hérite" automatiquement de toutes les dépendances de barN-shlibs.

Le champ BuildDependsOnly

Lors de mises à jour de bibliothèques, il est souvent nécessaire d'avoir deux versions des headers pendant une période de transition. L'une d'entre elles est utilisée pour compiler certaines choses, l'autre pour en compiler d'autres. C'est pourquoi, les paquets contenant des headers doivent être construits avec soin. Si foo-dev et bar-dev contiennent tous les deux des headers qui se recouvrent, alors foo-dev doit déclarer :

  Conflicts: bar-dev
  Replaces: bar-dev

de même, bar-dev déclare des Conflicts/Replaces sur foo-dev.

De plus, les deux paquets doivent déclarer :

  BuildDependsOnly: True

Ceci empêche d'autres paquets de dépendre de foo-dev ou de bar-dev, car de telles dépendances enrayeraient le mécanisme du Conflicts/Replaces.

Il existe certains paquets contenant des headers et pour lesquels il ne semble pas approprié de déclarer une valeur "true" pour BuildDependsOnly. Dans ce cas, le paquet doit déclarer :

  BuildDependsOnly: False

et la raison pour laquelle cela est fait doit être mentionnée dans le champ DescPackaging.

Le champ BuildDependsOnly ne doit être mentionné dans le fichier .info du paquet que si ce paquet contient des headers installés dans /sw/include.

À partir de la version 0.20.5 de fink, "fink validate" affichage un message pour tout .deb qui contient des headers et au moins une dylib, et qui ne donne pas la valeur "true" ou "false" au champ BuildDependsOnly. (Il est possible que, dans les versions postérieures de fink, ce message soit étendu aux cas des .deb contenant des headers et une bibliothèque statique).

The goal of the Shared Library Policy is to allow assure compatibility between libraries supplied by one package and libraries or programs that use them in a different package. Some packages may have shared libraries that are not designed to be used by other packages. Common situations include a suite of programs that come with a back-end library of utility functions or a program that comes with plugins to handle various features. Because these libraries are "private" to the package that has them, they do not require being packaged with separate -shlibs or BuildDependsOnly SplitOffs.

Le champ Shlibs :

En sus de placer les bibliothèques partagées dans le bon paquet, suivant en cela la version 4 de cette règle, vous devez également déclarer toutes les bibliothèques partagées en utilisant le champ Shlibs. Ce champ contient une ligne distincte pour chaque bibliothèque partagée ; la ligne comprend le nom d'installation de la bibliothèque. If the library is public, its Shlibs entry also lists the -compatibility_version, versioned dependency information specifying the Fink package which provides this library at this compatibility version, and the library architecture. Cette architecture peut avoir pour valeur "32", "64", "32-64" ou même ne pas exister ; dans ce dernier cas, elle prend la valeur "32" par défaut. La dépendance doit être déclarée sous la forme foo (>= version-révision)version-révision correspond à la première version du paquet de Fink qui fournit cette bibliothèque (avec cette version de compatibilité). Par exemple, une déclaration :

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

indique qu'une bibliothèque 32bit, dont le nom d'installation est %p/lib/libbar.1.dylib et la version de compatibilité est 2.1.0, a été installée à partir de la version 1.1-2 du paquet bar1. De plus, cette déclaration équivaut à la promesse du mainteneur qu'une bibliothèque 32 bit avec ce nom et une version de compatibilité au moins égale à 2.10 sera toujours présente dans les versions ultérieures du paquet bar1.

Notez l'utilisation de %p dans le nom de la bibliothèque, ce qui permet à tous les utilisateurs de Fink de trouver le bon nom d'installation, quel que soit le préfixe qu'ils ont choisi.

Quand un paquet est mis à jour, on copie tout simplement le champ Shlibs dans la nouvelle version/révision du paquet. L'exception à cette règle survient quand la version de compatibilité est incrémentée : dans ce cas, le numéro de version dans les informations de dépendance doit être changé pour la version/révision courante (celle qui est la première à fournir la bibliothèque avec le nouveau numéro de version de compatibilité).

The Shlibs entry for a private library uses a different syntax:

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

The leading exclamation point indicates that this is a private library, and since the other information is not relevant in this case, it is not included.

Note that in this example, the private shared library has been placed in its own subdirectory %N of the %i/lib directory (which was named after the package). This is a recommended procedure for private libraries, as an additional safety measure, to prevent other packages from accidentally linking to this library.

Mesures à prendre quand le numéro de version majeure change :

Si le numéro de version majeure change de N à M, vous devez créer deux nouveaux paquets barM et barM-shlibs. Le paquet barM-shlibs ne peut recouvrir le paquet barN-shlibs, puisque de nombreux utilisateurs installeront les deux simultanément. Dans le paquet barM, vous devez utiliser les dépendances :

  Conflicts: barN
  Replaces: barN

et vous devez modifier barN, de façon similaire, pour inclure les dépendances :

  Conflicts: barM
  Replaces: barM

Les utilisateurs verront alors barN et barM apparaître et disparaître au gré de la construction de divers paquets dépendant de l'une ou l'autre version de la bibliothèque partagée, tandis que barN-shlibs et barM-shlibs resteront installés de façon permanente.

Paquets contenant des fichiers binaires et des bibliothèques :

Quand un paquet en amont contient tout à la fois des fichiers binaires et des public bibliothèques, la construction des paquets fink doit être menée avec soin. Dans certains cas, les seuls fichiers binaires seront des fichiers du genre foo-config, qui sont censés n'être utilisés qu'à la compilation, et jamais à l'exécution. Dans ces cas, les binaires peuvent aller avec les headers dans le paquet foo.

Dans d'autres cas, les fichiers binaires seront nécessaires à d'autres paquets pendant l'exécution, et devront être regroupés dans un paquet fink séparé avec un nom du type foo-bin. Le paquet foo-bin doit dépendre du paquet foo-shlibs, et les mainteneurs d'autres paquets doivent être encouragés à utiliser :

  Depends: foo-bin
  BuildDepends: foo

ainsi la gestion de foo-shlibs sera assurée implicitement.

Néanmoins, la mise à jour pose un problème dans ce cas, puisque les utilisateurs ne seront pas invités à installer foo-bin. Pour résoudre ce problème, tant que tous les autres mainteneurs de paquets n'ont pas révisé leur paquets comme indiqué ci-dessus, votre paquet foo peut stipuler :

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

Ceci forcera l'installation de foo-bin sur la plupart des systèmes, jusqu'au moment où les mainteneurs de paquets auront mis à jour leurs paquets qui dépendent de foo.

As of fink-0.28.0 (released in January 2008), the format of the Shlibs entry for a "private" shared library has changed (see earlier discussion of the difference between a public and a private shared library). Note that the Shared Library Policy has always required all shared libraries to be listed; the change here is only in the syntax of the Shlibs field. Because this type of shared library is not designed to be used by external packages, there is no need to document its compatilibity or other versioning. Instead, an exclamation-mark is used. For example, if libquux.3.dylib is the install_name of a private shared library, it would be listed as follows:

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

3.5 Modules Perl

La réglementation de Fink pour les modules perl, effective à partir de mai 2003, a été modifiée en avril 2004.

Traditionnellement, les paquets Fink pour les modules Perl avaient un suffixe -pm, et étaient compilés en utilisant la directive Type: perl, qui place les modules Perl dans /sw/lib/perl5 et/ou dans /sw/lib/perl5/darwin. Avec la nouvelle réglementation, cet emplacement n'est autorisé que pour les modules perl qui sont indépendants de la version de perl utilisée pour les compiler (et qui ne dépendent pas d'autres modules perl dépendants des versions).

Les modules Perl qui sont dépendants des versions sont les modules dits XS, qui contiennent fréquemment du code C compilé ainsi que des routines écrites en langage Perl. Il y a de nombreuses façons de les reconnaître, notamment par la présence d'un fichier avec un suffixe .bundle.

Un module perl qui dépend des versions doit être construit en utilisant un binaire dont le nom comporte le numéro de version de perl, comme perl5.6.0, et doit stocker ses fichiers dans des sous-répertoires des répertoires standards de perl ; les noms de ces sous-répertoires doivent comporter le numéro de version de perl, comme /sw/lib/perl5/5.6.0 et /sw/lib/perl5/5.6.0/darwin. Par convention, les noms des paquets utilisent le suffixe -pm560 pour un module Perl de version 5.6.0. Des conventions de stockage et de nommage similaires s'imposent pour les autres versions de perl, qui incluent perl 5.6.1 (dans les seules branches 10.2), perl 5.8.0 (dans les seules branches 10.3), perl 5.8.1, perl 5.8.4 et perl 5.8.6.

La directive Type: perl 5.6.0 utilise automatiquement le binaire dont le nom comporte le numéro de version de perl et stocke les fichiers dans les bons sous-répertoires. (Cette directive est disponible à partir de la version 0.13.0 de fink).

Sous la réglementation de mai 2003, il était permis de créer un paquet -pm, qui est essentiellement un paquet "lot", qui charge la variante -pm560 ou une autre variante existante. Cette stratégie est déconseillée sous la réglementation d'avril 2004, et sera complètement interdite après une période de transition. (La seule exception sera le paquet storable-pm qui doit se présenter sous cette forme pour le bootstrap).

À partir de la version 0.20.2 de fink, le paquet virtuel system-perl "fournit" automatiquement certains modules perl quand la version de Perl présente sur le système est supérieure ou égale à 5.8.0. Dans le cas de system-perl-5.8.1-1, ces modules sont les suivants : attribute-handlers-pm581, cgi-pm581, digest-md5-pm581, file-spec-pm581, file-temp-pm581, filter-simple-pm581, filter-util-pm581, getopt-long-pm581, i18n-langtags-pm581, libnet-pm581, locale-maketext-pm581, memoize-pm581, mime-base64-pm581, scalar-list-utils-pm581, test-harness-pm581, test-simple-pm581, time-hires-pm581. (Cette liste était légèrement différente dans la version 0.20.1 de fink ; les mainteneurs de paquet sont invités à vérifier que c'est bien sur la nouvelle liste qu'ils se basent).

Effective à partir de la version 0.13.0 de fink, la commande fink validate, quand elle est appliquée à un fichier .deb, teste si le paquet fink est un module XS qui a été installé dans un répertoire dont le nom ne comporte pas le numéro de version, et, génère, dans ce cas, une alerte.

Les utilisateurs peuvent avoir plusieurs versions de perl installées au même moment. C'est pourquoi tout paquet de module basé sur une version de perl doit être écrit de tel sorte qu'il permette d'installer concurremment une autre version du même module. Il faut donc prendre soin d'éviter tout conflit d'installation dû à des noms identiques lors de l'installation des pages de manuel, des binaires ou autres scripts exécutables. Il est interdit de mettre dans un paquet un nom de fichier se terminant par -pmXYZ si le chemin complet du fichier est identique dans une autre version XYZ. L'utilisation de Replaces pour permettre de remplacer des fichiers de nom identique dans des modules correspondant à des versions de perl différentes n'est plus autorisée. En ce qui concerne les pages de manuel, voici la solution de remplacement à partir de mars 2005: on a définit dans Fink des emplacements différents pour le MANPATH : %p/lib/perl5/X.Y.Z/man pour chaque version perl-X.Y.Z. Il n'est plus besoin de créer des paquets SplitOff -man ou -doc mutuellement exclusifs. Par exemple, pour éviter des conflits entre uri-pm581 et uri-pm586, la page de manuel nommée URI.3pm est installée sous le nom %p/lib/perl5/5.8.1/man/man3/URI.3pm pour la version 5.8.1 et sous le nom %p/lib/perl5/5.8.6/man/man3/URI.3pm pour la version 5.8.6. Notez que les scripts par défaut générés par Type: perl X.Y.Z n'ont pas changé, vous devez donc installer les man pages manuellement dans InstallScript. Si, par ailleurs, vous n'utilisez pas un script hautement personnalisé, vous pouvez toujours utiliser le script par défaut, puis déplacer les fichiers manuellement :

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

Cela déplacera toutes les pages de manuel. Si vous ne désirez déplacer qu'une section des pages de manuel (par exemple, la section 3, page de manuel du module, mais pas la section, page de manuel des scripts), vous pouvez utiliser l'approche suivante :

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

Si votre paquet comporte des exécutables, par exemple des scripts démo ou des utilitaires dans %p/bin, vous avez plusieurs options. L'une d'entre elle est de mettre ces fichiers (et leurs pages de manuel et autres fichiers associés) dans un paquet splitoff %N-bin. L'utilisation des champs Conflicts et Replaces assurera que l'installation des différentes versions de perl de ces paquets, qui contiennent des fichiers de même nom, est mutuellement exclusive. L'utilisateur peut installer de nombreuses versions différentes des modules de runtime basées sur des versions différentes de perl et décider laquelle choisir à tout moment pour exécuter un script. Par exemple, Tk.pm comporte un exécutable ptksh. La collection des paquets tk-pm* peut être construite de la façon suivante :

Info2: <<
Package: tk-pm%type_pkg[perl]
Type: perl (5.8.1 5.8.4 5.8.6)
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.8.1, %{Ni}5.8.4, %{Ni}5.8.6
  Replaces: %{Ni}5.8.1, %{Ni}5.8.4, %{Ni}5.8.6
  Files: bin share/man/man1
<<
<<

Une autre solution est de renommer les scripts et leurs pages de manuel de façon à y inclure la version de perl. Cette méthode assure qu'il n'y a jamais de conflit, il n'est donc pas besoin d'utiliser des splitoffs %N-bin mutuellement exclusifs :

Info2: <<
Package: tk-pm%type_pkg[perl]
Type: perl (5.8.1 5.8.4 5.8.6)
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
<<
<<

L'utilisateur accède à la version de ptksh correspondant à la version de perl désirée. On peut aussi utiliser update-alternatives pour permettre aux utilisateurs d'accéder à ces versions par leurs noms génériques (pas de mention de version de perl dans le nom).

De même, à partir de mars 2005, l'emplacement des pages de manuel et des modules installés par les paquets fink pour perl lui-même (paquets perlXYZ et perlXYZ-core pour des versions de perl différentes de celle fournie par Apple) a changé. Par conséquent, aucun autre paquet de fink fournissant des versions de mises à jour des modules core perl ne doit énumérer des paquets perlXYZ ou perlXYZ-core dans un champ Replaces.

3.6 Règles Emacs

Le projet Fink a choisi de suivre les règles du projet Debian en ce qui concerne emacs, avec quelques différences. (Vous trouverez les règles Debian sur http://www.debian.org/doc/packaging-manuals/debian-emacs-policy). Il existe deux différences dans les règles de Fink. Premièrement, ces règles ne s'appliquent, à l'heure actuelle, qu'aux paquets emacs21, emacs22 et emacs21 de fink. (Ceci pourra changer à l'avenir). Deuxièmement, contrairement aux règles Debian, les paquets Fink peuvent installer des objets directement dans /sw/share/emacs/site-lisp.

3.7 Source Policy

Sources should normally be downloaded from the location(s) that the upstream developer(s) use, and any modifications for Fink should be done through the use of a PatchFile and/or a PatchScript. Do not make changes manually and use a changed source archive as a Source in your Fink packaging.

If a VCS checkout (e.g. from git or svn) is to be used, e.g. because a project doesn't do formal releases, or a fix for a particular issue has been added between releases of a package, an acceptable source can be generated via the following method:

  1. Check out the package, preferably at a definite revision of the VCS.
  2. Make an archive from the VCS checkout (e.g. zip, tar, tar.gz, or tar.bz2).

    Give the tarball a unique version. For example, you can include the VCS revision in the archive name, e.g. foo-0svn1234.tar.gz for a package that doesn't make releases, or bar-1.2.3+svn4567.tar.bz2 for a Fink package which is between upstream releases.

  3. Use the same Version in your .info file.
  4. It is also useful to put the commands that you ran to generate the source tarball in the DescPackaging field.
  5. Upload the tarball to a public download site where users can use fink to download it. If you don't have ready access to one, ask on the Fink developers mailing list or the #fink IRC channel, and someone should be able to help.

3.8 File Download Policy

Packages are not to download any files during the unpack, patch, compile, install, or build phases of the build process. Any large patches (i.e. larger than can be accommodated conveniently in a PatchFile) that need to be applied should set up as additional Sources in accordance with the Source Policy.

Packages may download data in a PostInstScript after they have been installed on the system, under some limited circumstances:

If you are unsure, contact the Fink Core Team.

4 Organisation des fichiers

Les règles d'organisation des fichiers suivantes font partie intégrante des règles de construction des paquets de Fink.

4.1 Hiérarchie standard des fichiers

Fink suit l'esprit de Filesystem Hierarchy Standard - Norme de hiérarchie du système de fichiers, ou FHS en raccourci. Il ne peut qu'en suivre l'esprit car FHS a été conçu pour les vendeurs de systèmes qui ont le contrôle des arborescences / et /usr. Fink n'est qu'une distribution supplémentaire qui ne contrôle que son répertoire (ou préfixe) d'installation. Les exemples ci-dessous utilisent le préfixe par défaut, soit /sw.

4.2 Répertoires

Les fichiers doivent être placés dans les sous-répertoires suivant de l'arborescence :

RépertoireUtilisation
/sw/bin

Ce répertoire est dédié aux exécutables généraux. Il n'existe pas de sous-répertoire.

/sw/sbin

Ce répertoire correspond aux exécutables pour administrateurs système. Les démons lancés en tâche de fond y sont placés. Il n'y a pas de sous-répertoire.

/sw/include

Ce répertoire stocke les headers C et C++. On peut créer autant de sous-répertoires que nécessaire. Si un paquet installe des headers qui peuvent être confondus avec des headers standard C, les headers du paquet doivent être installés dans un sous-répertoire.

/sw/lib

Ce répertoire est destiné aux fichiers de données et bibliothèques dépendants de l'architecture du système. Les bibliothèques statiques et partagées doivent être placées dans /sw/lib, sauf s'il existe une bonne raison pour ne pas le faire. C'est également là que sont placés les exécutables qui ne doivent pas être directement lancés par l'utilisateur (dans le cas contraire, ils sont placés dans libexec).

On peut créer un sous-répertoire spécifique à un paquet, afin d'y mettre des données privées ou des modules chargeables. Pensez à utiliser des noms de répertoire qui garantissent la compatibilité entre versions. Il est bon d'utiliser le numéro de version majeur du paquet dans le nom du sous-répertoire ou à un niveau inférieur de la hiérarchie ; par exemple, /sw/lib/perl5 ou /sw/lib/apache/1.3. Faites attention si vous utilisez le type d'hôte dans le nom des répertoires créés. Un sous-répertoire nommé powerpc-apple-darwin1.3.3 ne garantit pas la compatibilité entre versions ; utilisez plutôt powerpc-apple-darwin1.3 ou powerpc-apple-darwin.

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

Ce répertoire est dédié aux bibliothèques 64-bit. Le répertoire /sw/lib/ppc64 est utilisé sous architecture powerpc et le répertoire /sw/lib/x86_64 sous architecture i386. Les bibliothèques combinées (fat) doivent être enregistrées dans le répertoire /sw/lib.

/sw/share

Ce répertoire sert aux fichiers de données indépendants de l'architecture. Les mêmes règles que celles en vigueur pour /sw/lib s'appliquent ici. Quelques sous-répertoires courants sont décrits ci-dessous.

/sw/share/man

Ce répertoire contient les pages de manuel. Son arborescence suit celle des sections courantes. Chaque programme installé dans /sw/bin et /sw/sbin doit avoir une page de manuel associée dans ce répertoire.

/sw/share/info

Ce répertoire contient la documentation en format Info (produit à partir de sources Texinfo). La maintenance du fichier dir est automatisée par la version Debian du programme install-info (qui fait partie du paquet dpkg). Utilisez le champ de description InfoDocs pour générer le code approprié utilisé par les scripts de paquet postinst et prerm. Fink s'assure qu'aucun paquet n'installe un fichier dir de lui-même. Il n'y a pas de sous-répertoire.

/sw/share/doc

Ce répertoire contient la documentation autre que les pages de manuel ou les documents Info. Les fichiers README, LICENSE et COPYING sont placés dans ce répertoire. Chaque paquet doit y créer un sous-répertoire, dont le nom est basé sur celui du paquet. Le nom du sous-répertoire ne doit pas contenir de numéro de version (sauf s'il fait lui-même partie du nom du paquet). Conseil : utilisez %n.

/sw/share/locale

Ce répertoire contient les catalogues de messages de traduction.

/sw/var

Le répertoire var contient les données variables. Ceci inclut les répertoires spool (fichiers en attente de traitement), les fichiers verrous (lock), les bases de données des variables d'état (db), les données variables des jeux (games) et les fichiers d'historique (log).

/sw/etc

Ce répertoire contient les fichiers de configuration. Quand un paquet possède plus d'un ou deux fichiers de configuration, un sous-répertoire doit être créé. Le nom du sous-répertoire doit être celui du paquet ou d'un de ses programmes, de façon à l'identifier facilement.

/sw/src

Ce répertoire sert à stocker et compiler le code source. Un paquet ne doit rien installer dans ce répertoire.

/sw/Applications

This directory is for storing OS X-style applications which are launched by double-clicking rather than from the command line.

/sw/Library/Frameworks

This directory is for storing OS X-style frameworks, sometimes used by OS X-style applications.

4.3 À éviter

Aucun autre répertoire que ceux mentionnés ci-dessus ne doit être créé dans /sw. En particulier, les répertoires suivant ne doivent pas être utilisés : /sw/man, /sw/info, /sw/doc, /sw/libexec et /sw/lib/locale.

5 Compilateurs

Fink utilise la famille des compilateurs gcc, tel qu'ils sont fournis par Apple Computer sur le site Apple Developer Connection. Il existe différentes versions de gcc et chaque système Mac OS X en comporte, en général, plusieurs.

Cette partie explique quelques-unes des façons dont Fink gère ces différentes versions de gcc. Un courriel posté sur la liste de diffusion de Fink comporte de plus amples explications.

5.1 Versions du compilateur

Comme ces compilateurs évoluent, il y a plusieurs "distributions" de fink différentes pour s'adapter à ces changements.

Chaque distribution comporte certaines valeurs par défaut pour les compilateurs gcc et g++, qui correspondent à ceux qu'un utilisateur compilant à partir des sources est censé avoir installés. Vous pouvez donc compter sur le fait qu'un appel direct à "gcc" ou "g++" à partir d'un paquet utilisera ces valeurs par défaut. Si vous avez besoin d'utiliser une valeur différente (par exemple, durant la transition vers une nouvelle distribution), le fichier .info du paquet doit le spécifier en utilisant les versions binaires fournies par Apple. La façon exacte de le faire dépend du système de compilation du logiciel, mais pour de nombreux paquets, on peut utiliser les champs fink SetCC et SetCXX à cette fin. Par exemple, vous pouvez passer à la version 3.3 du compilateur g++ avec le champ SetCXX: g++-3.3. Vérifiez le résultat lors de la compilation afin de vous assurer que le bon compilateur est utilisé.

La distribution 10.1 part du principe que la version du compilateur est la version 2.95 ; la distribution 10.2 que la version du compilateur est la version 3.1 ; les distributions 10.2-gcc3.3 et 10.3 que la version du compilateur est la version 3.3. Pour la distribution 10.4-transitional, c'est un peu plus compliqué : g++-3.3 est utilisé avec gcc-4.0. Cela changera de nouveau dans la distribution 10.4 où l'on utilisera gcc-4.0 et g++-4.0.

À partir de la distribution 10.4-transitional, une nouvelle méthode a été introduite pour assurer la sélection du bon compilateur g++. Durant la compilation, un répertoire /sw/var/lib/fink/path-prefix-g++-XXX (où XXX est le numéro de version) est ajouté au PATH. Ce répertoire contient des scripts shell qui se charge de sélectionner la bonne version de g++.

5.2 L'ABI g++

L'ABI g++ a changé trois fois depuis la naissance de Mac OS X : elle est différente pour les versions 2.95, 3.1, 3.3 et 4.0. Ces différentes ABI ne sont pas compatibles entre elles, et toute bibliothèque utilisant du code C++ et liée à un projet doit être compilée avec la même ABI que celle en cours d'utilisation.

Fink garde trace de l'ABI g++ à l'aide du champ GCC. Ce champ doit être défini par tout paquet qui invoque les compilateurs g++ ou c++. Il NE doit PAS être défini pour les paquets qui n'invoquent pas ces compilateurs. Quand un changement d'ABI intervient, il faut vérifier le champ GCC de toutes les dépendances d'un paquet. Quand toutes les dépendances ont été mises à jour, le paquet lui-même peut être mis à jour. Les versions des dépendances doivent être modifiées pour assurer que les utilisateurs aient bien toutes les dépendances correctes mises à jour avant de tenter de compiler la nouvelle version d'un paquet.

Si un petit nombre de paquets dépendent uniquement les uns des autres, on peut laisser la version de l'ABI précédente en place, s'ils ne sont pas prêts pour la mise à jour. Quand la mise à jour aura lieu, ils seront tous mis à jour en même temps avec une version correcte sur tous les paquets. C'est pourquoi il est préférable de ne mettre à jour les paquets qu'au moment de la distribution.

Fink utilise le champ GCC pour s'assurer que les utilisateurs ont bien la bonne version du compilateur g++ installée sur leur système. Si le champ GCC est défini par le paquet, fink vérifie que la commande gcc_select a reçu la valeur en cours. Cette valeur est 3.3 pour les versions 10.2 et 10.3 de Mac OS X, et 4.0 pour la version 10.4 de Mac OS X. La commande gcc_select n'était pas disponible antérieurement à la version 10.2 de Mac OS X.

6 Référence

6.1 Construction d'un paquet

Pour comprendre l'utilité de certains des champs, vous devez d'abord savoir comment Fink construit un paquet. La construction se déroule en cinq phases : décompression, application des rustines, compilation, installation et construction proprement dite. L'exemple ci-dessous correspond à une installation dans /sw du paquet gimp-1.2.1-1.

Lors de la phase de décompression, le répertoire /sw/src/fink.build/gimp-1.2.1-1 est créé et l'archive tar y est décompressée (il peut y avoir plusieurs archives tar). Dans la plupart des cas, un répertoire gimp-1.2.1, contenant le source, sera créé ; toutes les étapes suivantes seront exécutées dans ce répertoire (par exemple /sw/src/fink.build/gimp-1.2.1-1/gimp-1.2.1). Les champs SourceDirectory, NoSourceDirectory et SourceNExtractDir permettent de contrôler quels sont les répertoires à utiliser.

Lors de la phase d'application des rustines, le code source est modifié par les rustines, pour qu'il compile sous Darwin. Les actions dérivées des champs UpdateConfigGuess, UpdateLibtool, Patch et PatchScript sont exécutées dans l'ordre d'énumération de ces champs.

Lors de la phase de compilation, le source est configuré et compilé. En général, cela correspond au lancement du script configure avec certains paramètres, puis à l'exécution de la commande make. Voir la description du champ CompileScript pour de plus amples informations. Si les séries de tests sont activées (nouvelle fonctionnalité accessible en mode mainteneur dans la version 0.25 de fink), le script TestScript est lancé juste après le script CompileScript.

Lors de la phase d'installation, le paquet est installé dans un répertoire temporaire, /sw/src/fink.build/root-gimp-1.2.1-1 (= %d). (Notez la partie "root-"). Tous les fichiers qui sont normalement installés dans /sw sont installés dans /sw/src/fink.build/root-gimp-1.2.1-1/sw (= %i = %d%p). Voir la description du champ InstallScript pour de plus amples informations.

(À partir de fink 0.9.9., il est possible de générer plusieurs paquets à partir d'une seule description de paquet en utilisant le champ SplitOff. À la fin de la phase d'installation, des répertoires d'installation distincts sont créés pour chaque paquet à construire et les fichiers sont placés dans le répertoire approprié).

Lors de la phase de construction, un fichier binaire (.deb) est construit à partir du répertoire temporaire. On ne peut agir directement sur cette étape, néanmoins différentes informations issues de la description du paquet sont utilisées afin de générer un fichier de contrôle pour dpkg.

6.2 Champs

Nous avons classé les champs en plusieurs catégories. Cette liste n'est pas forcément exhaustive. :-)

Données initiales :

ChampUtilisation
Package

Nom du paquet. Peut contenir des minuscules, des nombres ou les caractères spéciaux suivants : '.', '+' et '-'. Pas de trait de soulignement ('_'), ni de majuscules. Champ obligatoire.

Seuls les raccourcis %N, %{Ni}, %type_raw[] et %type_pkg[] sont applicables à ce champ.

Selon les règles de Fink, un paquet donné doit toujours être compilé avec les mêmes options activées. Si un paquet peut avoir plusieurs variantes (voir la documentation sur le champ Type), vous devez encoder les informations concernant la variante dans le champ Package (voir la documentation sur le raccourci %type_pkg[]). De cette façon, chaque variante possédera un nom unique. Le nom du paquet indique quelles variantes sont incluses. Notez que l'usage des raccourcis %type_pkg[] et %type_raw[] dans le nom du paquet est récent et grandement incompatible avec les anciennes versions de fink ; les descriptions de ces paquets doivent être insérés dans un champ InfoN avec N>=2.

Version

Le numéro de version en amont. Même limitations que pour le champ Package. Champ obligatoire.

Notez que certains programmes utilisent une numérotation de version non standard qui peut provoquer des problèmes de tri, ou bien utilisent des caractères non autorisés dans ce champ. Dans ce cas, vous devez convertir la valeur de la version originale en une valeur acceptable qui permette de trier les versions correctement. Si vous ne savez pas comment les versions seront triées, utilisez la commande dpkg à l'invite d'un shell. Par exemple :

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

imprimera "vrai" car le numéro de version "1.2.1" est inférieur au numéro de version "1.3". Voir la page de manuel dpkg pour de plus amples informations.

Revision

Le numéro de révision du paquet. Incrémentez ce numéro quand vous faites une nouvelle description pour la même version en amont. Les numéros de révision commencent à 1. Champ obligatoire.

Les règles de Fink stipule vous devez incrémenter le champ Revision chaque fois que vous changez un fichier .info, si les changements entraînent une modification de la forme binaire (compilée) du paquet (le fichier .deb). Cela s'applique aux changements opérés dans le champ Depends ou les autres champs incluant une liste de paquets, ainsi qu'à l'ajout, la suppression ou le changement de nom des paquets splitoff, ou bien encore le déplacement de fichiers d'un splitoff à un autre. Quand la migration d'un paquet vers une nouvelle arborescence (par exemple de 10.2 à 10.3) conduit à des modifications de cette nature, vous devez incrémenter le champ Revision de 10 unités dans la nouvelle arborescence, de façon à garder la possibilité de mises à jour ultérieures dans l'arborescence la plus ancienne.

Architecture

Liste d'architectures système basées sur la CPU et séparées par des virgules sur lesquelles le paquet et tout paquet splitoff sont censés tourner. Pour le moment, les seules valeurs valides sont powerpc et i386. Si ce champ est présent et non vide après vérification conditionnelle, fink ignorera la ou les descriptions de paquet(s) correspondante(s) si l'architecture système de la machine locale n'est pas comprise dans la liste. Si le champ est omis ou s'il est vide, le paquet est géré comme si toutes les architectures système étaient reconnues. Introduit dans une version CVS de fink postérieure à la version 0.24.11.

Pour l'instant, l'utilisation la plus courante de ce champ est prévue pour les paquets qui requièrent un compilateur antérieur à gcc-4.0 (ou pour les paquets qui en dépendent). Dans ce cas, la valeur du champ sera powerpc.

Ce champ admet la syntaxe conditionnelle standard pour toute valeur de la liste. Les raccourcis clavier peuvent y être utilisés (voir le champ Depends pour de plus amples informations). Il s'ensuit que certaines variantes peuvent être restreintes à certaines architectures systèmes. Par exemple :

  Package: foo-pm%type_pkg[perl]
  Type: perl (5.8.1 5.8.4 5.8.6)
  Architecture: (%type_pkg[perl] = 581) powerpc

est interprété comme une variante foo-pm581 pour l'architecture système powerpc, le champ restant vide pour toute autre variante. N'oubliez pas que le fait d'omettre une certaine valeur d'architecture ne signifie pas que le paquet n'est pas censé tourner sur l'architecture système en question.

Distribution

A comma-separated list of distribution(s) for which the package (and any splitoff packages) are intended. At present, the only valid values for distribution are 10.4, 10.5, and 10.6 . If this field is present and not blank after conditional handling, fink will ignore the package description(s) if the local machine distribution is not listed. If the field is omitted or the value is blank, all distributions are assumed. (Introduced in fink 0.26.0.)

Since Fink's 10.4, 10.5, and 10.6 distributions share a common set of finkinfo files, the most common use of this field will be for packages which are suitable for one of those distributions but not the other.

This field supports the standard conditional syntax for any value in the value list and percent-expansions can be used (see the Depends field for more information). In this manner, certain variants can be restricted to certain architectures. For example:

  Package: foo-pm%type_pkg[perl]
  Type: perl (5.8.1 5.8.6)
  Distribution: (%type_pkg[perl] = 581) 10.3, (%type_pkg[perl] = 581) 10.4

will result in the field for the foo-pm581 variant being 10.3, 10.4 and the field being blank for the foo-pm586 variant.

Since python 2.3 is not available in the 10.5 distribution, and the available perl packages vary by distribution, these package types provide a common use of this field. For reference, we note the availabilty of various perl versions in the 10.3, 10.4, 10.5, 10.6, and 10.7 distributions:

    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

A way to include all variants in a single finkinfo file is as follows.

  Package: foo-pm%type_pkg[perl]
  Type: perl (5.6.0 5.8.0 5.8.1 5.8.4 5.8.6 5.8.8 5.10.0 5.12.3)
  Distribution: <<
   (%type_pkg[perl] = 560) 10.3, (%type_pkg[perl] = 580) 10.3, 
   (%type_pkg[perl] = 581) 10.3, (%type_pkg[perl] = 581) 10.4, 
   (%type_pkg[perl] = 584) 10.3, (%type_pkg[perl] = 584) 10.4, 
   (%type_pkg[perl] = 586) 10.3, (%type_pkg[perl] = 586) 10.4, (%type_pkg[perl] = 586) 10.5,
   (%type_pkg[perl] = 588) 10.4, (%type_pkg[perl] = 588) 10.5, (%type_pkg[perl] = 588) 10.6,
   (%type_pkg[perl] = 5100) 10.5, (%type_pkg[perl] = 5100) 10.6,
   (%type_pkg[perl] = 5123) 10.7
  <<

Note that we do not include old distributions, such as 10.2 or 10.4-transitional, since the versions of fink which are relevant for them do not recognize this field.

Epoch

Introduit à partir de fink 0.12.0. Ce champ facultatif peut être utilisé pour spécifier l'ère du paquet (défaut 0 si ce champ n'est pas renseigné). Pour de plus amples informations, voir Debian Policy Manual. Comme Fink et quelques-uns des outils Debian sous-jacents utilisent nom-version-revision comme identifiant unique d'un paquet, vous ne devez pas créer deux paquets qui ne diffèrent que par le numéro d'ère.

Quant elle est utilisée dans la version, l'ère apparaît avant la valeur de la version, séparée d'elle par deux-points (1:3.14-2). Notez que l'ère ne fait partie ni de %v, ni de %f. Si vous ajoutez un champ ère au fichier de description d'un paquet, vous pouvez être amené à l'introduire également dans ses dépendances. Par exemple, si vous ajoutez Epoch: 1 à foo et que foo-dev déclare Depends: foo-shlibs (= %v-%r), vous devez le changer en Depends: foo-shlibs (= %e:%v-%r).

Description

Courte description du paquet (répond à la question qu'est-ce c'est ?). C'est une description d'une ligne qui est affichée sous forme de liste, elle doit donc être courte et bien ciblée. Elle peut avoir moins de 45 caractères, mais ne peut dépasser 60 caractères. Il n'est pas nécessaire d'indiquer le nom du paquet, il sera affiché de toute façon. Champ obligatoire.

Type

Peut être bundle. Les paquets lots sont utilisés pour regrouper plusieurs paquets. Ils n'ont que des dépendances, mais ni code ni fichiers installés. Les champs Source, PatchScript, CompileScript, InstallScript et ceux qui leur sont liés sont ignorés pour ce type de paquets.

nosource est un type très voisin. Il sert à indiquer qu'il n'y a pas d'archive tar source. Rien n'est téléchargé et la phase de décompression crée simplement un répertoire vide. Néanmoins, les phases d'application de rustine, de compilation et d'installation sont exécutées normalement. De cette façon, on peut incorporer tout le code avec une rustine, ou créer quelques répertoires avec InstallScript. À partir de la version 0.18.0 de fink, on peut utiliser Source: none pour obtenir le même résultat. Ceci permet d'utiliser "Type" pour d'autres usages (Type: perl, etc...).

À partir de fink 0.9.5, il existe un type perl, qui permet d'offrir un choix de valeurs par défaut pour les scripts de compilation et d'installation. À partir de fink 0.13.0, il existe une nouvelle variante de ce type, perl $version, où $version est une version spécifique de perl, constituée de trois chiffres séparés par un point, par exemple : perl 5.6.0.

Dans une version CVS postérieure à fink-0.19.2, l'utilisation de langage/langage-version a été généralisée pour permettre à tout mainteneur de définir des types et sous-types associés et ainsi d'utiliser plus d'un type par paquet. Les types et sous-types sont des chaînes de caractères arbitraires ; toutefois, les blancs sont interdits et les parenthèses, virgules, crochets et signe pourcentage ne doivent pas être utilisés. Les raccourcis ne sont pas interprétés et le type (mais non le sous-type) est converti en minuscules. Les valeurs du type sont définies dans une liste , chaque valeur étant séparée de la suivante par des virgules ; chaque valeur peut elle-même avoir une liste de sous-types associés séparés par des blancs.

De plus, il existe un concept de "variantes", qui permet de décrire dans un fichier .info unique une famille de paquets étroitement liés, ayant chacun des options différentes activées. La clé de ce processus est l'utilisation d'une liste de sous-types. Au lieu d'une simple chaîne de caractères, on utilise une liste de chaînes de caractères séparés par des blancs et mise entre parenthèses. Fink clone le fichier de description du paquet pour chaque sous-type de la liste et remplace cette liste par un unique sous-type dans le clone. Par exemple :

Type: perl (5.6.0 5.8.1)

provoque la création de deux descriptions de paquet, une qui se comporte comme si on avait Type: perl 5.6.0 et l'autre comme si on avait Type: perl 5.8.1. Le sous-type spécial "(boolean)" est un raccourci pour une liste contenant le type lui-même et un point. Ainsi les deux formes suivantes sont identiques :

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

L'interprétation de la liste de sous-types / clonage du paquet est récursive. S'il y a plusieurs types avec des listes de sous-types, on obtient toutes les combinaisons possibles :

Type: -ssl (boolean), perl (5.6.0 5.8.1)

Dans les autres champs, on accède à un sous-type donné de variante en utilisant les fonctions de pseudo-hachage %type_raw[] et %type_pkg[]. Voici deux exemples de fragments de fichiers .info :

Info2: <<
Package: foo-pm%type_pkg[perl]
Type: perl (5.6.0 5.8.1)
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
<<
<<

À partir de la version 0.26.0 de fink, il existe un champ spécial Type: -64bit qui contrôle un nouveau raccourci %lib et modifie la valeur par défaut du drapeau LDFLAGS. Quand on combine ce champ avec la construction %type_num[], ceci permet de construire à partir d'un seul fichier .info les versions 32-bit et 64-bit d'une bibliothèque. Voici un exemple :

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]
  <<
<<
<<
License

Ce champ indique la nature de la licence sous laquelle le paquet est distribué. Sa valeur doit être l'une de celles décrites plus haut dans la section Licences de paquet. De plus, ce champ ne doit être renseigné que si le paquet respecte effectivement les règles de construction des paquets, c'est-à-dire installe une copie de la licence dans le répertoire doc.

Maintainer

Nom et adresse e-mail de la personne responsable du paquet. Ce champ est obligatoire et ne doit mentionner qu'un nom et qu'une adresse e-mail sous le format suivant :

Prénom Nom <utilisateur@hôte.domaine.com>
InfoN

Ce champ permet à fink d'implémenter des changements de syntaxe incompatibles avec les versions précédentes dans les fichiers de description de paquet. Une version donnée de fink est configurée avec un nombre entier maximum "N", qu'il sait gérer. Tout paquet dont le champ InfoN est supérieur à ce nombre sera ignoré. Il ne faut donc utiliser ce mécanisme que dans les cas d'absolue nécessité, faute de quoi on priverait de ces paquets les personnes utilisant des versions plus anciennes de fink. Quand un autre champ doit utiliser un numéro InfoN spécifique, mention en est faite dans la description du champ. Pour utiliser ce mécanisme, il faut insérer l'ensemble de la description du paquet dans le champ InfoN. Voir plus haut la section "Format de fichier" pour une description de la syntaxe des champs constitués de plusieurs lignes. Voici les fonctionnalités ajoutées à chaque niveau InfoN, ainsi que la version la plus ancienne de fink qui les gère :

  • Info2 (fink >= 0.20.0) : capacité à interpréter les raccourcis dans le champ Package principal du fichier .info et à utiliser les raccourci %type_* dans le champ Package des paquets SplitOff (et SplitOffN).
  • Info3 (fink>=0.25.0) : possibilité d'utiliser des retraits significatifs dans les fichiers .info, arrêt de la gestion des lignes multiples de la norme RFC-822, possibilité de mettre des commentaires dans les champs de listes de paquets.
  • Info4 (fink>=0.26.2): adds %V expansion, and permits %lib in ConfigureParams field.

Dépendances :

ChampUtilisation
Depends

Liste de paquets à installer pour que le paquet puisse compiler. L'interprétation des raccourcis a lieu dans ce champ (tout comme dans les autres champs de cette catégorie : BuildDepends, RuntimeDepends, Provides, Conflicts, Replaces, Recommends, Suggests et Enhances). C'est, en général, une liste de noms de paquets séparés par des virgules, mais Fink gère maintenant les clauses de choix et de version avec la même syntaxe que dpkg. En voici un exemple :

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

Notez qu'on ne peut indiquer de réelles options de dépendances. Si un paquet fonctionne avec ou sans un autre paquet, vous devez soit vous assurer que l'autre paquet n'est pas utilisé, même s'il est présent, soit l'ajouter à la liste des dépendances. Si vous voulez donner à l'utilisateur le choix entre les deux options, faîtes deux paquets distincts, par exemple : wget et wget-ssl.

Ordre des opérations : le "OU" logique (liste de choix exclusifs) a priorité sur le "ET" logique entre chaque paquet (ou jeu de choix) dans la liste séparée par des virgules. À moins de mettre des parenthèses comme celles utilisées en arithmétique, il n'y a aucun moyen de spécifier des groupes de choix ou de changer l'ordre des opérations dans le champ Depends et les champs similaires.

À partir d'une version CVS postérieure à la version 0.18.2 de fink, on peut utiliser des dépendances conditionnelles. Celles-ci sont indiquées en plaçant (chaîne1 opérateur chaîne2) avant le nom du paquet. L'interprétation des raccourcis se fait normalement, puis les deux chaînes sont comparées en fonction de l'opérateur utilisé, qui peut être : <<, <=, =, !=, >>, >=. Le paquet qui suit n'est considéré comme une dépendance que si la comparaison est vraie.

Vous pouvez utiliser ce format pour simplifier la maintenance de paquets similaires. Par exemple, elinks et elinks-ssl peuvent avoir :

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

Ce qui a le même effet que si elinks avait :

Depends: expat-shlibs

et elinks-ssl avait :

Depends: openssl097-shlibs, expat-shlibs

Vous pouvez aussi utiliser un autre type de syntaxe : (chaîne de caractères), qui est "vrai" si la chaîne de caractères est non nulle. Par exemple :

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

indiquera une dépendance du paquet x11 pour la variante nethack-x11, mais pas pour la variante nethack.

Notez que quand on utilise les champs Depends/BuildDepends pour les paquets de bibliothèques partagées, alors qu'il existe plus d'une version majeure disponible, il ne faut pas utiliser la syntaxe suivante :

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

même si le paquet peut fonctionner avec l'une ou l'autre bibliothèque. Il faut en choisir une (de préférence, la version la plus élevée possible) et s'y tenir dans l'ensemble du paquet.

Comme cela a été expliqué dans la section Librairies partagées, un seul des paquets -dev peut être installé à un instant donné, et chacun possède des liens de même nom qui peuvent se référer à des noms de fichiers différents dans le paquet associé -shlibs. Lors de la compilation du paquet foo, le nom réel du fichier (dans le paquet -shlibs) est codé en dur dans le binaire foo. Cela signifie que le paquet résultant nécessite le paquet -shlibs associé au -dev qui était installé au moment de la compilation. En conséquence, on ne peut indiquer dans le champ Depends que l'un quelconque des paquets est requis.

Auparavant, les paquets non essentiels dépendaient implicitement des paquets essentiels ; ce n'est plus vrai.

BuildDepends

Introduit dans fink 0.9.0. Liste de dépendances utilisées uniquement lors de la compilation. Il sert à spécifier des outils (par exemple flex) qui doivent être présents pour compiler les paquets, mais qui ne sont pas nécessaires à l'exécution. Utilise la même syntaxe que Depends. Si les séries de tests sont activées, les dépendances du champs TestDepends sont ajoutés à cette liste.

RuntimeDepends

Introduit dans fink 0.32.0. A list of dependencies that is applied at run time only, that is, when the package is being installed. This can be used to list packages that must be present to run the package, but which are not used at build time. Supports the same syntax as Depends.

Provides

Liste de noms de paquets séparés par des virgules que ce paquet est censé "fournir". Si un paquet nommé "pine" indique Provides: mailer, alors toute dépendance à "mailer" est considérée comme satisfaite si "pine" est installé. En général, on énumère aussi ces paquets dans les champs "Conflicts" et "Replaces".

Notez qu'aucun numéro de version n'est associé aux éléments Provides. Ils n'héritent pas du paquet parent qui contient la liste Provides, et il n'existe aucune syntaxe permettant d'indiquer un numéro de version dans le champ Provides lui-même. En outre, une dépendance contenant un numéro de version n'est pas satisfaite par un paquet qui a un champ Provides contenant le paquet dépendant. En conséquence, le fait d'avoir plusieurs variantes avec un champ Provides qui inclut un même paquet peut être dangereux, car cela revient à interdire l'utilisation des numéros de versions dans les dépendances. Par exemple, si foo-gnome et foo-nognome ont tous les deux un champ "Provides: foo", tout autre paquet contenant un champ "Depends: foo (> 1.1)" ne fonctionnera pas correctement.

Conflicts

Liste de noms de paquets séparés par des virgules qui ne doivent pas être installés en même temps que le paquet. Pour les paquets virtuels, on peut énumérer dans ce champ les noms des paquets fournis ; ils seront gérés correctement. Ce champ gère aussi les clauses de versions tout comme le champ Depends, mais pas les clauses de choix (cela n'aurait aucun sens). Si un paquet est nommé dans son propre champ Conflicts, il sera supprimé de cette liste (sans avertissement). (Introduit dans une version CVS de fink postérieure à la version 0.18.2).

Note : Fink lui-même ignore ce champ à l'heure actuelle. Néanmoins, il est passé à dpkg et est géré en conséquence. Bref, il n'a d'effet qu'à l'exécution, pas à la compilation.

BuildConflicts

Liste de paquets qui ne doivent pas être installés lorsque le paquet est compilé. Ce champ peut être utilisé pour empêcher ./configure ou le compilateur de détecter des headers debibliothèques ou pour éviter d'utiliser une certaine version d'un outil connue pour être boguée (par exemple, un bogue dans une certaine version de sed). Si les séries de tests sont activées, les paquets énumérés dans le champt TestConflicts sont ajoutés à cette liste.

Replaces

Utilisé en général avec "Conflicts", quand le paquet non seulement remplace les fonctions du paquet en conflit, mais a aussi des fichiers en commun. Sans ce champ, dpkg pourrait générer des erreurs lors de la phase d'installation du paquet, car certains fichiers appartiendraient toujours à un autre paquet. C'est aussi l'indication que les deux paquets en cause sont équivalents l'un l'autre, et que l'un peut être remplacé par l'autre. Si un paquet est nommé dans son propre champ Replaces, il sera supprimé (sans avertissement) de cette liste. (Introduit dans une version CVS de fink postérieure à la version 0.18.2).

Note : Fink lui-même ignore ce champ à l'heure actuelle. Néanmoins, il est passé à dpkg et est géré en conséquence. Bref, il n'a d'effet qu'à l'exécution, pas à la compilation.

Recommends, Suggests, Enhances

Ces champs indiquent des relations supplémentaires spécifiques dans le même style que les autres champs de dépendances. Ces trois champs n'ont aucun effet sur l'installation via dpkg ou apt-get. Néanmoins, ils sont utilisés par dselect et d'autres interfaces pour aider l'utilisateur à faire des choix.

Pre-Depends

Une variante spéciale du champ Depends avec une sémantique plus stricte. Ce champ ne doit être utilisé qu'après en avoir discuté sur la liste de développeurs et qu'il soit apparu évident que cela était nécessaire.

Essential

Valeur booléenne qui signale les paquets essentiels. Ceux-ci sont installés lors du processus de bootstrap. dpkg refusera de supprimer les paquets essentiels du système, à moins d'utiliser des options spéciales, qui permettent de lever cette interdiction. Auparavant, les paquets non essentiels dépendaient implicitement des paquets essentiels ; ce n'est plus vrai.

BuildDependsOnly

Introduit dans fink 0.9.9. Valeur booléenne qui indique qu'aucun autre paquet ne doit avoir un champ Depends le mentionnant, seul le champ BuildDepends est autorisé. Contrairement aux autres champs booléens, BuildDependsOnly a trois valeurs : indéfini (non spécifié) n'a pas le même sens que faux. Voir la section Librairies partagées pour de plus amples informations.

À partir de la version 0.20.5 de fink, la présence ou l'absence de ce champ, et sa valeur s'il est présent, sont sauvegardées dans le fichier .deb à la construction du paquet. Par conséquent, si vous changez la valeur de BuildDependsOnly, ou si vous l'ajoutez ou le supprimez, vous devez incrémenter le numéro de révision du paquet.

Phase de décompression :

ChampUtilisation
CustomMirror

Liste de sites miroirs. Chaque ligne correspond à un site miroir, sous le format suivant : <emplacement>: <url>. L'emplacement peut être un code continent (par exemple : nam - Amérique du Nord), un code pays (par exemple : nam-us - Amérique du Nord-États-Unis), ou bien autre chose ; les archives sont recherchées sur les miroirs dans l'ordre d'énumération de ces derniers. Exemple :

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

Les codes des continents et des pays se trouvent dans le fichier /sw/lib/fink/mirror/_keys, qui est partie intégrante des paquets fink et fink-mirrors.

Source

URL de l'archive tar du source. Ce doit être une URL HTTP ou FTP, mais Fink ne fait pas de vérification - il se contente de passer l'URL à wget. Ce champ gère un type spécial d'URL pour les miroirs : miroir:<nom-miroir>:<chemin-relatif>. Ainsi, la définition du miroir nom-miroir est récupérée dans le fichier de configuration de Fink, la partie chemin-relatif y est ajoutée, et c'est l'ensemble qui est utilisé comme réelle URL. Chaque nom-miroir reconnu est stocké dans le fichier /sw/lib/fink/mirror/_list, qui fait partie du paquet fink ou du paquet fink-mirrors. Par ailleurs, l'utilisation de custom comme nom-miroir oblige Fink à utiliser le champ CustomMirror. L'interprétation des raccourcis a lieu avant utilisation de l'URL. N'oubliez pas que %n correspond à toutes les variantes du champ %type_, il est donc conseillé d'utiliser ici %{ni} (avec, éventuellement, des spécifications de %type_).

À partir de fink 0.18.0, Source: none indique qu'il n'y a pas de source à récupérer. Voir la description du champ Type pour de plus amples informations. La valeur gnu est un raccourci pour mirror:gnu:%n/%n-%v.tar.gz ; de même, gnome est un raccourci pour mirror:gnome:stable/sources/%n/%n-%v.tar.gz. La valeur par défaut est %n-%v.tar.gz (correspond à un téléchargement ordinaire). Cette forme de définition implicite pour Source est obsolète (il est toujours possible de fournir un nom de fichier explicite ou d'opérer un téléchargement manuel).

Les sources nécessaires à la seule exécution des séries de tests doivent être placés à l'intérieur d'un bloc InfoTest et utilisés les champs de type TestSource.

SourceN

Quand un paquet est constitué de plusieurs archives tar, vous devez les énumérer en utilisant ces champs supplémentaires, où N commence à 2. Le premier fichier archive tar (sorte d'archive tar "principale") est indiqué dans Source, le second dans Source2, et ainsi de suite. Les règles sont les mêmes que celles en vigueur pour le champ Source, mais les raccourcis "gnu" et "gnome" ne sont pas interprétés - cela n'aurait aucune utilité par ailleurs. À partir d'une version CVS de fink postérieure à la version 0.19.2, vous pouvez utiliser n'importe quels nombres entiers N >= 2 (non nécessairement consécutifs). Néanmoins, les doublons ne sont pas autorisés.

SourceDirectory

Doit être utilisé quand la décompression de l'archive tar aboutit à la création d'un répertoire dont le nom est différent du nom de base de l'archive. En général, une archive tar nommée "foo-1.0.tar.gz" crée un répertoire nommé "foo-1.0". Si le répertoire créé porte un nom différent, indiquez-le dans ce champ. L'interprétation des raccourcis y est effectuée.

NoSourceDirectory

Donnez à ce paramètre booléen la valeur "true" si la décompression de l'archive tar ne crée pas de répertoire. En général, une archive tar nommée "foo-1.0.tar.gz" crée un répertoire nommé "foo-1.0". Si les fichiers sont simplement décompressés dans le répertoire en cours, utilisez ce champ et donnez-lui la valeur "true".

SourceNExtractDir

Normalement, une archive tar auxiliaire est extraite dans le même répertoire que l'archive tar principale. Si vous devez l'extraire dans un sous-répertoire spécifique, utilisez ce champ pour l'indiquer. Source2ExtractDir correspond, bien évidemment, à l'archive tar Source2. Voir ghostscript, vim et tetex comme exemples d'utilisation de ce champ.

SourceRename

Ce champ renomme une archive tar à la volée. Ceci est utile, par exemple, lorsque la version du source est encodée dans le nom du répertoire du serveur, mais que l'archive elle-même porte le même nom pour toutes les versions, comme http://www.foobar.org/coolapp/1.2.3/source.tar.gz. Pour résoudre les problèmes que cela cause, vous pouvez utiliser quelque chose de similaire à :

SourceRename: %n-%v.tar.gz

Dans l'exemple ci-dessus, l'archive tar sera sauvegardée sous /sw/src/coolapp-1.2.3.tar.gz.

SourceNRename

Ce champ est semblable au champ SourceRename, mais il est utilisé pour renommer l'archive tar correspondant au champ SourceN. Voir context ou hyperref comme exemples d'utilisation de ce champ.

Source-MD5

Introduit dans fink 0.10.0. Vous pouvez indiquer dans ce champ la somme de contrôle MD5 du fichier source. La valeur sera alors utilisée par Fink pour détecter les fichiers sources incorrects, c'est-à-dire les archives tar qui ne correspondent pas à celles que le créateur du paquet a utilisées. Les causes les plus courantes de ce type de problème sont : téléchargement incomplet de l'archive, mainteneurs en amont ayant changé l'archive sans le signaler, chevaux de Troie ou attaques similaires, etc...

Exemple :

Source-MD5: 4499443fa1d604243467afe64522abac

La somme de contrôle est calculée avec l'outil md5sum. Si vous voulez calculer la somme de contrôle de l'archive tar /sw/src/apache_1.3.23.tar.gz, exécutez la commande suivante (le résultat est affiché au-dessous) :

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

La valeur affichée à gauche correspond à la valeur recherchée.

SourceN-MD5

Introduit dans fink 0.10.0. Ce champ est semblable au champ Source-MD5, mais il est utilisé pour indiquer la somme de contrôle MD5 de l'archive tar correspondant au champ SourceN.

TarFilesRename

Introduit dans fink 0.10.0. Ce champ ne s'applique qu'aux fichiers sources utilisant le format tar.

Avec ce champ, vous pouvez renommer les fichiers d'une archive tar donnée durant l'extraction. Ceci est très utile pour gérer les problèmes dus au fait que le système de fichiers HFS+ ne tient pas compte de la casse. En effet, sur un système standard Mac OS X, les fichiers install et INSTALL ne sont pas distinguables. L'utilisation de ce champ permet d'éviter ces problèmes sans avoir à changer l'archive tar (comme on le faisait auparavant dans de tels cas).

Indiquez juste la liste des fichiers à renommer dans ce champ. Vous pouvez utiliser des caractères joker. Par défaut, à tout fichier spécifié dans la liste est ajouté le suffixe _tmp. Vous pouvez modifier ce comportement en utilisant la même syntaxe que celles des champs Files et DocFiles, c'est-à-dire en écrivant l'ancien nom suivi de deux-points, puis du nouveau nom. Exemple :

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

Introduit dans fink 0.10.0. Ce champ est similaire au champ TarFilesRename, mais il est utilisé pour renommer l'archive tar correspondant au champ SourceN.

Phase d'application des rustines :

ChampUtilisation
UpdateConfigGuess

Valeur booléenne. Si elle est vraie ("true"), les fichiers config.guess et config.sub présents dans le répertoire de compilation sont remplacés par des versions reconnaissant Darwin. Ce remplacement se produit lors de la phase d'application des rustines avant que le script PatchScript soit exécuté. N'utilisez ce champ quand cas d'absolue nécessité, c'est-à-dire lorsque le script configure se termine inopinément par un message "unknown host" (système inconnu).

UpdateConfigGuessInDirs

Introduit dans une version CVS postérieure à la version 0.9.0. Liste de sous-répertoires. A le même effet que UpdateConfigGuess, mais dans toute l'arborescence du source ; utile lorsque plusieurs fichiers config.guess existent dans différents répertoires du source. Auparavant, il fallait copier ou déplacer les fichiers dans le script PatchScript. Avec ce nouveau champ, il suffit de donner la liste des répertoires. Utilisez . pour mettre à jour les fichiers dans le répertoire de compilation.

UpdateLibtool

Valeur booléenne. Si elle est vraie ("true"), les fichiers ltconfig et ltmain.sh présents dans le répertoire de compilation sont remplacés par des versions reconnaissant Darwin. Ce remplacement se produit lors de la phase d'application des rustines avant que le script PatchScript soit exécuté. N'utilisez ce champ quand cas d'absolue nécessité. Certains paquets ne fonctionnent plus lorsqu'on modifie la version des scripts libtool. Voir la page libtool pour de plus amples informations.

UpdateLibtoolInDirs

Introduit dans une version CVS postérieure à la version 0.9.0. Liste de sous-répertoires. A le même effet que UpdateLibtool ; utile lorsque plusieurs fichiers scripts libtool 1.3.x sont présents dans différents répertoires de l'arborescence du source. Auparavant, il fallait copier ou déplacer les fichiers dans le script PatchScript. Avec ce nouveau champ, il suffit de donner la liste des répertoires. Utilisez . pour mettre à jour les fichiers dans le répertoire de compilation.

UpdatePoMakefile

Valeur booléenne. Si elle est vraie ("true"), le fichier Makefile.in.in présent dans le sous-répertoire po est remplacé par une version modifiée. Ce remplacement se produit lors de la phase d'application des rustines avant que le script PatchScript soit exécuté.

La version modifiée prend en compte DESTDIR et garantit que les catalogues de messages seront placés dans /sw/share/locale, et non pas dans /sw/lib/locale. Assurez-vous, avant d'utiliser ce champ, qu'il est absolument nécessaire et que le paquet continuera à fonctionner. Vous pouvez exécuter diff pour trouver les différences entre la version du paquet et celle de Fink (située dans /sw/lib/fink/update).

Patch

Le nom d'une rustine à appliquer avec patch -p1 <nom-rustine. Ne donnez que le nom du fichier ; le chemin est ajouté automatiquement devant le nom du fichier. L'interprétation des raccourcis y est effectuée, si bien qu'on trouve, en général : %f.patch ou %n.patch. La rustine est appliquée avant que le script PatchScript soit exécuté (s'il existe).

N'oubliez pas que %n inclut implicitement toutes les variantes %type_. Le cas échéant, utilisez %{ni} (éventuellement avec des variantes spécifiques %type_). Il est plus facile de gérer une seule rustine et de faire des changements spécifiques à certaines variantes dans le script PatchScript que de gérer une rustine par variante.

PatchScript

Liste de commandes à exécuter lors de la phase d'application des rustines. C'est là où vous pouvez placer les commandes qui corrigent ou modifient le paquet source. Voir plus loin la note au sujet des scripts. L'interprétation des raccourcis a lieu avant que les commandes ne soient exécutées. Il n'existe pas de script par défaut.

Phase de compilation :

ChampUtilisation
SetENVVAR

Définit certaines variables d'environnement pendant les phases de compilation et d'installation. On peut utiliser ce champ pour passer des drapeaux de compilation, etc... aux scripts configure et aux Makefile. Les variables reconnues à l'heure actuelle sont : CC, CFLAGS, CPP, CPPFLAGS, CXX, CXXFLAGS, DYLD_LIBRARY_PATH, JAVA_HOME, LD, LDFLAGS, LIBRARY_PATH, LIBS, MACOSX_DEPLOYMENT_TARGET, MAKE, MFLAGS, MAKEFLAGS. L'interprétation des raccourcis a lieu sur la valeur spécifiée, comme expliquée dans la section précédente. Exemple courant :

SetCPPFLAGS: -no-cpp-precomp

Certaines de ces variables ont des valeurs pré-établies par défaut. Si vous leur donnez une valeur, celle-ci sera ajoutée dans la liste devant la valeur par défaut. Les variables à valeur pré-établies sont les suivantes :

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

À partir de la version 0.26.0 de fink, il existe une exception à ces valeurs par défaut. Si le champ Type: -64bit a pour valeur -64bit, alors la valeur par défaut de la variable LDFLAGS est -L%p/%lib -L%p/lib.

Enfin, la variable MACOSX_DEPLOYMENT_TARGET a une valeur par défaut qui dépend de la version de Mac OS X en cours d'exécution, mais le fait d'affecter une valeur à cette variable pour un paquet donné remplace la valeur par défaut, elle ne vient pas s'ajouter devant la valeur par défaut.

NoSetENVVAR

Quand la valeur de ce champ est true (vraie), les valeurs par défaut des variables à valeurs pré-établies, telles CPPFLAGS, LDFLAGS et CXXFLAGS mentionnées ci-dessus, sont désactivées. Autrement dit, si vous ne voulez pas que LDFLAGS ait une valeur par défaut, utilisez NoSetLDFLAGS: true.

ConfigureParams

Paramètres supplémentaires à passer au script configure. (Voir CompileScript pour de plus amples informations). Pour les paquets qui ne sont pas de Type: Perl, le paramètre --prefix=%p est ajouté avant la valeur de ce champ. À partir des versions de fink > 0.13.7, ce champ fonctionne aussi avec les modules perl Type: Perl ; il ajoute les paramètres à la chaîne perl par défaut Makefile.PL.

Si les séries de tests sont activées, la valeur du champ TestConfigureParams est ajoutée à ces paramètres.

À partir de la version 0.22.0 de fink, ce champ gère les expressions conditionnelles. La syntaxe est la même que celle utilisée dans le champ Depends et les autres champs basés sur des listes de paquets. L'expression conditionnelle s'applique au "mot" délimité par des espaces suivant immédiatement l'expression. Par exemple :

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

passera les drapeaux --mandir et --disable-shared dans tous les cas de figure, mais ne passera le drapeau --with-x11 qu'à la seule variante -x11.

GCC

Ce champ spécifie l'ABI-GCC utilisé par le code C++ du paquet (cela est indispensable, car l'ABI a changé deux fois au cours du temps; toute bibliothèque liée à du code C++ doit être compilée avec l'ABI résidant sur le système au moment de son utilisation).

Les valeurs autorisées sont les suivantes : 2.95.2 (ou 2.95), 3.1, 3.3 et 4.0. Nous avons cru comprendre que les auteurs de GCC comptent stabiliser l'ABI-GCC à un moment donné ; nous espérons qu'elle ne changera pas de nouveau.

Le champ GCC n'a pas de valeur par défaut ; il est ignoré s'il n'est pas défini. Néanmoins il existe dans chaque arborescence une valeur attendue qui correspond au compilateur g++ par défaut pour cette arborescence. Ces valeurs sont les suivantes : 2.95 pour l'arborescence 10.1, 3.1 pour l'arborescence 10.2, 3.3 pour les arborescences 10.2-gcc3.3, 10.3 et 10.4-transitional, et 4.0 pour l'arborescence 10.4 à venir.

Notez que lorsque la valeur GCC est différente de la valeur par défaut, le compilateur doit être indiqué dans le paquet (en général, en utilisant les drapeaux CC ou CXX), et qu'une dépendance sur un des paquets (virtuels) gcc doit être spécifiée.

À partir de la version 0.13.8 de fink, quand ce champ est utilisé, la version de gcc est testée via gcc_select, et fink se termine avec un message d'erreur si la version requise n'est pas présente.

Ce champ a été ajouté pour faciliter la transition entre les compilateurs gcc, qui ont introduit une incompatibilité binaire entre bibliothèques ; cette incompatibilité concerne des parties de code C++ non reproduites dans les différentes versions.

CompileScript

Liste de commandes à exécuter durant la phase de compilation. C'est là qu'il faut mettre les commandes de configuration et de compilation du paquet. Voir plus loin la note au sujet des scripts. L'interprétation des raccourcis a lieu avant que les commandes ne soient exécutées. Normalement, les commandes sont les suivantes :

./configure %c
make

Elles conviennent pour les paquets utilisant GNU autoconf. Pour ceux de type perl (indiqué via le champ Type) dont la version perl n'est pas indiquée, les commandes par défaut (à partir de la version 0.13.4 de fink) sont les suivantes :

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

Si le type est du style perl $version (où $version est, par exemple, 5.6.0), les commandes par défaut sont les suivantes :

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

$perlarchdir est "darwin" pour les versions antérieures ou égales à 5.8.0, "darwin-thread-multi-2level" pour les versions postérieures ou égales à 5.8.1.

NoPerlTests

Introduite dans une version de fink > 0.13.7. Valeur booléenne spécifique aux paquets de module perl. Si sa valeur est true (vraie), la partie make test de CompileScript est ignorée pour ce paquet.

Séries de tests :

ChampUtilisation
InfoTest

Introduit dans la version 0.25 de fink. Ce champ englobe les données spécifiques à utiliser pour exécuter les séries de tests. Il contient d'autres champs. Si ce champ est présent, il doit inclure un champ TestScript. Tous les autres champs sont facultatifs. Les champs autorisés à l'intérieur du champ InfoTest sont les suivants :

  • TestScript : script d'exécution de la série de tests. Ce script doit retourner un statut de valeur 0 si la série de tests s'est déroulée sans incident, de 1 s'il y a des messages d'attention, et de n'importe quelle autre valeur si les incidents sont suffisamment sévères pour les considérer comme fatals. Du fait de cette logique à trois états, la valeur du statut doit être explicitement indiquée. Par exemple, make check n'est pas conforme à cette logique, puisqu'il retourne un statut de 1 si la cible à vérifier n'existe pas ; par contre, make check || exit 2 respecte la logique à trois états.
  • TestConfigureParams : valeur ajoutée au champ ConfigureParams.
  • TestDepends et TestConflicts : liste des paquets à ajouter respectivement aux champs BuildDepends et BuildConflicts.
  • TestSource : sources supplémentaires nécessaires pour exécuter la série de tests. Tous les champs liés à ce champ sont autorisés. On doit donc aussi utiliser le champ TestSource-MD5. On peut aussi se servir des champs TestSourceN et TestSourceN-MD5, TestTarFilesRename, etc...
  • TestSuiteSize : donne une idée approximative de la durée d'exécution de la série de tests. Les valeurs permises sont les suivantes : small, medium et large. Ce champ est pour l'instant ignoré.
  • Tout autre champ standard. Si un champ est indiqué à la fois à l'intérieur et à l'extérieur du bloc InfoTest, c'est sa valeur à l'intérieur du bloc InfoTest qui sera utilisée si la suite de tests est activée.

Voici un exemple :

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

Phase d'installation :

ChampUtilisation
UpdatePOD

Introduit dans la version 0.9.5 de fink. Valeur booléenne réservée aux paquets de module perl. Si sa valeur est true (vraie), du code est ajouté aux scripts install, postrm et postinst, qui gèrent les fichiers .pod fournis par les paquets perl. En particulier, la date .pod est ajoutée et ôtée du fichier central /sw/lib/perl5/darwin/perllocal.pod. (Si le type est du style perl $version, où $version est, par exemple, 5.6.0, les scripts sont adaptés pour gérer le fichier central .pod /sw/lib/perl5/$version/perllocal.pod).

InstallScript

Liste de commandes à exécuter durant la phase d'installation. C'est là où il faut mettre les commandes qui copient tous les fichiers requis dans le répertoire de construction du paquet. Voir plus loin la note au sujet des scripts. L'interprétation des raccourcis a lieu avant que les commandes ne soient exécutées. Normalement, on utilise :

make install prefix=%i

Ceci convient pour les paquets utilisant GNU autoconf. Pour ceux de type perl (indiqué via le champ Type) dont la version perl n'est pas indiquée, les commandes par défaut (à partir de la version 0.13.4 de fink) sont les suivantes :

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

Si le type est du style perl $version (où $version est, par exemple, 5.6.0), les commandes par défaut sont les suivantes :

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

$perlarchdir est "darwin" pour les versions antérieures ou égales à 5.8.0, et "darwin-thread-multi-2level" pour les versions postérieures ou égales à 5.8.1.

Si le paquet l'admet, il est préférable d'utiliser make install DESTDIR=%d.

AppBundles

Introduit dans une version postérieure à la version 0.23.1. Ce champ installe le(s) lot(s) dans le répertoire %p/Applications. Il crée également un lien symbolique vers le répertoire /Applications/Fink. Exemple :

AppBundles: build/*.app Foo.app
JarFiles

Introduit dans la version 0.10.0 de fink. Champ similaire au champ DocFiles. Il installe les fichiers jar spécifiés dans %p/share/java/%n. Exemple :

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

Cette commande installe tous les fichiers jar situés dans le répertoire lib, puis installe le fichier foo.jar sous le nom de fooBar.jar.

Elle garantit aussi que les fichiers jar (en fait, tous les fichiers d'extension .jar situés dans %p/share/java/%n) sont ajoutés à la variable d'environnement CLASSPATH. Ceci permet aux outils tels configure ou ant de détecter correctement les fichiers jar installés.

DocFiles

Ce champ fournit un moyen simple d'installer les fichiers README et COPYING dans le répertoire doc du paquet, soit %p/share/doc/%n. Sa valeur consiste en une liste de fichiers séparés par des espaces. Vous pouvez copier les fichiers à partir de sous-répertoires du répertoire de compilation, ils seront placés dans le répertoire lui-même et non pas dans un sous-répertoire. Les caractères joker reconnus par le shell sont autorisés. On peut aussi renommer des fichiers à la volée en faisant suivre le nom du fichier de deux-points (:), puis du nouveau nom. Exemple :libgimp/COPYING:COPYING.libgimp. Ce champ ajoute les commandes install appropriées au script InstallScript.

Shlibs

Introduit dans la version 0.11.0 de fink. Ce champ déclare les bibliothèques partagées installées dans le paquet. There is one line for each shared library, which contains the -install_name of the library and information about its binary compatibility. Shared libraries that are "public" (i.e., provided for use by other packages) have, separated by whitespace after the filename, the -compatibility_version, versioned package dependency information specifying the Fink package which provides this library at this compatibility version, and the library architecture. Cette architecture peut avoir pour valeur "32", "64", "32-64" ou même ne pas exister ; dans ce dernier cas, elle prend la valeur "32" par défaut. Les informations de dépendance doivent être spécifiées sous la forme foo (>= version-revision), où version-revision représente la première version d'un paquet Fink qui rend disponible cette bibliothèque (avec cette version de compatibilité). La déclaration Shlibs revient à dire que le mainteneur du paquet garantit qu'une bibliothèque portant ce nom et ayant une version de compatibilité au moins égale à -compatibility_version sera présente dans toutes les versions postérieures de ce paquet Fink. Shared libraries that are "private" are denoted by an exclamation mark preceeding the filename, and no compatilibity or versioning information is given. See the Shared Library Policy for more information.

RuntimeVars

Introduit dans fink 0.10.0. Ce champ fournit un moyen pratique de donner une valeur statique à des variables d'environnement pendant l'exécution (si vous voulez avoir plus de latitude dans ce domaine, voir la section scripts profile.d). À partir du moment où le paquet est installé, ces variables sont définies par les scripts /sw/bin/init.[c]sh.

La valeur de la variable peut contenir des espaces (seuls les espaces de fin de chaîne sont supprimés) ; l'interprétation des raccourcis a eu lieu sur ce champ. Exemple :

RuntimeVars: <<
 UneVariable: %p/Valeur
 UneAutreVariable: toto tata
<<

définit deux variables d'environnement 'UneVariable' et 'UneAutreVariable' ; leurs valeurs seront respectivement '/sw/Valeur' (si votre préfixe est /sw) et 'toto tata'.

Ce champ ajoute les commandes appropriées au script InstallScript. Ces commandes ajoutent une ligne setenv/export pour chaque variable aux scripts profile.d du paquet ; vous pouvez donc spécifier vos propres commandes, elles ne seront pas remplacées. Les lignes sont ajoutées en début de scripts, vous pouvez donc utiliser ces variables dans vos scripts.

SplitOff

Introduit dans fink 0.9.9. Génère un second paquet à partir d'une seule exécution du couple compilation/installation. Pour avoir de plus amples informations sur la façon dont ce champ fonctionne, voir la section splitoff ci-dessous.

SplitOffN

Introduit dans fink 0.9.9. Similaire au champ SplitOff, utilisé pour générer un N-ième paquet à partir d'une seule exécution du couple compilation/installation. À partir d'une version CVS de fink postérieure à la version 0.19.2, vous pouvez utiliser des valeurs entières (non nécessairement consécutives) de N >= 2. Néanmoins, il ne peut pas y avoir de doublons.

Files

Introduit dans fink 0.9.9. Utilisé uniquement avec un champ SplitOff ou SplitOffN, ce champ indique quels fichiers et répertoires doivent être déplacés du répertoire d'installation %I du paquet parent vers le répertoire d'installation en cours %i. Notez que le déplacement a lieu après l'exécution des scripts InstallScript et DocFiles du paquet parent, mais avant l'exécution des mêmes scripts du paquet en cours d'installation.

Phase de construction :

ChampUtilisation
PreInstScript, PostInstScript, PreRmScript, PostRmScript

Ces champs correspondent à des scripts shell qui seront appelés lors de l'installation, la mise à jour ou la suppression du paquet. Fink ajoute automatiquement l'en-tête du script shell #!/bin/sh et appelle set -e, de façon à ce que tout échec d'une commande entraîne 'arrêt immédiat du script. Fink ajoute aussi exit 0 à la fin du script. Pour signaler une erreur, utilisez exit avec un code non nul. Le premier paramètre ($1) contient une valeur indiquant l'action à faire. Exemples de valeurs possibles : install, upgrade, remove et purge. Notez qu'il existe d'autres valeurs, utilisées lors des reprises sur erreur et du remplacement d'un paquet par un autre.

Ces différents scripts sont appelés lors des évènements suivants :

  • PreInstScript : lors de la première installation d'un paquet et avant la mise à jour d'un paquet à la même version.
  • PostInstScript : après le dépaquetage et la définition des variables spécifiques au paquet.
  • PreRmScript : avant la suppression et la mise à jour d'un paquet à une version ultérieure.
  • PostRmScript : après la suppression et la mise à jour du paquet à une version ultérieure.

Soyons plus clair. Une mise à jour invoque à la fois les scripts ...Inst de la nouvelle version et les scripts ...Rm de l'ancienne version. Vous trouverez de plus amples informations à ce sujet dans le Chapitre 6 du Manuel des normes Debian.

L'interprétation des raccourcis a lieu dans ces scripts. Les commandes peuvent, en général, être lancées sans donner leur chemin complet.

ConfFiles

Liste de fichiers séparés par des espaces. Ces fichiers sont des fichiers de configuration modifiables par l'utilisateur. L'interprétation des raccourcis a lieu sur ce champ. Le chemin complet des fichiers doit être indiqué, comme dans %p/etc/%n.conf. Ces fichiers sont traités de façon spéciale par dpkg. Quand un paquet est mis à jour et que le fichier de configuration a changé à la fois sur le disque et dans le paquet, dpkg demande à l'utilisateur quelle version il veut utiliser et sauvegarde l'ancien fichier. Quand un paquet est supprimé avec "remove", les fichiers de configuration ne sont pas supprimés. Pour les supprimer, il faut utiliser "purge".

InfoDocs

Liste des documents Info que le paquet installe dans %p/share/info. Des commandes appropriées sont ajoutées aux scripts postinst et prerm pour mettre à jour le fichier de la hiérarchie Info dir.

Note: Only use the un-numbered file in the case of split Info documents. E.g. if a package has:

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

you should only use:

InfoDocs:  foo.info

Cette fonctionnalité est en cours de développement, d'autres champs pourront être ajoutés à l'avenir pour une gestion plus précise.

DaemonicFile

Décrit un service pour daemonic. daemonic est utilisé par Fink pour créer et supprimer des éléments à lancer au démarrage pour les processus démon (par exemple les serveurs web). La description est ajoutée au paquet sous la forme d'un fichier nommé %p/etc/daemons/nom.xml, où nom est indiqué par le champ DaemonicName et est réduit, par défaut, au nom du paquet. L'interprétation des raccourcis a lieu sur le contenu de ce champ. Notez que vous devez ajouter daemonic à la liste des dépendances, si votre paquet utilise ce champ.

DaemonicName

Nom du fichier de description d'un service daemonic. Voir la description de DaemonicFile pour de plus amples informations.

Autres informations :

ChampUtilisation
Homepage

URL de la page d'accueil du paquet en amont.

DescDetail

Description plus détaillée que celle figurant dans le champ Description (répond aux questions : qu'est-ce que c'est ?, comment l'utiliser?). Les lignes multiples sont autorisées. Comme ce champ sera affiché sans que la longueur des lignes soit adaptée à la largeur de la fenêtre d'affichage, vous devez insérer des sauts de ligne, de façon à ce que les lignes ne dépassent pas 78 caractères (si possible).

DescUsage

Information nécessaire à l'utilisation du paquet (répond à la question : comment l'utiliser ?). Exemple : "exécute wmaker.inst avant d'utiliser WindowMaker". Lignes multiples autorisées. Comme ce champ sera affiché sans que la longueur des lignes soit adaptée à la largeur de la fenêtre d'affichage, vous devez insérer des sauts de ligne, de façon à ce que les lignes ne dépassent pas 78 caractères (si possible).

DescPackaging

Notes sur la construction du paquet. Les éléments du type : "rustine pour le Makefile de sorte que tout aille au bon endroit" sont placés dans ce champ. Lignes multiples autorisées.

DescPort

Notes spécifiques au portage du paquet sur Darwin. Les éléments du type : "scripts config.guess et libtool scripts mis à jour, -no-cpp-precomp nécessaire" sont placés dans ce champ. Lignes multiples autorisées.

6.3 Paquets multiples

À partir de la version 0.9.9 de fink, on peut utiliser un seul fichier .info pour construire plusieurs paquets. La phase d'installation commence, comme pour tout autre type de paquet, par l'exécution des scripts InstallScript et DocFiles. Si un champ SplitOff ou SplitOffN est présent, il y a création d'un répertoire d'installation supplémentaire. À l'intérieur des champs SplitOff et SplitOffN, le nouveau répertoire d'installation est désigné par %i, tandis que le répertoire d'installation du paquet parent est désigné par %I.

Chaque champ SplitOff ou SplitOffN doit contenir un certain nombre de champs qui lui sont propres. En fait, cela ressemble à une description de paquet ordinaire, mais certains champs sont omis. Voici les champs qui peuvent y figurer (classés par catégorie) :

Comme %n-%v-%r représente l'identifiant unique d'un paquet, on ne peut avoir le même champ Package (avec les mêmes champs Version et Revision) dans un SplitOff (ou dans un SplitOffN) d'un paquet multiple. Si l'on utilise des variantes, il faut se rappeler que chaque variante est considérée comme un paquet indépendant des autres. Il s'ensuit que la disposition suivante est interdite :

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

Lors de la phase d'installation, les champs InstallScript et DocFiles du paquet parent sont exécutés en premier. Puis vient l'exécution des champs SplitOff et SplitOffN. Pour chacun de ces champs à tour de rôle, la commande Files déplace les fichiers et répertoires spécifiés, du répertoire d'installation %I du paquet parent dans le répertoire de l'installation en cours %i. Puis les scripts InstallScript et DocFiles des paquets SplitOff et SplitOffN sont exécutés.

À l'heure actuelle, le champ SplitOff, s'il existe, est exécuté en premier, suivi des champs SplitOffN par ordre numérique. Néanmoins, cela pourrait changer dans le futur. Il est donc conseillé de ne pas utiliser :

SplitOff: <<
  Description: certains headers
  Files: include/foo.h include/bar.h
<<
SplitOff2: <<
  Description: tous les autres headers
  Files: include/*
<<

qui ne fonctionne correctement que si SplitOff est exécuté avant SplitOff2. Il vaut mieux donner la liste explicite des fichiers pour chaque champ (ou utiliser des noms de fichier plus explicites).

Lors de la phase de construction du paquet, les scripts pre/post install/remove de chacun des paquets sont construits à partir des commandes spécifiques de la phase de construction desdits paquets.

Chaque paquet à construire doit placer les fichiers de licence dans %i/share/doc/%n (avec %n ayant une valeur différente pour chaque paquet). Notez que DocFiles copie les fichiers au lieu de les déplacer ; il est donc possible d'installer une même copie de la documentation dans chacun des paquets en utilisant DocFiles plusieurs fois.

6.4 Scripts

Les champs PatchScript, CompileScript et InstallScript vous permettent d'indiquer des commandes shell à exécuter. Le répertoire de construction (%b) est le répertoire en cours lors de l'exécution des scripts. Vous devez toujours utiliser des chemins relatifs ou des raccourcis pour les fichiers et répertoires de l'arborescence fink, et jamais des chemins absolus. Deux formats différents sont possibles pour ces champs.

Le champ peut être constitué d'une simple liste de commandes, un peu comme un script shell. Néanmoins, les commandes sont exécutées ligne après ligne via system(). Il en résulte que l'assignation de variables ou les changements de répertoire n'ont d'effet que pour les commandes résidant sur une même ligne. À partir d'une version CVS de fink postérieure à 0.18.2, vous pouvez ajuster la longueur des lignes de la même manière que dans les scripts shell : une barre oblique inversée (\) à la fin de la ligne indique que la ligne suivante est la suite de la ligne précédente.

Vous pouvez aussi insérer un script complet, en utilisant l'interpréteur que vous voulez. Comme avec tout autre script Unix, la première ligne doit commencer par #! suivi du chemin complet de l'interpréteur et des options désirées (exemple : #!/bin/csh, #!/bin/bash -ev, etc...). Dans ce cas, la totalité du champ *Script est déversée dans un fichier temporaire, qui est alors exécuté.

6.5 Rustines

Si votre paquet nécessite une rustine pour compiler sous Darwin (ou pour fonctionner avec fink), donnez à la rustine le même nom que celui indiqué dans la description du paquet, en utilisant l'extension ".patch" au lieu de ".info", et placez-la dans le même répertoire que le fichier .info. Si vous utilisez le nom complet du paquet dans le nom du fichier, indiquez-le dans le champ d'une des façons suivantes (elles sont équivalentes) :

Patch: %f.patch
PatchScript: patch -p1 <%a/%f.patch

Si vous utilisez les nouvelles conventions de nommage d'un paquet unique, utilisez %n au lieu de %f. Ces deux champs ne sont pas exclusifs l'un de l'autre ; vous pouvez utiliser les deux et ils seront tous deux exécutés. Dans ce cas, le script PatchScript sera exécuté en dernier.

Comme il se peut que vous ayez besoin du préfixe choisi par l'utilisateur dans le fichier rustine, il est conseillé d'utiliser une variable telle @PREFIX@ au lieu de /sw dans la rustine et d'utiliser ensuite :

PatchScript: sed 's|@PREFIX@|%p|g' <%a/%f.patch | patch -p1

Les rustines doivent être en format unidiff et sont, en général, créées en utilisant :

diff -urN <répertoiredusourceoriginel> <répertoiredusourcemodifié>

Si vous utilisez emacs pour modifier les fichiers, vous devez ajouter -x'*~' à la commande diff ci-dessus, pour exclure les fichiers de sauvegarde générés automatiquement.

Il faut aussi noter que les très grosses rustines ne doivent pas être mises dans cvs. Elles doivent être placées sur un serveur web/ftp et référencées en utilisant le champ SourceN:. Si vous n'avez pas de site web, les administrateurs du projet fink peuvent mettre le fichier à disposition à partir du site web de fink. Si votre rustine fait plus de 30Kb, vous devez la traiter comme un téléchargement distinct.

6.6 Scripts profile.d

Si votre paquet nécessite une initialisation à l'exécution (par exemple, pour définir des variables d'environnement), vous pouvez utiliser des scripts profile.d. Ces scripts sont sourcés par les scripts /sw/bin/init.[c]sh. Normalement, tout utilisateur de fink charge ces scripts dans ses fichiers de démarrage de shell (.cshrc et équivalents). Votre paquet doit fournir deux variantes de scripts : l'une pour les shells compatibles avec sh (sh, zsh, bash, ksh, ...), l'autre pour les shells compatibles avec csh (csh, tcsh). Elles doivent être installées sous la forme /sw/etc/profile.d/%n.[c]sh (où %n représente le nom du paquet). Il faut aussi positionner leurs bits de lecture et d'exécution (c'est-à-dire les installer avec -m 755), autrement elles ne seront pas chargées correctement.

Si vous n'avez besoin que d'initialiser certaines variables d'environnement (par exemple, définir QTDIR comme '/sw'), vous pouvez utiliser le champ RuntimeVars, qui a été conçu exactement pour ce faire.


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.fr.xml,v 1.80 2012/11/11 15:20:16 gecko2 Exp $