[ << ] [ < ] [ Sommaire ] [ > ] [ >> ]

3. Erreurs classiques dans les ebuilds

• Erreurs communes dans les ebuilds
• Erreurs communes de soumission d'ebuilds
• Commentaires et suggestions

3.a. Erreurs communes dans les ebuilds

Introduction

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 Politique de développement des ebuilds pour Gentoo et le Guide des ebuilds pour Gentoo. 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.

Ensuite, il pourrait être utile de lire quelques ebuilds qui utilisent des eclass et comprendre comment les utiliser en lisant le Guide eclass. Finalement, vous devez lire le Guide de contribution d'ebuilds soigneusement avant de soumettre vos ebuilds.

En-tête cassé/invalide/manquant

Quand vous soumettez vos ebuilds, l'en-tête doit être exactement le même que celui de /usr/portage/skel.ebuild. Il est important de ne pas le modifier et de s'assurer que la ligne $Header: $ est intacte.

Les trois premières lignes doivent ressembler à celles-ci :

# 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 $Header: $ même si vous soumettez un ebuild pour une nouvelle version ou une correction. La ligne doit être présente. Quand on enregistre l'ebuild dans le CVS, cet en-tête sera modifié avec la version appropriée et la date. Il n'y a donc pas besoin de la modifier manuellement.

Non déclaration de IUSE

L'oubli le plus fréquent, et de loin, est la variable IUSE. Vous devez (selon le Guide des ebuilds pour Gentoo) inclure la variable IUSE, même si aucun paramètre USE n'est utilisé. S'il n'y en a aucun de supporté, ajoutez simplement la ligne suivante :

IUSE=""

P, PV, PN, PF redéfinis

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 « expansions de 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.

Inclure les numéros de version dans SRC_URI et S

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 facilite la maintenance de l'ebuild. 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}

DEPEND comporte des erreurs de syntaxe

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.

• Toujours inclure la catégorie
  Par exemple, utilisez >=x11-libs/gtk+-2 et non >=gtk+-2.
• N'utilisez pas d'astérisque (*) pour les dépendances en >=.
  Par exemple, on doit avoir >=x11-libs/gtk+-2 à la place de >=x11-libs/gtk+-2*.
• Spécifique à GTK : toujours utiliser =x11-libs/gtk+-1.2* pour les applications GTK+1.
• Ne jamais dépendre d'un paquet meta
  Du coup, ne pas dépendre de gnome-base/gnome, mais toujours d'une bibliothèque spécifique, comme libgnome.
• Une dépendance par ligne.
  Ne mettez pas plusieurs dépendances sur la même ligne. Cela rend le code plus difficile à lire et à suivre.

DEPEND est incomplet

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.

• Lisez les fichiers configure.in ou configure.ac
  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.
• Regardez les fichiers .spec inclus
  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 complète des dépendances.
• Lire le site Internet de l'application/la bibliothèque
  Regardez sur le site de l'application pour repérer les dépendances qu'ils suggèrent comme étant nécessaires.
• Lisez les fichiers README et INSTALL du paquet
  Ils contiennent souvent des informations utiles sur comment construire et installer les paquets.
• Souvenez-vous des dépendances non-binaires comme pkg-config, les programmes de génération de documentation, etc.
  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.

LICENSE invalide

Une autre erreur commune que les utilisateurs font au moment de soumettre des ebuilds est de proposer une licence invalide. Par exemple, GPL n'est pas une licence valide. Vous devez spécifier GPL-1 ou GPL-2. Même chose pour la LGPL. Assurez-vous que la licence que vous utilisez dans le champ LICENSE est une licence qui existe dans /usr/portage/licenses. Pour connaître la licence, vous pouvez lire le fichier COPYING dans l'archive source, il contient souvent la licence. Si la licence n'est pas spécifiée, utilisez la GPL-1 ou GPL-2 : on est souvent en présence de la GPL-2.

Si la licence du paquet que vous soumettez est unique et n'est pas dans /usr/portage/licenses/, alors vous devez soumettre une nouvelle licence dans un fichier séparé.

Architectures non testées dans les KEYWORDS

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 incrémentez une version, toutes les architectures stables sont marquées d'un ~.

SLOT manquant

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"

DESCRIPTION et HOMEPAGE incorrectes

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.

Utilisation incorrecte des espaces au lieu de tabulations

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 s'il vous plaît, utilisez des tabulations.

Espaces en fin de lignes

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.

Ajouter des S=${WORKDIR}/${P} redondants

Si S=${WORKDIR}/${P}, 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 ${WORKDIR}/${P}.

Documentation manquante

Si votre paquet a une documentation, assurez-vous que vous l'installez en utilisant dodoc ou en les mettant dans /usr/share/doc/${PF}. N'oubliez pas de vérifier s'il y a des erreurs quand vous lancez dodoc ou doins.

3.b. Erreurs communes de soumission d'ebuilds

Introduction

Merci de soumettre vos ebuilds correctement en suivant le Guide contribuer pour les ebuilds sur la page de documentation Gentoo.

Archiver un ebuild

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.

Proposer des ebuilds

Ne copiez-collez pas un ebuild dans le champ de commentaire du bugzilla.

Aucune description sur ce qu'est le paquet

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.

Mise à jour d'un paquet sans changer le changelog

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

Soumettre des ebuilds non changés pour incrémenter la version d'un ebuild.

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.

3.c. Commentaires et suggestions

Merci d'envoyer vos commentaires, corrections et suggestions à Alastair Tse (en anglais).

[ << ] [ < ] [ Sommaire ] [ > ] [ >> ]

Ce document est protégé par la licence Creative Commons : Paternité - Partage des Conditions Initiales à l'Identique 2.5.