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
Ensuite, il pourrait être utile de lire quelques ebuilds qui utilisent des
eclass et comprendre comment les utiliser en lisant le
Quand vous soumettez vos ebuilds, l'en-tête doit être
Les trois premières lignes
# Copyright 1999-2004 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $
Nous n'avez pas besoin de modifier la ligne
L'oubli le plus fréquent, et de loin, est la variable IUSE. Vous devez (selon le
IUSE=""
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.
Soit dit en passant, si vous trouvez un paquet qui redéfinit une de ces variables, ne le copiez pas. Soumettez un bogue pour cet ebuild.
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 :
MY_P=${P/pyopenal/PyOpenAL}
SRC_URI="http://oomadness.tuxfamily.org/downloads/${MY_P}.tar.gz"
S=${WORKDIR}/${MY_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.
Voilà 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.
Une autre erreur commune que les utilisateurs font au moment de soumettre des
ebuilds est de proposer une licence invalide. Par exemple,
Si la licence du paquet que vous soumettez est unique et n'est pas dans
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
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 :
SLOT="0"
Merci de vérifier si la variable HOMEPAGE est correcte et pointe bien sur la bonne page si les utilisateurs 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.
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
Souvenez-vous que vous pouvez utiliser 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.
Si
Si votre paquet a une documentation, assurez-vous que vous l'installez en
utilisant
Merci de soumettre vos ebuilds correctement en suivant le
S'il vous plaît, par pitié, n'attachez pas les ebuilds en archives. De plus attachez les correctifs séparément afin qu'on puisse les examiner facilement.
Ne copiez-collez pas un ebuild dans le champ de commentaire du bugzilla.
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.
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é ou 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.
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 :
$ diff -u un-paquet-0.1.0.ebuild un-paquet-0.2.0.ebuild > ~/un-paquet-0.2.0.diff
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 des nouveaux guides et manuels). 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.
Merci de reporter vos commentaires, corrections et suggestions à