Création de paquets Fink

le nom du paquet actif

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

ère du paquet

version du paquet. Notez que l'ère ne fait partie de %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évision du paquet

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

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

répertoire dans lequel le paquet est construit, par exemple : /opt/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 /opt/sw/etc/fink.conf.

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

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

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

chemin des rustines

répertoire de compilation, exemple : /opt/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 /opt/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.

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.

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

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.

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.

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)

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

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.

Librairies partagées

Headers

Binaires, etc...

Librairies partagées

Headers

Binaires, etc...

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

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.

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.

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 /opt/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, /opt/sw/lib/perl5 ou /opt/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.

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

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

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

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.

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.

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

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

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.

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

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

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

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.

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.

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.

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.

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, 10.6, 10.7, 10.8, 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, and 10.15 . 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.9 through 10.14.5 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.5 is not available in the 10.7+ distributions, and the available perl versions 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 through 13.0 distributions (bolded systems indicate system-perl at that version):

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

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.

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

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.

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

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.

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>

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 /opt/sw/lib/fink/mirror/_keys, qui est partie intégrante des paquets fink et fink-mirrors.

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

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.

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.

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

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.

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 /opt/sw/src/coolapp-1.2.3.tar.gz.

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.

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 /opt/sw/src/apache_1.3.23.tar.gz, exécutez la commande suivante (le résultat est affiché au-dessous) :

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

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

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.

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

Source-Checksum: SHA256(5048f1c8fc509cc636c2f97f4b40c293338b6041a5652082d5ee2cf54b530c56)

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

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

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

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

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

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.

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

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.

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.

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.

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 /opt/sw/share/locale, et non pas dans /opt/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 /opt/sw/lib/fink/update).

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.

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.

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.

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.

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.

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.

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

où $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.

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.

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 ou TestSource-Checksum. On peut aussi se servir des champs TestSourceN et TestSourceN-MD5, TestSourceN-Checksum, 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
<<

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

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

où $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.

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

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.

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.

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.

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 /opt/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 '/opt/sw/Valeur' (si votre préfixe est /opt/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.

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.

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.

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.

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.

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

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.

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.

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

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

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

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

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.

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.