Update of /cvsroot/fink/web/xml/packaging
In directory sc8-pr-cvs5.sourceforge.net:/tmp/cvs-serv974
Modified Files:
packaging.fr.xml
Log Message:
Updating to latest English version
Index: packaging.fr.xml
===================================================================
RCS file: /cvsroot/fink/web/xml/packaging/packaging.fr.xml,v
retrieving revision 1.67
retrieving revision 1.68
diff -u -d -r1.67 -r1.68
--- packaging.fr.xml 19 Sep 2006 20:43:29 -0000 1.67
+++ packaging.fr.xml 30 Nov 2006 19:22:01 -0000 1.68
@@ -14,7 +14,7 @@
<section name="def1"><title>Qu'est-ce qu'un paquet ?</title>
<p>Un paquet est un logiciel qui forme une unité atomique. Un paquet contient
en général un programme exécutable, les fichiers de données dont il a
besoin et des catalogues de message pour l'internationalisation et la
documentation. Dans Fink, les paquets peuvent exister sous deux formes : la
description de paquet et le paquet binaire prêt à installer.</p>
<p>La description de paquet est un fichier texte compréhensible par un être
humain qui contient tout ce qui est nécessaire pour construire le paquet,
c'est-à -dire pour créer le paquet binaire. Les informations contenues dans la
description de paquet comprennent des métainformations (comme le nom du paquet
et une description de son objet), l'URL du source code et les instructions
nécessaires à la configuration, compilation et construction du paquet. La
description peut être accompagnée d'une rustine.</p>
-<p>Un paquet binaire est une archive qui contient effectivement les fichiers
qui constituent le paquet, c'est-à -dire les exécutables, les fichiers de
données, les catalogues de messages, les librairies, les fichiers include,
etc... Le paquet peut aussi contenir des métainformations pour le paquet
lui-même.
+<p>Un paquet binaire est une archive qui contient effectivement les fichiers
qui constituent le paquet, c'est-à -dire les exécutables, les fichiers de
données, les catalogues de messages, les bibliothèques, les fichiers include,
etc... Le paquet peut aussi contenir des métainformations pour le paquet
lui-même.
L'installation d'un paquet binaire consiste simplement à le dépaqueter,
puisqu'il est déjà dans un format prêt à l'emploi. Comme Fink construit les
paquets avec le gestionnaire de paquets dpkg, les paquets binaires ont le
format dpkg et ont une extension .deb.</p>
</section>
<section name="ident"><title>Identification d'un paquet</title>
@@ -125,7 +125,7 @@
</itemd></item>
<item><itemt>%c</itemt>
<itemd>
-<p>paramètres pour <em>c</em>onfigure : <code>--prefix=%p</code> plus tout
autre élément spécifié avec ConfigureParams</p>
+<p>paramètres pour <em>c</em>onfigure : <code>--prefix=%p</code> plus tout
autre élément spécifié avec ConfigureParams. Dans le cas d'un paquet qui
comporte le <code>Type: perl</code>, les drapeaux par défaut de construction
d'un paquet perl sont utilisés à la place de <code>--prefix=%p</code>.</p>
</itemd></item>
<item><itemt>%m</itemt>
<itemd>
@@ -165,7 +165,7 @@
<ul>
<li><code>GPL</code> - la licence générale publique GNU. Cette licence
requiert que le source soit accessible au même endroit que le binaire.</li>
<li><code>LGPL</code> - la licence publique GNU moins générale. Cette
licence requiert que le source soit accessible au même endroit que le
binaire.</li>
-<li><code>GPL/LGPL</code> - c'est un cas spécial pour les paquets dans
lesquels une partie est sous licence GPL (par exemple les exécutables) et une
autre partie est sous licence LGPL (par exemple les librairies).</li>
+<li><code>GPL/LGPL</code> - c'est un cas spécial pour les paquets dans
lesquels une partie est sous licence GPL (par exemple les exécutables) et une
autre partie est sous licence LGPL (par exemple les bibliothèques).</li>
<li><code>BSD</code> - pour les licences style BSD. Ceci inclue la licence BSD
dite "original", la licence BSD "modified" et la licence MIT. La licence Apache
compte aussi parmi les licences BSD. Avec ces licences, la distribution du code
source est optionnelle. </li>
<li><code>Artistic</code> - pour la licence "Artistic" et ses dérivées.</li>
<li><code>Artistic/GPL</code> - licence duale, combinée Artistic/GPL.</li>
@@ -188,17 +188,17 @@
<p>Fink est une distribution additionnelle qui est installée dans un
répertoire distinct du système de base. Il est essentiel qu'un paquet
n'installe aucun fichier en dehors du répertoire de Fink.</p>
<p>Il peut y avoir des exceptions quand on ne peut faire autrement, par
exemple avec XFree86. Dans ce cas, le paquet doit tester l'existence de
fichiers avant l'installation et refuser de s'installer si cela amène Ã
écraser des fichiers déjà existants. Le paquet doit s'assurer que tous les
fichiers qu'il aura installés en dehors du répertoire de Fink seront
supprimés lorsque le paquet lui-même sera éliminé, ou que ces fichiers ne
causeront aucun problème s'ils sont laissés sur place (c'est-à -dire qu'ils
devront tester l'existence des binaires avant de les appeler, etc...).</p>
</section>
-<section name="sharedlibs"><title>Librairies partagées</title>
-<p>Fink a de nouvelles règles en ce qui concerne les librairies partagées,
règles qui prennent effet à compter de février 2002. Cette partie de la
documentation donne des explications sur la version 4 de ces règles, qui
coïncide avec la publication de la distribution 0.5.0 de Fink. Nous
commencerons par un bref résumé, puis nous passerons à une revue de
détails.</p>
-<p>Tout paquet qui construit des librairies partagées et qui, soit (1) est
placé dans la branche stable, soit (2) est un nouveau paquet de Fink, doit
gérer ses librairies partagées conformément aux règles de Fink. Ceci
signifie :</p>
+<section name="sharedlibs"><title>Bibliothèques partagées</title>
+<p>Fink a de nouvelles règles en ce qui concerne les bibliothèques
partagées, règles qui prennent effet à compter de février 2002. Cette
partie de la documentation donne des explications sur la version 4 de ces
règles, qui coïncide avec la publication de la distribution 0.5.0 de Fink.
Nous commencerons par un bref résumé, puis nous passerons à une revue de
détails.</p>
+<p>Tout paquet qui construit des bibliothèques partagées et qui, soit (1)
est placé dans la branche stable, soit (2) est un nouveau paquet de Fink, doit
gérer ses bibliothèques partagées conformément aux règles de Fink. Ceci
signifie :</p>
<ul>
-<li>vérifier, à l'aide de <code>otool -L</code>, que le nom d'installation
de chaque librairie, ses numéros de versions de compatibilité et actuels sont
corrects</li>
-<li>mettre les librairies partagées dans un paquet séparé (exception faite
pour les liens de libfoo.dylib vers nom d'installation), et inclure le champ
<code>Shlibs</code> dans ce paquet</li>
+<li>vérifier, à l'aide de <code>otool -L</code>, que le nom d'installation
de chaque bibliothèque, ses numéros de versions de compatibilité et actuels
sont corrects</li>
+<li>mettre les bibliothèques partagées dans un paquet séparé (exception
faite pour les liens de libfoo.dylib vers nom d'installation), et inclure le
champ <code>Shlibs</code> dans ce paquet</li>
<li>mettre les headers et les liens finaux venant de libfoo.dylib dans un
paquet caractérisé par <code>BuildDependsOnly: True</code>, et prévoir
qu'aucun autre paquet ne dépendra de lui.</li>
</ul>
<p>Un mainteneur, qui a de bonnes raisons de s'écarter de ces règles et ne
scinde pas le paquet, devra expliquer pourquoi dans le champ DescPackaging.</p>
<p>Pour certains paquets, tout peut être fait avec un paquet principal et un
paquet -shlibs ; dans d'autres cas, vous aurez besoin d'un troisième paquet.
Le nouveau champ <code>SplitOff</code> facilite ce processus.</p>
-<p>Quand trois paquets sont nécessaires, il y a deux façons différentes de
les nommer, suivant que les librairies (option 1) ou les binaires (option 2)
sont les fonctionnalités les plus importantes du paquet.
+<p>Quand trois paquets sont nécessaires, il y a deux façons différentes de
les nommer, suivant que les bibliothèques (option 1) ou les binaires (option
2) sont les fonctionnalités les plus importantes du paquet.
Pour l'option 1, utilisez le schéma suivant :</p>
<itemtable labeld="Contenu" labelt="Paquet">
<item><itemt><code>foo-shlibs</code></itemt>
@@ -232,9 +232,9 @@
<p>Avec l'option 2, il est plus difficile de mettre à jour un paquet existant
: quand vous réalisez la mise à jour, vous devez ajouter <code>BuildDepends:
foo-dev</code> Ã chaque paquet qui a un champ <code>Depends: foo</code>. Autre
problème de mise à jour à garder à l'esprit : un paquet qui dépend
indirectement du vôtre (par l'intermédiaire d'un paquet tiers) peut
nécessiter qu'on lui ajoute <code>BuildDepends: foo</code> ou
<code>BuildDepends: foo-dev</code> pour assurer une mise à jour correcte.
C'est à vous de veiller à ce que que le champ <code>BuildDepends</code> soit
renseigné si nécessaire.</p>
<p><em>Règles détaillées</em></p>
<p>Nous allons désormais discuter de tout cela en détails, premièrement
nous aborderons les règles applicables aux logiciels nouvellement portés,
puis nous nous tournerons vers la question de la mise à jour de paquets
existant dans fink. Comme exemples des règles en action, voir les paquets
libpng, libjpeg et libtiff.</p>
-<p>Les logiciels portés sur Darwin doivent, autant que possible, construire
des librairies partagées. (Les mainteneurs de paquets sont libres de
construire des librairies statiques, si cela s'avère plus approprié pour
leurs paquets ; ils peuvent aussi soumettre des paquets contenant uniquement
des librairies statiques, s'ils le souhaitent). Quand on construit des
librairies partagées, <em>deux</em> paquets - nommés foo et foo-shlibs -,
étroitement liés, doivent être construits. Les librairies partagées vont
dans foo-shlibs, et les headers dans foo. Ces deux paquets peuvent être
réalisés avec un seul fichier .info, en utilisant le champ
<code>SplitOff</code>, comme indiqué ci-dessous. (En fait, il est souvent
nécessaire de construire plus de deux paquets à partir du source, et cela
peut être fait en utilisant <code>SplitOff2</code>, <code>SplitOff3</code>,
etc...)</p>
-<p>Chaque paquet logiciel pour lequel des librairies partagées peuvent être
construites doit avoir un <em>numéro de version majeure</em> N. Le numéro de
version majeure n'est censé changer que lorsqu'un changement irréversible se
produit dans l'API de la librairie. Fink utilise la convention de nommage
suivante : si le nom en amont du paquet est bar, alors les paquets fink sont
appelés barN et barN-shlibs. (Ceci n'est appliqué rigoureusement qu'à de
nouveaux paquets ou lorsque le numéro de version majeure change). Par exemple,
le numéro de version majeure pour le paquet pré-existant libpng était 2,
mais les versions récentes de la librairie ont pour numéro de version majeure
3. Il y a donc, maintenant, 4 paquets fink pour gérer ceci : libpng,
libpng-shlibs, libpng3, libpng3-shlibs. Seul libpng ou libpng3 peut être
installé à un moment donné, mais libpng-shlibs et libpng3-shlibs peuvent
être installés en même temps. (Notez que deux fichiers .info suffis
ent à construire ces quatre paquets).</p>
-<p>La librairie partagée elle-même et certains fichiers liés seront placés
dans le paquet barN-shlibs ; les fichiers "include" et un certain nombre
d'autres fichiers seront placés dans le paquet barN. Il ne peut y avoir de
recouvrement de fichiers entre ces deux paquets, et tout ce qui est placé dans
barN-shlibs doit avoir un nom chemin qui, d'une façon ou d'une autre,
contienne le numéro de version majeure N. Dans de nombreux cas, votre paquet
aura besoin de certains fichiers à l'exécution, fichiers qui sont
généralement installés dans <filename>%i/lib/bar/</filename> ou
<filename>%i/share/bar/</filename> ; vous devrez adapter les chemins
d'installation à <filename>%i/lib/bar/N/</filename> ou
<filename>%i/share/bar/N/</filename>.</p>
+<p>Les logiciels portés sur Darwin doivent, autant que possible, construire
des bibliothèques partagées. (Les mainteneurs de paquets sont libres de
construire des bibliothèques statiques, si cela s'avère plus approprié pour
leurs paquets ; ils peuvent aussi soumettre des paquets contenant uniquement
des bibliothèques statiques, s'ils le souhaitent). Quand on construit des
bibliothèques partagées, <em>deux</em> paquets - nommés foo et foo-shlibs -,
étroitement liés, doivent être construits. Les bibliothèques partagées
vont dans foo-shlibs, et les headers dans foo. Ces deux paquets peuvent être
réalisés avec un seul fichier .info, en utilisant le champ
<code>SplitOff</code>, comme indiqué ci-dessous. (En fait, il est souvent
nécessaire de construire plus de deux paquets à partir du source, et cela
peut être fait en utilisant <code>SplitOff2</code>, <code>SplitOff3</code>,
etc...)</p>
+<p>Chaque paquet logiciel pour lequel des bibliothèques partagées peuvent
être construites doit avoir un <em>numéro de version majeure</em> N. Le
numéro de version majeure n'est censé changer que lorsqu'un changement
irréversible se produit dans l'API de la bibliothèque. Fink utilise la
convention de nommage suivante : si le nom en amont du paquet est bar, alors
les paquets fink sont appelés barN et barN-shlibs. (Ceci n'est appliqué
rigoureusement qu'à de nouveaux paquets ou lorsque le numéro de version
majeure change). Par exemple, le numéro de version majeure pour le paquet
pré-existant libpng était 2, mais les versions récentes de la bibliothèque
ont pour numéro de version majeure 3. Il y a donc, maintenant, 4 paquets fink
pour gérer ceci : libpng, libpng-shlibs, libpng3, libpng3-shlibs. Seul libpng
ou libpng3 peut être installé à un moment donné, mais libpng-shlibs et
libpng3-shlibs peuvent être installés en même temps. (Notez que deux
fichiers
.info suffisent à construire ces quatre paquets).</p>
+<p>La bibliothèque partagée elle-même et certains fichiers liés seront
placés dans le paquet barN-shlibs ; les fichiers "include" et un certain
nombre d'autres fichiers seront placés dans le paquet barN. Il ne peut y avoir
de recouvrement de fichiers entre ces deux paquets, et tout ce qui est placé
dans barN-shlibs doit avoir un nom chemin qui, d'une façon ou d'une autre,
contienne le numéro de version majeure N. Dans de nombreux cas, votre paquet
aura besoin de certains fichiers à l'exécution, fichiers qui sont
généralement installés dans <filename>%i/lib/bar/</filename> ou
<filename>%i/share/bar/</filename> ; vous devrez adapter les chemins
d'installation à <filename>%i/lib/bar/N/</filename> ou
<filename>%i/share/bar/N/</filename>.</p>
<p>Tous les autres paquets dépendant de bar, version majeure N, devront
utiliser les dépendances :</p>
<codeblock>
Depends: barN-shlibs
@@ -245,8 +245,8 @@
BuildDependsOnly: True
</codeblock>
<p>dans la description du paquet barN.</p>
-<p>Si votre paquet inclut à la fois des librairies partagées et des
binaires, et si les binaires doivent être présents à l'exécution (et pas
seulement à la compilation), alors les binaires doivent être regroupés dans
un troisième paquet, qui peut être appelé barN-bin. Les autres paquets
peuvent dépendre de barN-bin comme de barN-shlibs.</p>
-<p>Lors de la construction de librairies partagées de version majeure N, il
est important que le "nom d'installation" soit
<filename>%p/lib/bar.N.dylib</filename>. (Vous pouvez trouver le nom
d'installation en exécutant <code>otool -L</code> sur votre librairie). Le
fichier librairie réel doit être installé sous le nom de :</p>
+<p>Si votre paquet inclut à la fois des bibliothèques partagées et des
binaires, et si les binaires doivent être présents à l'exécution (et pas
seulement à la compilation), alors les binaires doivent être regroupés dans
un troisième paquet, qui peut être appelé barN-bin. Les autres paquets
peuvent dépendre de barN-bin comme de barN-shlibs.</p>
+<p>Lors de la construction de bibliothèques partagées de version majeure N,
il est important que le "nom d'installation" soit
<filename>%p/lib/bar.N.dylib</filename>. (Vous pouvez trouver le nom
d'installation en exécutant <code>otool -L</code> sur votre bibliothèque). Le
fichier bibliothèque réel doit être installé sous le nom de :</p>
<codeblock>
%i/lib/bar.N.x.y.dylib
</codeblock>
@@ -255,11 +255,11 @@
%i/lib/bar.N.dylib -> %p/lib/bar.N.x.y.dylib
%i/lib/bar.dylib -> %p/lib/bar.N.x.y.dylib
</codeblock>
-<p>Si la librairie statique est aussi construite, elle doit être installée
sous le nom de :</p>
+<p>Si la bibliothèque statique est aussi construite, elle doit être
installée sous le nom de :</p>
<codeblock>
%i/lib/bar.a
</codeblock>
-<p>Si le paquet utilise libtool, ceci est généralement géré
automatiquement, mais, dans tous les cas, vous devez vérifier que tout s'est
passé correctement. Vous devez aussi vérifier que la version courante et la
version de compatibilité sont définies de façon appropriée à vos
librairies partagées. (On peut trouver les numéros de version avec la
commande <code>otool -L</code>).</p>
+<p>Si le paquet utilise libtool, ceci est généralement géré
automatiquement, mais, dans tous les cas, vous devez vérifier que tout s'est
passé correctement. Vous devez aussi vérifier que la version courante et la
version de compatibilité sont définies de façon appropriée à vos
bibliothèques partagées. (On peut trouver les numéros de version avec la
commande <code>otool -L</code>).</p>
<p>Les fichiers sont scindés entre les deux paquets comme suit :</p>
<ul>
<li> dans le paquet barN-shlibs :
@@ -300,7 +300,7 @@
<p>Durant l'exécution du champ <code>SplitOff</code>, les fichiers et les
répertoires spécifiés sont déplacés du répertoire d'installation %I du
paquet principal vers le répertoire d'installation %i du paquet splitoff. (Il
y a une convention similaire pour les noms : %N est le nom du paquet principal,
et %n est le nom du paquet actif). La commande <code>DocFiles</code> place
ensuite une copie de la documentation dans
<filename>%i/share/doc/barN-shlibs</filename>.</p>
<p>Notez que nous avons inclus la version courante exacte de barN-shlibs comme
dépendance du paquet principal barN (qui peut être abrégé en %N-shlibs (=
%v-%r) ). Ceci assure que les versions correspondent, et garantit aussi que
barN "hérite" automatiquement de toutes les dépendances de barN-shlibs.</p>
<p><em>Le champ BuildDependsOnly</em></p>
-<p>Lors de mises à jour de librairies, il est souvent nécessaire d'avoir
deux versions des headers pendant une période de transition. L'une d'entre
elles est utilisée pour compiler certaines choses, l'autre pour en compiler
d'autres. C'est pourquoi, les paquets contenant des headers doivent être
construits avec soin. Si foo-dev et bar-dev contiennent tous les deux des
headers qui se recouvrent, alors foo-dev doit déclarer :</p>
+<p>Lors de mises à jour de bibliothèques, il est souvent nécessaire d'avoir
deux versions des headers pendant une période de transition. L'une d'entre
elles est utilisée pour compiler certaines choses, l'autre pour en compiler
d'autres. C'est pourquoi, les paquets contenant des headers doivent être
construits avec soin. Si foo-dev et bar-dev contiennent tous les deux des
headers qui se recouvrent, alors foo-dev doit déclarer :</p>
<codeblock>
Conflicts: bar-dev
Replaces: bar-dev
@@ -317,18 +317,18 @@
</codeblock>
<p>et la raison pour laquelle cela est fait doit être mentionnée dans le
champ DescPackaging.</p>
<p>Le champ BuildDependsOnly ne doit être mentionné dans le fichier .info du
paquet que si ce paquet contient des headers installés dans /sw/include.</p>
-<p>Ã partir de la version 0.20.5 de fink, "fink validate" affichage un
message pour tout .deb qui contient des headers et au moins une dylib, et qui
ne donne pas la valeur "true" ou "false" au champ BuildDependsOnly. (Il est
possible que, dans les versions postérieures de fink, ce message soit étendu
aux cas des .deb contenant des headers et une librairie statique). </p>
+<p>Ã partir de la version 0.20.5 de fink, "fink validate" affichage un
message pour tout .deb qui contient des headers et au moins une dylib, et qui
ne donne pas la valeur "true" ou "false" au champ BuildDependsOnly. (Il est
possible que, dans les versions postérieures de fink, ce message soit étendu
aux cas des .deb contenant des headers et une bibliothèque statique). </p>
<p><em>Le champ Shlibs :</em></p>
-<p>En sus de placer les librairies partagées dans le bon paquet, suivant en
cela la version 4 de cette règle, vous devez également déclarer toutes les
librairies partagées en utilisant le champ <code>Shlibs</code>. Ce champ
contient une ligne distincte pour chaque librairie partagée ; la ligne
comprend le <code>nom d'installation</code> de la librairie, la <code>version
de compatibilité</code>, et des informations de dépendance qui indiquent le
paquet de Fink qui fournit cette librairie à cette version de compatibilité.
La dépendance doit être déclarée sous la forme <code> foo (>=
version-révision)</code> où <code>version-révision</code> correspond à la
<em>première</em> version du paquet de Fink qui fournit cette librairie (avec
cette version de compatibilité). Par exemple, une déclaration :</p>
+<p>En sus de placer les bibliothèques partagées dans le bon paquet, suivant
en cela la version 4 de cette règle, vous devez également déclarer toutes
les bibliothèques partagées en utilisant le champ <code>Shlibs</code>. Ce
champ contient une ligne distincte pour chaque bibliothèque partagée ; la
ligne comprend le <code>nom d'installation</code> de la bibliothèque, la
<code>version de compatibilité</code>, et des informations de dépendance qui
indiquent le paquet de Fink qui fournit cette bibliothèque à cette version de
compatibilité. La dépendance doit être déclarée sous la forme <code> foo
(>= version-révision)</code> où <code>version-révision</code> correspond Ã
la <em>première</em> version du paquet de Fink qui fournit cette bibliothèque
(avec cette version de compatibilité). Par exemple, une déclaration :</p>
<codeblock>
Shlibs: <<
%p/lib/bar.1.dylib 2.1.0 bar1 (>= 1.1-2)
<<
</codeblock>
-<p>indique qu'une librairie, dont le <code>nom d'installation</code> est
%p/lib/bar.1.dylib et <code>la version de compatibilité </code> est 2.1.0, a
été installée à partir de la version 1.1-2 du paquet <em>bar1</em>. De
plus, cette déclaration équivaut à la promesse du mainteneur qu'une
librairie avec ce nom et une version de compatibilité au moins égale à 2.10
sera toujours présente dans les versions ultérieures du paquet
<em>bar1</em>.</p>
-<p>Notez l'utilisation de %p dans le nom de la librairie, ce qui permet Ã
tous les utilisateurs de Fink de trouver le bon <code>nom
d'installation</code>, quel que soit le préfixe qu'ils ont choisi.</p>
+<p>indique qu'une bibliothèque, dont le <code>nom d'installation</code> est
%p/lib/bar.1.dylib et <code>la version de compatibilité </code> est 2.1.0, a
été installée à partir de la version 1.1-2 du paquet <em>bar1</em>. De
plus, cette déclaration équivaut à la promesse du mainteneur qu'une
bibliothèque avec ce nom et une version de compatibilité au moins égale Ã
2.10 sera toujours présente dans les versions ultérieures du paquet
<em>bar1</em>.</p>
+<p>Notez l'utilisation de %p dans le nom de la bibliothèque, ce qui permet Ã
tous les utilisateurs de Fink de trouver le bon <code>nom
d'installation</code>, quel que soit le préfixe qu'ils ont choisi.</p>
<p>Quand un paquet est mis à jour, on copie tout simplement le champ
<code>Shlibs</code> dans la nouvelle version/révision du paquet. L'exception
à cette règle survient quand la <code>version de compatibilité</code> est
incrémentée : dans ce cas, le numéro de version
-dans les informations de dépendance doit être changé pour la
version/révision courante (celle qui est la première à fournir la librairie
avec le nouveau numéro de version de compatibilité).</p>
+dans les informations de dépendance doit être changé pour la
version/révision courante (celle qui est la première à fournir la
bibliothèque avec le nouveau numéro de version de compatibilité).</p>
<p><em>Mesures à prendre quand le numéro de version majeure change :</em></p>
<p>Si le numéro de version majeure change de N à M, vous devez créer deux
nouveaux paquets barM et barM-shlibs. Le paquet barM-shlibs ne peut recouvrir
le paquet barN-shlibs, puisque de nombreux utilisateurs installeront les deux
simultanément. Dans le paquet barM, vous devez utiliser les dépendances :</p>
<codeblock>
@@ -340,17 +340,17 @@
Conflicts: barM
Replaces: barM
</codeblock>
-<p>Les utilisateurs verront alors barN et barM apparaître et disparaître au
gré de la construction de divers paquets dépendant de l'une ou l'autre
version de la librairie partagée, tandis que barN-shlibs et barM-shlibs
resteront installés de façon permanente.</p>
+<p>Les utilisateurs verront alors barN et barM apparaître et disparaître au
gré de la construction de divers paquets dépendant de l'une ou l'autre
version de la bibliothèque partagée, tandis que barN-shlibs et barM-shlibs
resteront installés de façon permanente.</p>
<p><em>Mise à jour d'un paquet de fink existant :</em></p>
-<p>Le meilleur moyen de mettre à jour un paquet fink existant qui installe
des librairies, qu'elles soient statiques ou partagées, est de créer une
nouvelle version foo du paquet, accompagné d'un nouveau paquet foo-shlibs, qui
satisfait aux règles ci-dessus. Si des librairies partagées (ou d'autres
fichiers présents maintenant dans foo-shlibs) étaient installées auparavant,
ces nouveaux paquets doivent stipuler :</p>
+<p>Le meilleur moyen de mettre à jour un paquet fink existant qui installe
des bibliothèques, qu'elles soient statiques ou partagées, est de créer une
nouvelle version foo du paquet, accompagné d'un nouveau paquet foo-shlibs, qui
satisfait aux règles ci-dessus. Si des bibliothèques partagées (ou d'autres
fichiers présents maintenant dans foo-shlibs) étaient installées auparavant,
ces nouveaux paquets doivent stipuler :</p>
<codeblock>
Replaces: foo (<< version.decompatibilité.laplusancienne)
</codeblock>
<p>de façon que la mise à jour soit transparente pour les utilisateurs.
(Vous <em>ne</em> devez <em>pas</em> utiliser "Conflicts: foo", car cela
empêche la mise à jour).</p>
-<p>Après mise à jour, les paquets qui stipulent "Depends: foo" continueront
à fonctionner normalement. Toutefois, vous devez contacter les mainteneurs de
tous ces paquets fink et les presser de modifier leurs paquets pour qu'ils
stipulent, dès que possible, "Depends: foo-shlibs, BuildDepends: foo". Vous ne
pourrez pas créer de nouveaux paquets fooM, fooM-shlibs qui implémentent une
version majeure de la librairie partagée tant qu'ils ne l'auront pas fait.</p>
+<p>Après mise à jour, les paquets qui stipulent "Depends: foo" continueront
à fonctionner normalement. Toutefois, vous devez contacter les mainteneurs de
tous ces paquets fink et les presser de modifier leurs paquets pour qu'ils
stipulent, dès que possible, "Depends: foo-shlibs, BuildDepends: foo". Vous ne
pourrez pas créer de nouveaux paquets fooM, fooM-shlibs qui implémentent une
version majeure de la bibliothèque partagée tant qu'ils ne l'auront pas
fait.</p>
<p>Les paquets fink existants qui n'ont pas utilisé le bon nom d'installation
ou qui n'ont pas utilisé un nom correct ou des liens symboliques pour les
libraires partagées doivent être mis à jour soigneusement, au cas par cas.
Si vous êtes embarrassé pour choisir une stratégie de mise à jour rendant
vos paquets compatibles avec les nouvelles règles, parlez-en sur la liste de
diffusion fink-devel.</p>
-<p><em>Paquets contenant des fichiers binaires et des librairies :</em></p>
-<p>Quand un paquet en amont contient tout à la fois des fichiers binaires et
des librairies, la construction des paquets fink doit être menée avec soin.
Dans certains cas, les seuls fichiers binaires seront des fichiers du genre
<code>foo-config</code>, qui sont censés n'être utilisés qu'à la
compilation, et jamais à l'exécution. Dans ces cas, les binaires peuvent
aller avec les headers dans le paquet <code>foo</code>.</p>
+<p><em>Paquets contenant des fichiers binaires et des bibliothèques :</em></p>
+<p>Quand un paquet en amont contient tout à la fois des fichiers binaires et
des bibliothèques, la construction des paquets fink doit être menée avec
soin. Dans certains cas, les seuls fichiers binaires seront des fichiers du
genre <code>foo-config</code>, qui sont censés n'être utilisés qu'à la
compilation, et jamais à l'exécution. Dans ces cas, les binaires peuvent
aller avec les headers dans le paquet <code>foo</code>.</p>
<p>Dans d'autres cas, les fichiers binaires seront nécessaires à d'autres
paquets pendant l'exécution, et devront être regroupés dans un paquet fink
séparé avec un nom du type <code>foo-bin</code>. Le paquet
<code>foo-bin</code> doit dépendre du paquet <code>foo-shlibs</code>, et les
mainteneurs d'autres paquets doivent être encouragés à utiliser :</p>
<codeblock>
Depends: foo-bin
@@ -450,9 +450,14 @@
</itemd></item>
<item><itemt><filename>/sw/lib</filename></itemt>
<itemd>
-<p>Ce répertoire est destiné aux fichiers de données et librairies
dépendants de l'architecture du système. Les librairies statiques et
partagées doivent être placées dans <filename>/sw/lib</filename>, 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).</p>
+<p>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 <filename>/sw/lib</filename>, 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).</p>
<p>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,
<filename>/sw/lib/perl5</filename> ou <filename>/sw/lib/apache/1.3</filename>.
Faites attention si vous utilisez le type d'hôte dans le nom des répertoires
créés. Un sous-répertoire nommé <code>powerpc-apple-darwin1.3.3</code> ne
garantit pas la compatibilité entre versions ; utilisez plutôt
<code>powerpc-apple-darwin1.3</code> ou <code>powerpc-apple-darwin</code>.</p>
</itemd></item>
+<item><itemt><filename>/sw/lib/ppc64</filename>
+<filename>/sw/lib/x86_64</filename></itemt>
+<itemd>
+<p>Ce répertoire est dédié aux bibliothèques 64-bit. Le répertoire
<filename>/sw/lib/ppc64</filename> est utilisé sous architecture powerpc et le
répertoire <filename>/sw/lib/x86_64</filename> sous architecture i386. Les
bibliothèques combinées (fat) doivent être enregistrées dans le répertoire
<filename>/sw/lib</filename>.</p>
+</itemd></item>
<item><itemt><filename>/sw/share</filename></itemt>
<itemd>
<p>Ce répertoire sert aux fichiers de données indépendants de
l'architecture. Les mêmes règles que celles en vigueur pour
<filename>/sw/lib</filename> s'appliquent ici. Quelques sous-répertoires
courants sont décrits ci-dessous.</p>
@@ -505,7 +510,7 @@
<p>à partir de la distribution 10.4-transitional, une nouvelle méthode a
été introduite pour assurer la sélection du bon compilateur g++. Durant la
compilation, un répertoire
<filename>/sw/var/lib/fink/path-prefix-g++-XXX</filename> (où XXX est le
numéro de version) est ajouté au PATH. Ce répertoire contient des scripts
shell qui se charge de sélectionner la bonne version de g++.</p>
</section>
<section name="abi"><title>L'ABI g++</title>
-<p>L'ABI g++ a changé trois fois depuis la naissance de Mac OS X : elle est
différente pour les versions 2.95, 3.1, 3.3 et 4.0. Ces différentes ABI ne
sont pas compatibles entre elles, et toute librairie utilisant du code C++ et
liée à un projet doit être compilée avec la même ABI que celle en cours
d'utilisation.</p>
+<p>L'ABI g++ a changé trois fois depuis la naissance de Mac OS X : elle est
différente pour les versions 2.95, 3.1, 3.3 et 4.0. Ces différentes ABI ne
sont pas compatibles entre elles, et toute bibliothèque utilisant du code C++
et liée à un projet doit être compilée avec la même ABI que celle en cours
d'utilisation.</p>
<p>Fink garde trace de l'ABI g++ à l'aide du champ GCC. Ce champ doit être
défini par tout paquet qui invoque les compilateurs g++ ou c++. Il NE doit PAS
être défini pour les paquets qui n'invoquent pas ces compilateurs. Quand un
changement d'ABI intervient, il faut vérifier le champ GCC de toutes les
dépendances d'un paquet. Quand toutes les dépendances ont été mises Ã
jour, le paquet lui-même peut être mis à jour. Les versions des dépendances
doivent être modifiées pour assurer que les utilisateurs aient bien toutes
les dépendances correctes mises à jour avant de tenter de compiler la
nouvelle version d'un paquet.</p>
<p>Si un petit nombre de paquets dépendent uniquement les uns des autres, on
peut laisser la version de l'ABI précédente en place, s'ils ne sont pas
prêts pour la mise à jour. Quand la mise à jour aura lieu, ils seront tous
mis à jour en même temps avec une version correcte sur tous les paquets.
C'est pourquoi il est préférable de ne mettre à jour les paquets qu'au
moment de la distribution.</p>
<p>Fink utilise le champ GCC pour s'assurer que les utilisateurs ont bien la
bonne version du compilateur g++ installée sur leur système. Si le champ GCC
est défini par le paquet, fink vérifie que la commande
<code>gcc_select</code> a reçu la valeur en cours. Cette valeur est 3.3 pour
les versions 10.2 et 10.3 de Mac OS X, et 4.0 pour la version 10.4 de Mac OS X.
La commande <code>gcc_select</code> n'était pas disponible antérieurement Ã
la version 10.2 de Mac OS X.</p>
@@ -650,13 +655,13 @@
Depends: (%type_pkg[-x11]) x11
</codeblock>
<p>indiquera une dépendance du paquet x11 pour la variante nethack-x11, mais
pas pour la variante nethack.</p>
-<p>Notez que quand on utilise les champs Depends/BuildDepends pour les paquets
de librairies partagées, alors qu'il existe plus d'une version majeure
disponible, il <em>ne faut pas</em> utiliser la syntaxe suivante :</p>
+<p>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 <em>ne faut pas</em> utiliser la syntaxe suivante :</p>
<codeblock>
Package: foo
Depends: id3lib3.7-shlibs | id3lib3.7-shlibs
BuildDepends: id3lib3.7-dev | id3lib4-dev
</codeblock>
-<p>même si le paquet peut fonctionner avec l'une ou l'autre librairie. 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.</p>
+<p>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.</p>
<p>Comme cela a été expliqué dans la section <xref chapter="policy"
section="sharedlibs">Librairies partagées</xref>, 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 <code>Depends</code> que l'un quelconque des paquets est
requis.</p>
<p>Auparavant, les paquets non essentiels dépendaient implicitement des
paquets essentiels ; ce n'est plus vrai.</p>
</itemd></item>
@@ -676,7 +681,7 @@
</itemd></item>
<item><itemt>BuildConflicts</itemt>
<itemd>
-<p>Liste de paquets qui ne doivent pas être installés lorsque le paquet est
compilé. Ce champ peut être utilisé pour empêcher <code>./configure</code>
ou le compilateur de détecter des headers de librairies 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
<code>TestConflicts</code> sont ajoutés à cette liste.</p>
+<p>Liste de paquets qui ne doivent pas être installés lorsque le paquet est
compilé. Ce champ peut être utilisé pour empêcher <code>./configure</code>
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
<code>TestConflicts</code> sont ajoutés à cette liste.</p>
</itemd></item>
<item><itemt>Replaces</itemt>
<itemd>
@@ -830,7 +835,8 @@
</itemd></item>
<item><itemt>ConfigureParams</itemt>
<itemd>
-<p>Paramètres supplémentaires à passer au script configure. (Voir
CompileScript pour de plus amples informations). Si les séries de tests sont
activées, la valeur du champ <code>TestConfigureParams</code> est ajoutée Ã
ces paramètres. à partir des versions de fink > 0.13.7, ce champ fonctionne
aussi avec les modules perl <code>Type: Perl</code> ; il ajoute les paramètres
à la chaîne perl par défaut Makefile.PL.</p>
+<p>Paramètres supplémentaires à passer au script configure. (Voir
CompileScript pour de plus amples informations). Pour les paquets qui ne sont
pas de <code>Type: Perl</code>, le paramètre <code>--prefix=%p</code> est
ajouté avant la valeur de ce champ. à partir des versions de fink > 0.13.7,
ce champ fonctionne aussi avec les modules perl <code>Type: Perl</code> ; il
ajoute les paramètres à la chaîne perl par défaut Makefile.PL.</p>
+<p>Si les séries de tests sont activées, la valeur du champ
<code>TestConfigureParams</code> est ajoutée à ces paramètres.</p>
<p>à 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
<code>Depends</code> 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 :</p>
<codeblock>
Type: -x11 (boolean)
@@ -841,12 +847,12 @@
</itemd></item>
<item><itemt>GCC</itemt>
<itemd>
-<p>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 librairie
liée à du code C++ doit être compilée avec l'ABI résidant sur le système
au moment de son utilisation).</p>
+<p>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).</p>
<p>Les valeurs autorisées sont les suivantes : <code>2.95.2</code> (ou
<code>2.95</code>), <code>3.1</code>, <code>3.3</code> et <code>4.0</code>.
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.</p>
<p>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 : <code>2.95</code> pour l'arborescence 10.1,
<code>3.1</code> pour l'arborescence 10.2, <code>3.3</code> pour les
arborescences 10.2-gcc3.3, 10.3 et 10.4-transitional, et <code>4.0</code> pour
l'arborescence 10.4 Ã venir.</p>
<p>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.</p>
<p>à partir de la version 0.13.8 de fink, quand ce champ est utilisé, la
version de gcc est testée via <code>gcc_select</code>, et fink se termine avec
un message d'erreur si la version requise n'est pas présente.</p>
-<p>Ce champ a été ajouté pour faciliter la transition entre les
compilateurs gcc, qui ont introduit une incompatibilité binaire entre
librairies ; cette incompatibilité concerne des parties de code C++ non
reproduites dans les différentes versions.</p>
+<p>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.</p>
</itemd></item>
<item><itemt>CompileScript</itemt>
<itemd>
@@ -965,7 +971,7 @@
</itemd></item>
<item><itemt>Shlibs</itemt>
<itemd>
-<p><em>Introduit dans la version 0.11.0 de fink.</em> Ce champ déclare les
librairies partagées installées dans le paquet. Il y a une ligne par
librairie partagée, cette ligne est constituée de trois éléments séparés
par des blancs : le nom d'installation de la librairie
<code>-install_name</code>, le numéro de version de compatibilité de la
librairie <code>-compatibility_version</code> et des informations de
dépendance de version qui indiquent quel paquet de Fink fournit la librairie
à cette version de compatibilité. Les informations de dépendance doivent
être spécifiées sous la forme <code> foo (>= version-revision)</code>, où
<code>version-revision</code> représente la <em>première</em> version d'un
paquet Fink qui rend disponible cette librairie (avec cette version de
compatibilité). La déclaration Shlibs revient à dire que le mainteneur du
paquet garantit qu'une librairie portant ce nom et ayant une version de
compatibilité au moins égale à <c
ode>-compatibility_version</code> sera présente dans toutes les versions
postérieures de ce paquet Fink.</p>
+<p><em>Introduit dans la version 0.11.0 de fink.</em> Ce champ déclare les
bibliothèques partagées installées dans le paquet. Il y a une ligne par
bibliothèque partagée, cette ligne est constituée de trois éléments
séparés par des blancs : le nom d'installation de la bibliothèque
<code>-install_name</code>, le numéro de version de compatibilité de la
bibliothèque <code>-compatibility_version</code> et des informations de
dépendance de version qui indiquent quel paquet de Fink fournit la
bibliothèque à cette version de compatibilité. Les informations de
dépendance doivent être spécifiées sous la forme <code> foo (>=
version-revision)</code>, où <code>version-revision</code> représente la
<em>première</em> 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 compatib
ilité au moins égale à <code>-compatibility_version</code> sera présente
dans toutes les versions postérieures de ce paquet Fink.</p>
</itemd></item>
<item><itemt>RuntimeVars</itemt>
<itemd>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Fink-commits mailing list
Fink-commits@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-commits
