Paquets - 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 /opt/sw
du paquet gimp-1.2.1-1.
Lors de la phase de décompression, le répertoire /opt/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 /opt/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, /opt/sw/src/fink.build/root-gimp-1.2.1-1
(= %d). (Notez la partie "root-"). Tous les fichiers qui sont normalement installés dans /opt/sw
sont installés dans /opt/sw/src/fink.build/root-gimp-1.2.1-1/opt/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 :
Champ | Utilisation |
---|---|
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 |
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 --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 |
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 |
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 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 Ce champ admet la syntaxe conditionnelle standard pour toute valeur de la liste. Les raccourcis clavier peuvent y être utilisés (voir le champ 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 |
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
Since Fink's
This field supports the standard conditional syntax for any value in
the value list and percent-expansions can be used (see
the 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 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, 14.0, 15.0 perl 5.18.4: 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, 10.15, 11.0, 11.3, 12.0, 13.0, 14.0, 15.0 perl 5.28.2: 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, 10.15, 11.0, 11.3, 12.0, 13.0, 14.0, 15.0 perl 5.30.2: 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, 10.15, 11.0, 11.3, 12.0, 13.0, 14.0, 15.0 perl 5.30.3: 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, 10.15, 11.0, 11.3, 12.0, 13.0, 14.0, 15.0 perl 5.34.1: 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, 10.14.5, 10.15, 11.0, 11.3, 12.0, 13.0, 14.0, 15.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. |
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 |
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
À partir de fink 0.9.5, il existe un type 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: -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 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 :
|
Dépendances :
Champ | Utilisation |
---|---|
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 À 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 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 : 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 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 |
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 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 |
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 |
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. |
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, À 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 :
Champ | Utilisation |
---|---|
CustomMirror |
Liste de sites miroirs. Chaque ligne correspond à un site miroir, sous le format suivant : 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 |
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 : À partir de fink 0.18.0, Les sources nécessaires à la seule exécution des séries de tests doivent être placés à l'intérieur d'un bloc |
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 |
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 SourceRename: %n-%v.tar.gz Dans l'exemple ci-dessus, l'archive tar sera sauvegardée sous |
SourceNRename |
Ce champ est semblable au 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 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. |
SourceN-MD5 |
Introduit dans fink 0.10.0. Ce champ est semblable au champ |
Source-Checksum |
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 $ shasum -a 256 /opt/sw/src/libexif-0.6.22.tar.xz 5048f1c8fc509cc636c2f97f4b40c293338b6041a5652082d5ee2cf54b530c56 /opt/sw/src/libexif-0.6.22.tar.xz
The |
SourceN-Checksum |
This is just the same as the |
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 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 TarFilesRename: foo bar.* qux:quux Tar2FilesRename: directory/INSTALL:directory/INSTALL.txt |
TarNFilesRename |
Introduit dans fink 0.10.0. Ce champ est similaire au champ |
Phase d'application des rustines :
Champ | Utilisation |
---|---|
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 |
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 |
UpdatePoMakefile |
Valeur booléenne. Si elle est vraie ("true"), le fichier La version modifiée prend en compte DESTDIR et garantit que les catalogues de messages seront placés dans |
Patch |
Le nom d'une rustine à appliquer avec 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 |
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 :
Champ | Utilisation |
---|---|
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 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 |
ConfigureParams |
Paramètres supplémentaires à passer au script configure. (Voir CompileScript pour de plus amples informations). Pour les paquets qui ne sont pas de Si les séries de tests sont activées, la valeur du champ À 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 Type: -x11 (boolean) ConfigureParams: --mandir=%p/share/man (%type_pkg[-x11]) \ --with-x11 --disable-shared passera les drapeaux |
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 : 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 : 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 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 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ù |
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 |
Séries de tests :
Champ | Utilisation |
---|---|
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
Voici un exemple : InfoTest: << TestScript: make check || exit 2 TestConfigureParams: --enable-tests << |
Phase d'installation :
Champ | Utilisation |
---|---|
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 |
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 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ù Si le paquet l'admet, il est préférable d'utiliser |
AppBundles |
Introduit dans une version postérieure à la version 0.23.1. Ce champ installe le(s) lot(s) dans le répertoire 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 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 |
DocFiles |
Ce champ fournit un moyen simple d'installer les fichiers README et COPYING dans le répertoire doc du paquet, soit |
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 |
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 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. |
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 |
Files |
Introduit dans fink 0.9.9. Utilisé uniquement avec un champ |
Phase de construction :
Champ | Utilisation |
---|---|
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 Ces différents scripts sont appelés lors des évènements suivants :
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 |
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 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 |
DaemonicName |
Nom du fichier de description d'un service |
Autres informations :
Champ | Utilisation |
---|---|
Homepage |
URL de la page d'accueil du paquet en amont. |
DescDetail |
Description plus détaillée que celle figurant dans le champ |
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) :
- Données initiales : seul le champ
Package
doit être spécifié, tout le reste est hérité du paquet parent. Vous pouvez modifier les champsType
etLicense
en déclarant ces champs dans les champsSplitOff
etSplitOffN
. On peut utiliser les raccourcis ; il est préférable de mentionner le nom du paquet parent sous la forme %N. - Dépendances : tous les champs sont autorisés.
- Phases de décompression, d'application des rustines, de compilation : ces champs n'ont pas de signification dans ce contexte et seront ignorés s'ils sont présents.
- Phases d'installation et de construction : tous les champs sont autorisés à l'exception des champs SplitOff (un champ SplitOff ne peut contenir lui-même un autre champ SplitOff).
- Données supplémentaires : elles sont héritées du paquet parent, mais peuvent être modifiées en déclarant le champ dans les champs
SplitOff
ouSplitOffN
.
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 /opt/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 /opt/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 /opt/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 '/opt/sw'), vous pouvez utiliser le champ RuntimeVars, qui a été conçu exactement pour ce faire.