diff options
Diffstat (limited to 'doc/contributing.fr.texi')
| -rw-r--r-- | doc/contributing.fr.texi | 539 |
1 files changed, 510 insertions, 29 deletions
diff --git a/doc/contributing.fr.texi b/doc/contributing.fr.texi index 502de9f7f0..8900c7c704 100644 --- a/doc/contributing.fr.texi +++ b/doc/contributing.fr.texi @@ -25,6 +25,7 @@ quel nom ou pseudonyme de leur choix. * Construire depuis Git:: toujours le plus récent. * Lancer Guix avant qu'il ne soit installé:: Astuces pour les hackers. * La configuration parfaite:: Les bons outils. +* Consignes d'empaquetage:: Faire grandir la distribution. * Style de code:: Hygiène du contributeur. * Envoyer des correctifs:: Partager votre travail. @end menu @@ -99,7 +100,7 @@ valeur @code{localstatedir} utilisée par votre installation actuelle Finalement, vous devez invoquer @code{make check} pour lancer les tests (@pxref{Lancer la suite de tests}). Si quelque chose échoue, jetez un œil aux instructions d'installation (@pxref{Installation}) ou envoyez un message -à la list @email{guix-devel@@gnu.org}. +à la liste @email{guix-devel@@gnu.org}. @node Lancer Guix avant qu'il ne soit installé @@ -169,12 +170,15 @@ arborescence des source locale. @node La configuration parfaite @section La configuration parfaite -La configuration parfaite pour travailler sur Guix est simplement la -configuration parfaite pour travailler en Guile (@pxref{Using Guile in -Emacs,,, guile, Guile Reference Manual}). Tout d'abord, vous avez besoin de -mieux qu'un éditeur de texte, vous avez besoin de -@url{http://www.gnu.org/software/emacs, Emacs}, amélioré par le superbe -@url{http://nongnu.org/geiser/, Geiser}. +The Perfect Setup to hack on Guix is basically the perfect setup used for +Guile hacking (@pxref{Using Guile in Emacs,,, guile, Guile Reference +Manual}). First, you need more than an editor, you need +@url{http://www.gnu.org/software/emacs, Emacs}, empowered by the wonderful +@url{http://nongnu.org/geiser/, Geiser}. To set that up, run: + +@example +guix package -i emacs guile emacs-geiser +@end example Geiser permet le développement interactif et incrémental depuis Emacs : la compilation du code et son évaluation depuis les buffers, l'accès à la @@ -229,6 +233,461 @@ déclenchement @code{origin…}, qui peut aussi être étendue. L'extrait finissent sur @code{…}, qui peuvent aussi être étendues. +@node Consignes d'empaquetage +@section Consignes d'empaquetage + +@cindex paquets, création +The GNU distribution is nascent and may well lack some of your favorite +packages. This section describes how you can help make the distribution +grow. + +Les paquets de logiciels libres sont habituellement distribués sous forme +@dfn{d'archives de sources} — typiquement des fichiers @file{.tar.gz} +contenant tous les fichiers sources. Ajouter un paquet à la distribution +signifie essentiellement deux choses : ajouter une @dfn{recette} qui décrit +comment construire le paquet, avec une liste d'autres paquets requis pour le +construire, et ajouter des @dfn{métadonnées de paquet} avec la recette, +comme une description et une licence. + +Dans Guix, toutes ces informations sont incorporées dans les +@dfn{définitions de paquets}. Les définitions de paquets fournissent une +vue de haut-niveau du paquet. Elles sont écrites avec la syntaxe du langage +de programmation Scheme ; en fait, pour chaque paquet nous définissons une +variable liée à la définition et exportons cette variable à partir d'un +module (@pxref{Modules de paquets}). Cependant, il n'est @emph{pas} nécessaire +d'avoir une connaissance approfondie du Scheme pour créer des paquets. Pour +plus d'informations sur les définitions des paquets, @pxref{Définition des paquets}. + +Une fois une définition de paquet en place, stocké dans un fichier de +l'arborescence des sources de Guix, il peut être testé avec la commande +@command{guix build} (@pxref{Invoquer guix build}). Par exemple, en +supposant que le nouveau paquet s'appelle @code{gnew}, vous pouvez lancer +cette commande depuis l'arborescence de construction de Guix (@pxref{Lancer Guix avant qu'il ne soit installé}) : + +@example +./pre-inst-env guix build gnew --keep-failed +@end example + +Utiliser @code{--keep-failed} rend facile le débogage des échecs car il +fournit l'accès à l'arborescence de construction qui a échouée. Une autre +sous-commande utile pour le débogage est @code{--log-file}, pour accéder au +journal de construction. + +Si le paquet n'est pas connu de la commande @command{guix}, il se peut que +le fichier source ait une erreur de syntaxe, ou qu'il manque une clause +@code{define-public} pour exporter la variable du paquet. Pour comprendre +cela, vous pouvez charger le module depuis Guile pour avoir plus +d'informations sur la véritable erreur : + +@example +./pre-inst-env guile -c '(use-modules (gnu packages gnew))' +@end example + +Once your package builds correctly, please send us a patch +(@pxref{Envoyer des correctifs}). Well, if you need help, we will be happy to +help you too. Once the patch is committed in the Guix repository, the new +package automatically gets built on the supported platforms by +@url{http://hydra.gnu.org/jobset/gnu/master, our continuous integration +system}. + +@cindex substitution +Users can obtain the new package definition simply by running @command{guix +pull} (@pxref{Invoquer guix pull}). When @code{@value{SUBSTITUTE-SERVER}} +is done building the package, installing the package automatically downloads +binaries from there (@pxref{Substituts}). The only place where human +intervention is needed is to review and apply the patch. + + +@menu +* Liberté logiciel:: Ce que la distribution peut contenir. +* Conventions de nommage:: Qu'est-ce qu'un bon nom ? +* Numéros de version:: Lorsque le nom n'est pas suffisant. +* Synopsis et descriptions:: Aider les utilisateurs à trouver le bon + paquet. +* Modules python:: Un peu de comédie anglaise. +* Modules perl:: Petites perles. +* Paquets java:: Pause café. +* Polices de caractères:: À fond les fontes. +@end menu + +@node Liberté logiciel +@subsection Liberté logiciel + +@c =========================================================================== +@c +@c This file was generated with po4a. Translate the source file. +@c +@c =========================================================================== +@c Adapted from http://www.gnu.org/philosophy/philosophy.html. +@cindex logiciel libre +Le système d'exploitation GNU a été développé pour que les utilisateurs +puissent utiliser leur ordinateur en toute liberté. GNU est un +@dfn{logiciel libre}, ce qui signifie que les utilisateur ont les +@url{http://www.gnu.org/philosophy/free-sw.fr.html,quatre libertés +essentielles} : exécuter le programmer, étudier et modifier le programme +sous sa forme source, redistribuer des copies exactes et distribuer les +versions modifiées. Les paquets qui se trouvent dans la distribution GNU ne +fournissent que des logiciels qui respectent ces quatre libertés. + +En plus, la distribution GNU suit les +@url{http://www.gnu.org/distros/free-system-distribution-guidelines.html,recommandations +pour les distributions systèmes libres}. Entre autres choses, ces +recommandations rejettent les microgiciels non libres, les recommandations +de logiciels non libres et discute des façon de gérer les marques et les +brevets. + +Certaines sources amont autrement parfaitement libres contiennent une petite +partie facultative qui viole les recommandations ci-dessus, par exemple car +cette partie est du code non-libre. Lorsque cela arrive, les éléments en +question sont supprimés avec des correctifs ou des bouts de codes appropriés +dans la forme @code{origin} du paquet (@pxref{Définition des paquets}). De cette +manière, @code{guix build --source} renvoie la source « libérée » plutôt que +la source amont sans modification. + + +@node Conventions de nommage +@subsection Conventions de nommage + +@cindex nom du paquet +Un paquet a en fait deux noms qui lui sont associés : d'abord il y a le nom +de la @emph{variable Scheme}, celui qui suit @code{define-public}. Par ce +nom, le paquet peut se faire connaître par le code Scheme, par exemple comme +entrée d'un autre paquet. Deuxièmement, il y a la chaîne dans le champ +@code{name} d'une définition de paquet. Ce nom est utilisé par les +commandes de gestion des paquets comme @command{guix package} et +@command{guix build}. + +Les deux sont habituellement les mêmes et correspondent à la conversion en +minuscule du nom du projet choisi en amont, où les underscores sont +remplacés par des tirets. Par exemple, GNUnet est disponible en tant que +@code{gnunet} et SDL_net en tant que @code{sdl-net}. + +Nous n'ajoutons pas de préfixe @code{lib} au bibliothèques de paquets, à +moins qu'il ne fasse partie du nom officiel du projet. Mais @pxref{Modules python} et @ref{Modules perl} pour des règles spéciales concernant les +modules pour les langages Python et Perl. + +Les noms de paquets de polices sont gérés différemment, @pxref{Polices de caractères}. + + +@node Numéros de version +@subsection Numéros de version + +@cindex version du paquet +Nous n'incluons en général que la dernière version d'un projet de logiciel +libre donné. Mais parfois, par exemple pour des versions incompatibles de +bibliothèques, deux (ou plus) versions du même paquet sont requises. Elles +ont besoin d'un nom de variable Scheme différent. Nous utilisons le nom +défini dans @ref{Conventions de nommage} pour la version la plus récente ; les +versions précédentes utilisent le même nom, suffixé par @code{-} et le plus +petit préfixe du numéro de version qui permet de distinguer deux versions. + +Le nom dans la définition du paquet est le même pour toutes les versions +d'un paquet et ne contient pas de numéro de version. + +Par exemple, les version 2.24.20 et 3.9.12 de GTK+ peuvent être inclus de +cette manière : + +@example +(define-public gtk+ + (package + (name "gtk+") + (version "3.9.12") + ...)) +(define-public gtk+-2 + (package + (name "gtk+") + (version "2.24.20") + ...)) +@end example +Si nous voulons aussi GTK+ 3.8.2, cela serait inclus de cette manière : +@example +(define-public gtk+-3.8 + (package + (name "gtk+") + (version "3.8.2") + ...)) +@end example + +@c See <https://lists.gnu.org/archive/html/guix-devel/2016-01/msg00425.html>, +@c for a discussion of what follows. +@cindex numéro de version, pour les instantanés des systèmes de contrôle de version +Parfois, nous incluons des paquets provenant d'instantanés de systèmes de +contrôle de version (VCS) au lieu de versions publiées formellement. Cela +devrait rester exceptionnel, car c'est le rôle des développeurs amont de +spécifier quel est la version stable. Cependant, c'est parfois nécessaire. +Donc, que faut-il mettre dans le champ @code{version} ? + +Clairement, nous devons rendre l'identifiant de commit de l'instantané du +VCS visible dans la version, mais nous devons aussi nous assurer que la +version augmente de manière monotone pour que @command{guix package +--upgrade} puisse déterminer quelle version est la plus récente. Comme les +identifiants de commits, notamment avec Git, n'augmentent pas, nous ajoutons +un numéro de révision qui nous augmentons à chaque fois que nous mettons à +jour vers un nouvel instantané. La chaîne qui en résulte ressemble à cela : + +@example +2.0.11-3.cabba9e + ^ ^ ^ + | | `-- ID du commit en amont + | | + | `--- révision du paquet Guix + | +dernière version en amont +@end example + +C'est une bonne idée de tronquer les identifiants dans le champ +@code{version} à disons 7 caractères. Cela évite un problème esthétique (en +supposant que l'esthétique ait un rôle à jouer ici) et des problèmes avec +les limites de l'OS comme la longueur maximale d'un shebang (127 octets pour +le noyau Linux). Il vaut mieux utilise l'identifiant de commit complet dans +@code{origin} cependant, pour éviter les ambiguïtés. Une définition de +paquet peut ressembler à ceci : + +@example +(define my-package + (let ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7") + (revision "1")) ;révision du paquet Guix + (package + (version (git-version "0.9" revision commit)) + (source (origin + (method git-fetch) + (uri (git-reference + (url "git://example.org/my-package.git") + (commit commit))) + (sha256 (base32 "1mbikn@dots{}")) + (file-name (git-file-name name version)))) + ;; @dots{} + ))) +@end example + +@node Synopsis et descriptions +@subsection Synopsis et descriptions + +@cindex description du paquet +@cindex résumé du paquet +Comme nous l'avons vu avant, chaque paquet dans GNU@tie{}Guix contient un +résumé et une description (@pxref{Définition des paquets}). Les résumés et les +descriptions sont importants : ce sont eux que recherche @command{guix +package --search}, et c'est une source d'informations cruciale pour aider +les utilisateurs à déterminer si un paquet donner correspond à leurs +besoins. En conséquence, les mainteneurs doivent prêter attention à leur +contenu. + +Les résumés doivent commencer par une lettre capitale et ne doit pas finir +par un point. Ils ne doivent pas commencer par « a » ou « the » (« un » ou +« le/la »), ce qui n'apporte généralement rien ; par exemple, préférez « +File-frobbing tool » (« Outil de frobage de fichier ») à « A tool that frobs +file » (« Un outil qui frobe les fichiers »). Le résumé devrait dire ce que +le paquet est — p.@: ex.@: « Utilitaire du cœur de GNU (fichier, text, +shell) » — ou ce à quoi il sert — p.@: ex.@: le résumé de grep est « Affiche +des lignes correspondant à un motif ». + +Gardez à l'esprit que le résumé doit avoir un sens pour une large audience. +Par exemple « Manipulation d'alignements au format SAM » peut avoir du sens +pour un bioinformaticien chevronné, mais n'aidera pas ou pourra perdre une +audience de non-spécialistes. C'est une bonne idée de créer un résumé qui +donne une idée du domaine d'application du paquet. Dans cet exemple, cela +donnerait « Manipulation d'alignements de séquences de nucléotides », ce qui +devrait donner une meilleure idée à l'utilisateur pour savoir si c'est ce +qu'il recherche. + +Les descriptions devraient faire entre cinq et dix lignes. Utilisez des +phrases complètes, et évitez d'utiliser des acronymes sans les introduire +d'abord. Évitez les phrases marketings comme « world-leading », « +industrial-strength » et « next-generation » et évitez les superlatifs comme +« the most advanced » — ils ne sont pas utiles pour les utilisateurs qui +cherchent un paquet et semblent même un peu suspects. À la place, essayez +d'être factuels, en mentionnant les cas d'utilisation et les +fonctionnalités. + +@cindex balisage texinfo, dans les descriptions de paquets +Les descriptions peuvent inclure du balisage Texinfo, ce qui est utile pour +introduire des ornements comme @code{@@code} ou @code{@@dfn}, des listes à +points ou des hyperliens (@pxref{Overview,,, texinfo, GNU Texinfo}). +Cependant soyez prudents lorsque vous utilisez certains symboles, par +exemple @samp{@@} et les accolades qui sont les caractères spéciaux de base +en Texinfo (@pxref{Special Characters,,, texinfo, GNU Texinfo}). Les +interfaces utilisateurs comme @command{guix package --show} prennent en +charge le rendu. + +Les résumés et les descriptions sont traduits par des volontaires +@uref{http://translationproject.org/domain/guix-packages.html, sur le projet +de traduction} pour que le plus d'utilisateurs possible puissent les lire +dans leur langue natale. Les interfaces utilisateurs les recherchent et les +affichent dans la langue spécifiée par le paramètre de régionalisation +actuel. + +Pour permettre à @command{xgettext} de les extraire comme des chaînes +traduisibles, les résumés et les descriptions @emph{doivent être des chaînes +litérales}. Cela signifie que vous ne pouvez pas utiliser +@code{string-append} ou @code{format} pour construire ces chaînes : + +@lisp +(package + ;; @dots{} + (synopsis "Ceci est traduisible") + (description (string-append "Ceci n'est " "*pas*" " traduisible."))) +@end lisp + +La traduction demande beaucoup de travail, donc en tant que packageur, +faîtes encore plus attention à vos résumés et descriptions car chaque +changement peut demander d'autant plus de travail de la part des +traducteurs. Pour les aider, il est possible de donner des recommandations +ou des instructions qu'ils pourront voir en insérant des commentaires +spéciaux comme ceci (@pxref{xgettext Invocation,,, gettext, GNU Gettext}) : + +@example +;; TRANSLATORS: "X11 resize-and-rotate" should not be translated. +(description "ARandR is designed to provide a simple visual front end +for the X11 resize-and-rotate (RandR) extension. @dots{}") +@end example + + +@node Modules python +@subsection Modules python + +@cindex python +Nous incluons actuellement Python 2 et Python 3, sous les noms de variables +Scheme @code{python-2} et @code{python} comme expliqué dans @ref{Numéros de version}. Pour éviter la confusion et les problèmes de noms avec d'autres +langages de programmation, il semble désirable que le nom d'un paquet pour +un module Python contienne le mot @code{python}. + +Certains modules ne sont compatibles qu'avec une version de Python, d'autres +avec les deux. Si le paquet Foo ne compile qu'avec Ptyhon 3, on le nomme +@code{python-foo} ; s'il ne compile qu'avec Python 2, on le nome +@code{python2-foo}. S'il est compatible avec les deux versions, nous créons +deux paquets avec les noms correspondant. + +If a project already contains the word @code{python}, we drop this; for +instance, the module python-dateutil is packaged under the names +@code{python-dateutil} and @code{python2-dateutil}. If the project name +starts with @code{py} (e.g.@: @code{pytz}), we keep it and prefix it as +described above. + +@subsubsection Spécifier les dépendances +@cindex entrées, pour les paquets Python + +Les informations de dépendances pour les paquets Python se trouvent +généralement dans l'arborescence des source du paquet, avec plus ou moins de +précision : dans le fichier @file{setup.py}, dans @file{requirements.txt} ou +dans @file{tox.ini}. + +Votre mission, lorsque vous écrivez une recette pour un paquet Python, est +de faire correspondre ces dépendances au bon type « d'entrée » +(@pxref{Référence de paquet, inputs}). Bien que l'importeur @code{pypi} fasse +du bon boulot (@pxref{Invoquer guix import}), vous devriez vérifier la liste +suivant pour déterminer où va telle dépendance. + +@itemize + +@item +Nous empaquetons Python 2 avec @code{setuptools} et @code{pip} installé +comme Python 3.4 par défaut. Ainsi, vous n'avez pas à spécifié ces +entrées. @command{guix lint} vous avertira si vous faîtes cela. + +@item +Les dépendances Python requises à l'exécutions vont dans +@code{propagated-inputs}. Elles sont typiquement définies dans le mot-clef +@code{install_requires} dans @file{setup.py} ou dans le fichier +@file{requirements.txt}. + +@item +Les paquets Python requis uniquement à la construction — p.@: ex.@: ceux +listés dans le mot-clef @code{setup_requires} de @file{setup.py} — ou +seulement pour les tests — p.@: ex.@: ceux dans @code{tests_require} — vont +dans @code{native-inputs}. La raison est qu'ils n'ont pas besoin d'être +propagés car ils ne sont pas requis à l'exécution et dans le cas d'une +compilation croisée, c'est l'entrée « native » qu'il nous faut. + +Les cadriciels de tests @code{pytest}, @code{mock} et @code{nose} sont des +exemples. Bien sûr si l'un de ces paquets est aussi requis à l'exécution, +il doit aller dans @code{propagated-inputs}. + +@item +Tout ce qui ne tombe pas dans les catégories précédentes va dans +@code{inputs}, par exemple des programmes pour des bibliothèques C requises +pour construire des paquets Python avec des extensions C. + +@item +Si un paquet Python a des dépendances facultatives (@code{extras_require}), +c'est à vous de décider de les ajouter ou non, en fonction du ratio entre +utilité et complexité (@pxref{Envoyer des correctifs, @command{guix size}}). + +@end itemize + + +@node Modules perl +@subsection Modules perl + +@cindex perl +Les programmes Perl utiles en soit sont nommés comme les autres paquets, +avec le nom amont en minuscule. Pour les paquets Perl contenant une seule +classe, nous utilisons le nom de la classe en minuscule, en remplaçant les +occurrences de @code{::} par des tirets et en préfixant le tout par +@code{perl-}. Donc la classe @code{XML::Parser} devient +@code{perl-xml-parser}. Les modules contenant plusieurs classes gardent +leur nom amont en minuscule et sont aussi préfixés par @code{perl-}. Ces +modules tendent à avoir le mot @code{perl} quelque part dans leur nom, que +nous supprimons en faveur du préfixe. Par exemple, @code{libwww-perl} +devient @code{perl-libwww}. + + +@node Paquets java +@subsection Paquets java + +@cindex java +Le programmes Java utiles en soit sont nommés comme les autres paquets, avec +le nom amont en minuscule. + +Pour éviter les confusions et les problèmes de nom avec d'autres langages de +programmation, il est désirable que le nom d'un paquet Java soit préfixé par +@code{java-}. Si un projet contient déjà le mot @code{java}, nous le +supprimons, par exemple le paquet @code{ngsjava} est empaqueté sous le nom +@code{java-ngs}. + +Pour les paquets java contenant une seul classe ou une petite hiérarchie de +classes, nous utilisons le nom de la classe en minuscule, en remplaçant les +occurrences de @code{.} par des tirets et en préfixant le tout par +@code{java-}. Donc la classe @code{apache.commons.cli} devient +@code{java-apache-commons-cli}. + + +@node Polices de caractères +@subsection Polices de caractères + +@cindex polices +Pour les polices qui n esont en général par installées par un utilisateurs +pour du traitement de texte, ou qui sont distribuées en tant que partie d'un +paquet logiciel plus gros, nous nous appuyons sur les règles générales pour +les logiciels ; par exemple, cela s'applique aux polices livrées avec le +système X.Org ou les polices qui font partie de TeX Live. + +Pour rendre plus facile la recherche par l'utilisateur, les noms des autres +paquets contenant seulement des polices sont construits ainsi, +indépendamment du nom du paquet en amont. + +Le nom d'un paquet contenant une unique famille de polices commence par +@code{font-} ; il est suivi du nom du fondeur et d'un tiret @code{-} si le +fondeur est connu, et du nom de la police, dont les espaces sont remplacés +par des tirets (et comme d'habitude, toutes les lettres majuscules sont +transformées en minuscules). Par exemple, la famille de polices Gentium de +SIL est empaqueté sous le nom @code{font-sil-gentium}. + +Pour un paquet contenant plusieurs familles de polices, le nom de la +collection est utilisée à la place du nom de la famille. Par exemple les +polices Liberation consistent en trois familles, Liberation Sans, Liberation +Serif et Liberation Mono. Elles pourraient être empaquetées séparément sous +les noms @code{font-liberation-sans} etc, mais comme elles sont distribuées +ensemble sous un nom commun, nous préférons les empaqueter ensemble en tant +que @code{font-liberation}. + +Dans le cas où plusieurs formats de la même famille ou collection sont +empaquetés séparément, une forme courte du format, préfixé d'un tiret est +ajouté au nom du paquet. Nous utilisont @code{-ttf} pour les polices +TrueType, @code{-otf} pour les polices OpenType et @code{-type1} pour les +polices Type 1 de PostScript. + + @node Style de code @section Style de code @@ -323,9 +782,8 @@ vous l'entrez. En plus, @code{paredit.vim}} peut vous aider à gérer toutes ces parenthèses. Nous demandons que toutes les procédure de premier niveau contiennent une -chaîne de documentation. Ce pré-requis peut être relâché pour les -procédures privées simples dans l'espace de nom @code{(guix build @dots{})} -cependant. +chaîne de documentation. Ce prérequis peut être relâché pour les procédures +privées simples dans l'espace de nom @code{(guix build @dots{})} cependant. Les procédures ne devraient pas avoir plus de quatre paramètres positionnés. Utilisez des paramètres par mot-clefs pour les procédures qui @@ -376,6 +834,33 @@ Assurez-vous que le paquet se construise sur votre plate-forme avec @code{guix build @var{paquet}}. @item +We recommend you also try building the package on other supported +platforms. As you may not have access to actual hardware platforms, we +recommend using the @code{qemu-binfmt-service-type} to emulate them. In +order to enable it, add the following service to the list of services in +your @code{operating-system} configuration: + +@example +(service qemu-binfmt-service-type + (qemu-binfmt-configuration + (platforms (lookup-qemu-platforms "arm" "aarch64" "ppc" "mips64el")) + (guix-support? #t))) +@end example + +Then reconfigure your system. + +You can then build packages for different platforms by specifying the +@code{--system} option. For example, to build the "hello" package for the +armhf, aarch64, powerpc, or mips64 architectures, you would run the +following commands, respectively: +@example +guix build --system=armhf-linux --rounds=2 hello +guix build --system=aarch64-linux --rounds=2 hello +guix build --system=powerpc-linux --rounds=2 hello +guix build --system=mips64el-linux --rounds=2 hello +@end example + +@item @cindex construction groupée Assurez-vous que le paquet n'utilise pas de copie groupée d'un logiciel déjà disponible dans un paquet séparé. @@ -391,21 +876,18 @@ depuis un unique emplacement et qu'ils affectent tout le système, ce qu'empêchent les copies groupées. @item -Regardez le profile rapporté par @command{guix size} (@pxref{Invoquer guix size}). Cela vous permettra de remarquer des références à d'autres paquets -qui ont été retenus. Il peut aussi aider à déterminer s'il faut découper le -paquet (@pxref{Des paquets avec plusieurs résultats}) et quelle dépendance -facultative utiliser. +Take a look at the profile reported by @command{guix size} (@pxref{Invoquer guix size}). This will allow you to notice references to other packages +unwillingly retained. It may also help determine whether to split the +package (@pxref{Des paquets avec plusieurs résultats}), and which optional +dependencies should be used. In particular, avoid adding @code{texlive} as +a dependency: because of its extreme size, use @code{texlive-tiny} or +@code{texlive-union} instead. @item Pour les changements important, vérifiez que les paquets qui en dépendent (s'ils existent) ne sont pas affectés par le changement ; @code{guix refresh --list-dependant @var{paquet}} vous aidera (@pxref{Invoquer guix refresh}). -@c =========================================================================== -@c -@c This file was generated with po4a. Translate the source file. -@c -@c =========================================================================== @c See <https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html>. @cindex stratégie de branche @cindex stratégie de planification des reconstructions @@ -418,7 +900,7 @@ principes : branche @code{master} (changements non-disruptifs). @item entre 300 et 1 200 paquets dépendants -branche @code{staging} (changemets non-disruptifs). Cette branche devrait +branche @code{staging} (changements non-disruptifs). Cette branche devrait être fusionnées dans @code{master} tous les 3 semaines. Les changements par thèmes (par exemple une mise à jour de la pile GNOME) peuvent aller dans une branche spécifique (disons, @code{gnome-updates}). @@ -460,15 +942,14 @@ Cela est suffisant pour trouver une classe de non-déterminisme commune, comme l'horodatage ou des sorties générées aléatoirement dans le résultat de la construction. -Une autre option consiste à utiliser @command{guix challenge} -(@pxref{Invoquer guix challenge}). Vous pouvez lancer la commande une fois -que les paquets ont été commités et construits par @code{hydra.gnu.org} pour -vérifier s'il obtient le même résultat que vous. Mieux encore : trouvez une -autre machine qui peut le construire et lancez @command{guix publish}. Puis -la machine distante est sûrement différente de la vôtre, cela peut trouver -des problèmes de non-déterminisme liés au matériel — par exemple utiliser -une extension du jeu d'instruction — ou du noyau du système d'exploitation — -par exemple se reposer sur @code{uname} ou les fichiers de @file{/proc}. +Another option is to use @command{guix challenge} (@pxref{Invoquer guix challenge}). You may run it once the package has been committed and built +by @code{@value{SUBSTITUTE-SERVER}} to check whether it obtains the same +result as you did. Better yet: Find another machine that can build it and +run @command{guix publish}. Since the remote build machine is likely +different from yours, this can catch non-determinism issues related to the +hardware---e.g., use of different instruction set extensions---or to the +operating system kernel---e.g., reliance on @code{uname} or @file{/proc} +files. @item Lorsque vous écrivez de la documentation, utilisez une formulation au genre |