Go to:
Gentoo Home
Documentation
Forums
Lists
Bugs
Planet
Store
Wiki
Get Gentoo!
Gentoo's Bugzilla – Attachment 47829 Details for
Bug 73654
[fr] new translation for devrel HB
Home
|
New
–
[Ex]
|
Browse
|
Search
|
Privacy Policy
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
hb-guide-common-mistakes.xml
devrel-hb-guide-common-mistakes.xml (text/plain), 14.98 KB, created by
Clément VARALDI
on 2005-01-07 03:39:55 UTC
(
hide
)
Description:
hb-guide-common-mistakes.xml
Filename:
MIME Type:
Creator:
Clément VARALDI
Created:
2005-01-07 03:39:55 UTC
Size:
14.98 KB
patch
obsolete
><?xml version='1.0' encoding='UTF-8'?> ><!DOCTYPE sections SYSTEM "/dtd/book.dtd"> > ><!-- Le contenu de ce document est sous licence CC-BY-SA --> ><!-- Voir http://creativecommons.org/licenses/by-sa/1.0 --> > ><sections> > <section> > <title>Erreurs communes d'écriture d'ebuild</title> > <subsection> > <title>Introduction</title> > <body> > <p> > On peut retrouver un certain nombre d'erreurs communes dans les > ebuilds qui sont soumis par les utilisateurs. Assurez-vous que les > ebuilds que vous soumettez ne possèdent aucune de ces erreurs. Avant de > soumettre un ebuild, assurez-vous que vous avez bien lu la <uri link= > "?part=3&chap=1">Politique de développement des ebuilds pour Gentoo > </uri> et le <uri link="?part=2&chap=1">HOWTO ebuild Gentoo</uri>. > Lisez aussi quelques ebuilds (plus d'un ou deux) dans l'arbre de Portage > pour connaître le style dans lequel les ebuilds sont écrits. > </p> > > <p> > Ensuite, il pourrait être utile de lire quelques ebuilds qui utilisent > des eclass et comprendre comment les utiliser en lisant le <uri link= > "?part=2&chap=2">HOWTO Eclass</uri>. Finalement, vous devez lire le > <uri link="/doc/en/ebuild-submit.xml">Guide de contribution d'ebuilds > </uri> soigneusement avant de soumettre vos ebuilds. > </p> > </body> > </subsection> > > > <subsection> > <title>En-tête cassée/invalide/manquante</title> > <body> > <p> > Quand vous soumettez vos ebuilds, l'en-tête devrait être <e>exactement > </e> le même que celui dans <path>/usr/portage/skel.ebuild</path>. Il > est important de ne pas le modifier et de s'assurer que la ligne <c> > $Header: $</c> est intacte. > </p> > > <p> > Les trois premières lignes <e>doivent</e> ressembler à celles-ci : > </p> > > <pre caption="En-tête valide"> ># Copyright 1999-2004 Gentoo Foundation ># Distributed under the terms of the GNU General Public License v2 ># $Header: $ > </pre> > > <p> > Nous n'avez pas besoin de modifier la ligne <c>$Header: $</c> > uniquement si vous soumettez un ebuild remonté ou une correction > d'ebuild. Mais la ligne doit être présente. Quand on vérifie l'ebuild > dans le CVS, cet en-tête sera modifié avec la version appropriée et la > date. Donc il n'y a pas besoin de le modifier manuellement. > </p> > </body> > </subsection> > > > <subsection> > <title>Non déclaration de IUSE</title> > <body> > <p> > L'oubli le plus fréquent, et de loin, est la variable IUSE. Vous devez > (selon le <uri link="?part=2&chap=1">HOWTO ebuild Gentoo</uri>) > inclure la variable IUSE, même si aucun paramètre USE n'est utilisé. Si > il n'y en a aucun de supporté, ajoutez simplement la ligne > suivante : > </p> > > <pre caption="IUSE vide"> >IUSE="" > </pre> > </body> > </subsection> > > > <subsection> > <title>P, PV, PN, PF redéfinis</title> > <body> > <p> > Vous ne devez jamais redéfinir ces variables. Utilisez toujours MY_P, > MY_PN, MY_PV, P0, etc. Lisez d'autres ebuilds dans Portage qui utilisent > cela pour plus d'informations. La plupart des ebuilds utilisent la > fonctionnalité bash des "extensions aux paramètres". Lire la page de > manuel de bash pour comprendre comment elles fonctionnent. > </p> > > <p> > Soit dit en passant, si vous trouvez un paquet qui redéfinit une de ces > variables, ne le copiez pas. Soumettez un bogue à propos de l'ebuild. > </p> > </body> > </subsection> > > > <subsection> > <title>Inclure les numéros de version dans SRC_URI et S</title> > <body> > <p> > Vous devez essayer d'éviter d'inclure les numéros de version dans les > variables SRC_URI et S. Toujours essayer d'utiliser ${PV} ou ${P}. Cela > permet une maintenance de l'ebuild plus facile. Si un numéro de version > n'est pas cohérent par rapport à l'archive/source, alors utilisez MY_P. > Par exemple, dev-python/pyopenal récupère une archive nommée PyOpenAL, > donc nous effectuons une redéfinition comme suit : > </p> > > <pre caption="Exemple de redéfinition de version"> >MY_P=${P/pyopenal/PyOpenAL} >SRC_URI="http://oomadness.tuxfamily.org/downloads/${MY_P}.tar.gz" >S=${WORKDIR}/${MY_P} > </pre> > </body> > </subsection> > > > <subsection> > <title>DEPEND a des erreurs syntaxiques</title> > <body> > <p> > Il y a plusieurs choses qui ne vont pas avec les variables DEPEND et > RDEPEND soumis par des utilisateurs en général... Voici les points les > plus importants à suivre lorsque vous écrivez la partie sur les > dépendances. > </p> > > <ul> > <li> > <e>Toujours inclure la catégorie</e> > <br /> > Par exemple, utilisez <c>>=x11-libs/gtk+-2</c> et non > <c>>=gtk+-2</c>. > </li> > > <li> > <e>N'utilisez pas d'astérisque (*) pour >= dépendances.</e> > <br /> > Par exemple, on doit avoir <c>>=x11-libs/gtk+-2</c> à la place de > <c>>=x11-libs/gtk+-2*</c>. > </li> > > <li> > <e>Spécifique à GTK. Toujours utiliser =x11-libs/gtk+-1.2* pour les > applications GTK+1.</e> > </li> > > <li> > <e>Ne jamais dépendre d'un paquet meta</e> > <br /> > Du coup, ne pas dépendre de gnome-base/gnome, mais toujours d'une > bibliothèque spécifique, comme libgnome. > </li> > > <li> > <e>Une dépendance par ligne.</e> > <br /> > Ne mettez pas plusieurs dépendances sur la même ligne. Cela rend le > code plus difficile à lire et à suivre. > </li> > </ul> > </body> > </subsection> > > > <subsection> > <title>DEPEND est incomplet</title> > <body> > <p> > Voici encore une erreur assez commune. La personne qui soumet l'ebuild > le soumet, et l'ebuild fonctionne tout simplement, sans vérifier si > les dépendances sont correctes. Voici quelques trucs pour trouver les > bonnes dépendances. > </p> > > <ul> > <li> > <e>Lisez les fichiers configure.in ou configure.ac</e> > <br /> > Lisez-les pour vérifier les paquets qui y sont inclus. Les éléments à > rechercher sont l'utilisation de pkg-config ou les fonctions AM_* qui > vérifient une version spécifique. > </li> > > <li> > <e>Regardez les fichiers .spec inclus</e> > <br /> > Un bon indicateur des dépendances est de regarder dans les fichiers > .spec pour repérer des dépendances intéressantes. Cependant, ne vous > y fiez pas uniquement en pensant que ce sera une liste définitive et > complète des dépendances. > </li> > > <li> > <e>Lire le site Internet de l'application/la bibliothèque</e> > <br /> > Regardez sur le site de l'application pour repérer les dépendances > qu'ils suggèrent comme étant nécessaires. > </li> > > <li> > <e>Lisez les README et INSTALL du paquet</e> > <br /> > Ils contiennent aussi souvent des informations utiles sur comment > construire et installer les paquets. > </li> > > <li> > <e>Souvenez-vous des dépendances non-binaires comme pkg-config, les > programmes de génération de documentation, etc.</e> > <br /> > Souvent, le processus de construction nécessite des dépendances comme > intltool, libtool, pkg-config, doxygen, scrollkeeper, gtk-doc, etc. > Assurez-vous que ces dépendances sont bien respectées. > </li> > </ul> > </body> > </subsection> > > > <subsection> > <title>LICENSE invalide</title> > <body> > <p> > Une autre erreur commune que les utilisateurs font à l'heure de > soumettre des ebuilds est de fournir une licence invalide. Par exemple, > <c>GPL</c> n'est pas une licence valide. Vous devez spécifier <c>GPL-1 > </c> ou <c>GPL-2</c>. Même chose pour la <c>LGPL</c>. Assurez-vous que > la licence que vous utilisez dans le champ <c>LICENSE</c> est une > licence qui existe dans <path>/usr/portage/licenses</path>. Comme truc, > vous pouvez lire le fichier <c>COPYING</c> dans l'archive source, pour > repérer la licence. Si la licence n'est pas spécifiée, utilise la <c> > GPL-1</c> ou <c>GPL-2</c>, on est souvent en présence de la <c>GPL-2 > </c>. > </p> > > <p> > Si la licence du paquet que vous soumettez est unique et n'est pas dans > <path>/usr/portage/licenses/</path>, alors vous devez soumettre une > nouvelle licence dans un fichier séparé. > </p> > </body> > </subsection> > > > <subsection> > <title>Architectures non testées dans les KEYWORDS</title> > <body> > <p> > Merci de n'ajouter d'architectures dans les KEYWORDS que si l'ebuild a > effectivement été testé sur cette architecture. De même, tous les > nouveaux ebuilds doivent être en ~ARCH. Assurez-vous que quand vous > remontez une version, toutes les architectures stables sont marquées > d'un <c>~</c>. > </p> > </body> > </subsection> > > > <subsection> > <title>SLOT manquant</title> > <body> > <p> > Assurez-vous que vous avez la variable SLOT déclarée dans l'ebuild. Si > vous n'avez pas l'intention de l'utiliser, ne la supprimez pas. > Mettez : > </p> > > <pre caption="Variable SLOT par défaut"> >SLOT="0" > </pre> > </body> > </subsection> > > > <subsection> > <title>DESCRIPTION et HOMEPAGE incorrects</title> > <body> > <p> > Merci de vérifier si la variable HOMEPAGE est correcte et pointe bien > sur la bonne page s'ils veulent récupérer plus d'informations sur le > paquet. Et assurez-vous que la variable DESCRIPTION n'est pas trop > longue. Les bonnes descriptions décrivent la fonction principale d'un > paquet en une ligne. > </p> > </body> > </subsection> > > > <subsection> > <title>Utilisation incorrecte des espaces à la place de tabulations</title> > <body> > <p> > Ce n'est pas vraiment un plaisir que de reformatter des lignes d'ebuilds > parce que la personne qui l'a soumis ne suit pas les guides pour > utiliser des tabulations à la place d'espaces. Donc <e>s'il vous plaît > </e>, utilisez des tabulations. > </p> > </body> > </subsection> > > > <subsection> > <title>espaces en fin de lignes</title> > <body> > <p> > Souvenez-vous que vous devez lancer repoman sur vos ebuilds pour qu'il > puisse vous signaler s'il reste des espaces inutiles à la fin de vos > lignes, ou dans les lignes vides. > </p> > </body> > </subsection> > > > <subsection> > <title>Ajouter des S=${WORKDIR}/${P} redondants</title> > <body> > <p> > Si <c>S=${WORKDIR}/${P}</c>, alors vous ne devez pas l'ajouter dans > votre ebuild. Vous ne devez l'ajouter que si l'on a quelque chose > d'autre que <c>${WORKDIR}/${P}</c>. > </p> > </body> > </subsection> > > > <subsection> > <title>Documentation manquante</title> > <body> > <p> > Si votre paquet a une documentation, assurez-vous que vous l'installez > en utilisant <c>dodoc</c> ou en les mettant dans <path> > /usr/share/doc/${PF}</path>. N'oubliez pas de vérifier s'il y a des > erreurs quand vous lancez <c>dodoc</c>/<c>doins</c>. > </p> > </body> > </subsection> > </section> > > > > <section> > <title>Erreurs communes de soumission d'ebuilds</title> > <subsection> > <title>Introduction</title> > <body> > <p> > Merci de soumettre vos ebuilds correctement en suivant le <uri link= > "/doc/en/ebuild-submit.xml">HOWTO contribuer pour les ebuilds</uri> sur > la <uri link="/doc/en/index.xml">page de documentation Gentoo</uri>. > </p> > </body> > </subsection> > > > <subsection> > <title>Archiver un ebuild</title> > <body> > <p> > S'il vous plaît, par pitié, n'attachez pas les ebuilds en archives. > Attachez également les correctifs séparément afin qu'on puisse les > examiner facilement. > </p> > </body> > </subsection> > > > <subsection> > <title>Proposer des ebuilds</title> > <body> > <p> > Ne copiez-collez pas un ebuild dans le champ de commentaire du bugzilla. > </p> > </body> > </subsection> > > > <subsection> > <title>Aucune description sur ce qu'est le paquet</title> > <body> > <p> > Merci de nous permettre de savoir ce qu'est le paquet, et remplissez le > champ URL avec la page Internet de l'application, si elle existe. > </p> > </body> > </subsection> > > > <subsection> > <title>Mise à jour d'un paquet sans changer la description</title> > <body> > <p> > Si vous soumettez une mise à jour de paquet, assurez-vous de bien > expliquer les changements que vous avez fait sur l'ebuild. Par exemple, > si un paquet introduit une nouvelle fonctionnalité/option et que vous > utilisez un paramètre USE, indiquez-le dans votre bogue. Ne nous obligez > pas à partir à la chasse aux modifications non expliquées. > </p> > > <p> > C'est toujours mieux de soumettre un diff de mise à jour de paquet > plutôt que de soumettre l'ebuild complet. La meilleure méthode pour le > générer est celle-ci : > </p> > > <pre caption="Créer un diff"> >$ <i>diff -u un-paquet-0.1.0.ebuild un-paquet-0.2.0.ebuild > ~/un-paquet-0.2.0.diff</i> > </pre> > </body> > </subsection> > > > <subsection> > <title>Soumettre des ebuilds non changés pour faire un remontage d'ebuild. > </title> > <body> > <p> > Si vous soumettez une nouvelle version d'un paquet dans Portage, > assurez-vous que l'ebuild existant fonctionne et que les changements > sont inclus dans le nouvel ebuild (comme par exemple de nouvelles > documentations). S'il n'y a pas de changements nécessaires à effectuer > sur l'ebuild par rapport à l'ancienne version, n'attachez pas l'ebuild. > Signalez simplement dans le rapport de bogue que vous avez copié > l'ebuild et vérifié que le paquet fonctionne et s'installe correctement. > </p> > </body> > </subsection> > </section> > > > > > <section> > <title>Commentaires et suggestions</title> > <subsection> > <body> > <p> > Merci de reporter vos commentaires, corrections et suggestions à <mail > link="liquidx@gentoo.org">Alastair Tse</mail> (en anglais). > </p> > </body> > </subsection> > </section> ></sections>
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Raw
Actions:
View
Attachments on
bug 73654
:
45425
|
45432
|
45439
|
45441
|
45453
|
45595
|
45596
|
45893
|
45894
|
45895
|
45897
|
45961
|
47829
|
47830
|
47831
|
54040
|
54041
|
54042
|
54043
|
55255
|
55256
|
55257
|
55258
|
55259
|
55261
|
55487
|
55958
|
56147
|
56557