Attachment 122429 Details for Bug 182495 – The french translation of automagic.xml

[patch] The french translation of automagic.xml

automagic-fr.xml (text/plain), 11.45 KB, created by Nicolas Litchinko on 2007-06-18 18:29:19 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Nicolas Litchinko

Created: 2007-06-18 18:29:19 UTC

Size: 11.45 KB

patch

obsolete

><?xml version="1.0" encoding="UTF-8"?>
><!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd">
>
>
><guide link="/proj/en/qa/automagic.xml" lang="en">
><title>Les dÃ©pendances automagiques, ce qu'elles sont et comment les corriger</title>
>
><author title="Author">
> <mail link="flameeyes@gentoo.org">Diego PettenÃ²</mail>
></author>
><author title="Translator">
> <mail link="nicolas@litchinko.fr">Nicolas Litchinko</mail>
></author>
>
><abstract>
>Ce guide a pour objectif de dÃ©crire le problÃ¨me des Â«dÃ©pendances automagiquesÂ»,
>la raison pour laquelle elles posent problÃ¨me et comment les gÃ©rer dans les cas
>les plus courants.
></abstract>
>
>
>
><license/>
>
><version>0.1</version>
><date>2006-01-30</date>
>
><chapter> 
><title>Introduction</title>
>
><section>
><title>Qu'est-ce que les dÃ©pendances automagiques&nbsp;?</title>
><body>
>
>
>Les fameuses <e>dÃ©pendances automagiques</e> sont des dÃ©pendances lÃ©gÃ¨res d'un
>logiciel qui ne sont reconnues qu'au moment de la compilation ou de l'exÃ©cution
>et qui influent sur le fonctionnement du logiciel. Le nom <e>automagique</e>
>est un jeu de mot en rÃ©fÃ©rence aux GNU autotools qui produisent le plus souvent
>des <e>dÃ©pendances automagiques</e>.
>
>
>
>Les logiciels ont en gÃ©nÃ©ral deux catÃ©gories de dÃ©pendances&nbsp;: les
>dÃ©pendances indispensables et les dÃ©pendances optionnelles. La premiÃ¨re
>catÃ©gorie de dÃ©pendance est requise pour l'utilisation du logiciel (cela peut
>Ãªtre une bibliothÃ¨que ou une application) et elles ne peuvent manquer Ã  l'appel
>lors de la compilation ou l'exÃ©cution du logiciel (selon leur type: dÃ©pendances
>de compilation ou d'exÃ©cution). Les dÃ©pendances optionnelles sont celles qui
>peuvent Ãªtre dÃ©sactivÃ©es, en gÃ©nÃ©ral lors de la compilation (mais parfois aussi
>lors de l'exÃ©cution).
>
>
>
>Il revient souvent Ã  l'utilisateur (ou Ã  celui qui compile le logiciel)
>d'activer ou dÃ©sactiver les dÃ©pendances optionnelles. L'exemple classique de ce
>cas sont les options <c>--enable-foo</c> ou <c>--with-bar</c> du script
><c>./configure</c> (ces paramÃ¨tres sont utilisÃ©s pour activer des dÃ©pendances
>qui sont dÃ©sactivÃ©es par dÃ©faut, mais il y a Ã©galement des cas pour lesquelles
>les dÃ©pendances sont activÃ©es par dÃ©fault et il faut utiliser
><c>--disable-foo</c> ou <c>--without-bar</c>)
>
>
>
>Cependant, avec des systÃ¨mes de compilation qui essaient de comprendre ce qui
>est prÃ©sent sur le systÃ¨me qui sert Ã  la compilation, il arrive que des
>dÃ©pendances deviennent <e>automagiques</e>. Cela signifie que le systÃ¨me de
>compilation ne demande pas Ã  l'utilisateur s'il souhaite activer une option,
>et donc ajouter une dÃ©pendance, mais que la dÃ©pendance est activÃ©e si elle est
>dÃ©tectÃ©e. Ce comportement est mauvais.
>
>
></body>
></section>
>
><section> 
><title>Pourquoi les dÃ©pendances automagiques sont mauvaises</title>
>
><body>
>
>
>Dans le cas de distributions basÃ©es sur des binaires, comme celles basÃ©es sur
>RPM ou DEB, les dÃ©pendances automagiques ne changent rien&nbsp;: si
>l'utilisateur a quelque chose d'installÃ© et compile Ã  la main, c'est souvent ce
>qu'il veut activer l'option et s'il s'agit du mainteneur, il n'aura qu'Ã 
>ajouter une dÃ©pendance sur les paquets requis pour exÃ©cuter les binaires qu'il
>a crÃ©Ã©.
>
>
>
>Cela est diffÃ©rent pour les distributions basÃ©es sur les sources comme Gentoo
>Linux (et dÃ©rivÃ©s). Comme les distributions basÃ©es sur les sources ne sÃ©parent
>pas les paquets utilisateur et les paquets de dÃ©veloppement, les systÃ¨mes de
>construction peuvent trouver plus que ce que l'utilisateur voudrait et vont
>essayer de se lier avec tout ce qu'ils connaissent. C'est la principale cause
>de cassure de liaison avec un depclean (NdT. nettoyage des dÃ©pendances non
>utilisÃ©es).
>
>
>
>Pour simplifier, lorsqu'une dÃ©pendance automagique n'est pas indiquÃ©e comme
>indispensable dans un ebuild mais qu'au lieu de cela il existe un mÃ©canisme qui
>ajoute ou supprime la dÃ©pendance Ã  un paquet donnÃ©, si le paquet est prÃ©sent
>dans le systÃ¨me compilant le logiciel avec des dÃ©pendance automagiques et est
>ensuite supprimÃ©, le logiciel cessera de fonctionner, nÃ©cessitant alors une
>exÃ©cution de <c>revdep-rebuild</c> pour corriger la liaison. Il est Ã©galement
>possible qu'un utilisateur souhaite rÃ©ellement dÃ©sactiver une dÃ©pendance
>parce-qu'il sait qu'elle n'est pas stable ou parce qu'il crÃ©e un paquet binaire
>pour une autre machine sur laquelle la dÃ©pendance n'est peut-Ãªtre pas installÃ©e
>(ou ne fonctionne mÃªme peut-Ãªtre pas du tout).
>
>
>
>Lorsqu'un paquet a des dÃ©pendances automatiques il n'y a que deux choses qui
>peuvent Ãªtre faites&nbsp;: la premiÃ¨re est de dÃ©clarer la dÃ©pendance
>indispensable, sans considÃ©rer les choix fait par l'utilisateur dans la
>variable USE, mais cela peut signifier que le support de certaines
>fonctionnalitÃ©s que certains utilisateurs ne souhaitent pas activer sera
>toujours prÃ©sent et les dÃ©pendances seront toujours installÃ©es&nbsp;; l'autre
>solution est de corriger le systÃ¨me de compilation pour Ãªtre capable de
>dÃ©sactiver la dÃ©pendance lors de la compilation mÃªme si elle est prÃ©sente sur
>le systÃ¨me.
>
>
>
>La plupart du temps, les dÃ©veloppeurs upstream (NdT. les dÃ©veloppeurs du
>logiciel) ne pensent pas vraiment Ã  ajouter la possibilitÃ© de dÃ©sactiver les
>dÃ©pendances automagiques puisqu'ils ne le ressentent pas comme un vÃ©ritable
>problÃ¨me&nbsp;: ils les ont toutes d'installÃ©es, ou au moins celles dont ils
>ont besoin, et ils compilent en gÃ©nÃ©ral avec toutes les options d'activÃ©es.
>Heureusement, la plupart des dÃ©veloppeurs upstream acceptent d'ajouter des
>options pour dÃ©sactiver ces dÃ©pendances si des correctifs sont fournis (parfois
>Ã©galement sans correctifs, mais bien Ã©videmment la demande sera mieux reÃ§ue si
>des correctifs sont dÃ©jÃ  prÃªts). Ce n'est toutefois pas toujours le cas. Par
>exemple, les dÃ©veloppeurs de Wine ne veulent pas ajouter la possibilitÃ©
>d'activer ou de dÃ©sactiver des fonctionnalitÃ©s lors de l'appel Ã 
><c>./configure</c> car ils dÃ©sirent que leur logiciel utilise toujours le plus
>d'options possible.
>
>
></body>
>
></section>
>
></chapter>
>
><chapter> 
><title>Corriger les dÃ©pendances automagiques</title>
>
><section> 
><title>Autotools</title>
>
><body>
>
>
>La majoritÃ© des dÃ©pendances automagiques, comme leur nom l'indique, sont due Ã 
>un (mauvais) usage des GNU autotools (<c>autoconf</c> pour Ãªtre exact). Il y a
>deux cas principaux dans lesquels des dÃ©pendances automagiques
>apparaissent&nbsp;: le premier est le cas des Â«dÃ©veloppeurs paresseuxÂ» dans
>lequel les dÃ©pendances n'ont pas du tout de paramÃ¨tre pour <c>./configure</c>
>et sont seulement vÃ©rifiÃ©es Ã  l'aide de AC_CHECK_LIB ou la macro
>PKG_CHECK_MODULE de <c>pkg-config</c> qui permettent l'exÃ©cution de code
>spÃ©cifique lorsqu'une bibliothÃ¨que (ou un paquet) sont prÃ©sent ou non&nbsp;;
>l'autre cas est celui du Â«paramÃ¨tre malicieuxÂ» dans lequel le paramÃ¨tre
><c>--disable-foo</c> ou <c>--without-bar</c> est acceptÃ© par <c>./configure</c>
>mais n'est pas correctement interprÃ©tÃ©.
>
>
>
>Le premier cas est facile Ã  corriger, il n'y a qu'Ã  ajouter un appel Ã 
>AC_ARG_WITH (ou AC_ARG_ENABLE) et ensuite vÃ©rifier la valeur de
>la variable correspondante avant de faire le test. Il est utile de savoir que
>le premier paramÃ¨tre passÃ© Ã  cette macro crÃ©e une variable qui est chargÃ©e par
><c>autoconf</c> sans avoir Ã  ajouter les autres paramÃ¨tres qui dÃ©terminent
>l'action Ã  effectuer lorsque le paramÃ¨tre est prÃ©sent et lorsqu'il ne l'est
>pas. Cette variable est appelÃ©e <path>$enable_foo</path> ou
><path>$with_bar</path> en fonction de la macro utilisÃ©e.
>
>
><note>
>Pour que les correctifs soient acceptÃ©s par les dÃ©veloppeurs upstream, il est
>en gÃ©nÃ©ral suggÃ©rÃ© de ne pas changer le comportement de <c>./configure</c>
>lorsqu'il est appelÃ© sans paramÃ¨tres&nbsp;; c'est pourquoi nous allons vous
>prÃ©senter deux mÃ©thodes pour rendre les dÃ©pendances non-automagiques, une pour
>les dÃ©pendances activÃ©es par dÃ©faut et une autre pour les dÃ©pendances
>dÃ©sactivÃ©es par dÃ©faut.
></note>
>
><pre caption="Ajouter une dÃ©pendance optionnelle activÃ©e par dÃ©faut">
>AC_ARG_WITH([foo], AS_HELP_STRING([--without-foo], [Build without foo library (default: test)]))
>
>if test "x$with_foo" != "xno"; then
> PKG_CHECK_MODULES([FOO], [foo >= 0.1])
>fi
></pre>
>
><pre caption="Ajouter une dÃ©pendance optionnelle dÃ©sactiver par dÃ©faut">
>AC_ARG_WITH([foo], AS_HELP_STRING([--with-foo], [Build with foo library (default: disabled)]))
>
>if test "x$with_foo" == "xyes"; then
> PKG_CHECK_MODULES([FOO], [foo >= 0.1])
>fi
></pre>
>
>
>Lorsque le paramÃ¨tre est prÃ©sent mais n'est pas honorÃ©, corriger le problÃ¨me de
>dÃ©pendance peut aussi bien Ãªtre simple que complexe. Il peut s'agir d'un test
>qui n'est pas correctement Ã©crit, et dans ce cas il faut le modifier en quelque
>chose qui ressemble aux tests prÃ©sentÃ©s prÃ©cÃ©demment, ou il peut s'agir d'un
>mÃ©lange complet des appels aux macros AC_ARG_WITH. Dans ces cas, il vaut
>mieux vÃ©rifier le code avec prÃ©caution et contacter les dÃ©veloppeurs upstream
>s'il s'agit d'une erreur complexe.
>
>
><warn>
>Souvent (presque tout le temps lorsque le paquet utilise automake), les
>dÃ©pendances automagiques sont associÃ©es avec des appels Ã 
>AM_CONDITIONAL. Il est trÃ¨s important que ces appels soient placÃ©s
><e>hors</e> des blocs if/fi, ou alors les appels Ã  <c>./configure</c> vont
>exploser.
></warn>
>
>
>Il y a en rÃ©alitÃ© une autre mÃ©thode pour contourner le problÃ¨me, sans corriger
>(et patcher), les dÃ©pendances automagiques gÃ©nÃ©rÃ©es par AC_CHECK_LIB et
>c'est en jouant avec les valeurs mises en cache par <c>autoconf</c>. Cette
>mÃ©thode est en fait dÃ©prÃ©ciÃ©e parce-qu'elle ne rÃ¨gle pas la cause du problÃ¨me
>et peut en crÃ©er d'autres si les dÃ©veloppeurs upstream modifient lÃ©gÃ¨rement les
>tests en utilisant un autre nom pour la variable mise en cache. De plus, de
>cette faÃ§on, les correctifs ne peuvent Ãªtre envoyÃ©s aux dÃ©veloppeurs upstream
>pour Ãªtre intÃ©grÃ©s dans les prochaines versions.
>
>
></body>
></section>
>
><section> 
><title>Les autres systÃ¨mes de compilation</title>
>
><body>
>
><impo>
>Veuillez contribuer Ã  ce guide ;) Des notes a propos d'autres systÃ¨mes de
>construction non-personnalisÃ©s comme <c>scons</c> sont les bienvenues. Si le
>systÃ¨me de construction peut dÃ©finir des dÃ©pendances automagiques, il devrait
>Ã©galement y avoir un moyen de les corriger.
></impo>
>
>
>Les dÃ©pendances automagiques peuvent Ã©galement Ãªtre crÃ©Ã©es par des systÃ¨mes de
>construction utilisÃ©s par certains logiciels. Malheureusement, du fait de leur
>personnalisation, ces systÃ¨mes de construction sont en gÃ©nÃ©ral difficile Ã 
>optimiser et il n'est pas possible de dÃ©finir une mÃ©thode d'approche gÃ©nÃ©rale
>pour les corriger.
>
>
></body>
></section>
>
></chapter>
>
></guide>
>
>

Actions: View | Diff

Attachments on bug 182495: 122429 | 122528 | 122530