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

5. Guide de maintenance des ebuilds

• Introduction
• Ajouter un ebuild
• Stabiliser des ebuilds
• Règles pour stabiliser un ebuild
• Mettre à jour des ebuilds
• Déplacer des ebuilds
• Enlever des ebuilds
• Collision de fichiers

5.a. Introduction

Ce guide a pour objectif de présenter les procédures courantes de maintenance des ebuilds ainsi que les procédures de maintenance plus rares avec lesquelles les développeurs ne sont pas forcément très familiers.

5.b. Ajouter un ebuild

Quand vous créez un nouvel ebuild, vous ne devez inclure que les KEYWORDS pour les architectures qui ont été effectivement testées pour cet ebuild, ce qui confirmera qu'il fonctionne effectivement bien comme nous l'espérons et que les paramètres USE sont bien respectés dans le paquet résultant de l'installation à partir de l'ebuild. Dans la mesure du possible, vous devez également préciser les bibliothèques ou applications qui ont été effectivement utilisées lors des tests dans la mesure où vous serez responsable des problèmes inhérents à votre paquet pour les architectures présentées. Un minimum de vérifications doit être effectué comme s'assurer que l'application se lance bien et sans erreurs.

Si vous ajoutez un ebuild proposé par un utilisateur, faites comme si celui-ci n'avait pas fait de vérification sur les différentes architectures : il arrive souvent que les KEYWORDS aient été récupérés sur d'autres paquets ou générés à partir de la documentation proposée avec les sources des paquets. Cela ne signifie en rien que le paquet fonctionnera effectivement sur ces mêmes architectures.

5.c. Stabiliser des ebuilds

Les ebuilds ne peuvent être stabilisés, c'est-à-dire placés de ~arch à arch que si le mainteneur de l'ebuild ou un mainteneur de l'architecture concernée considère l'ebuild comme effectivement stable. Le mainteneur du paquet doit toujours être contacté juste pour le cas où il y ait une raison pour que l'ebuild ne soit pas stabilisé pour cette architecture. Si vous faites partie d'une équipe qui gère une architecture, alors vous pouvez marquer un ebuild pour celle-ci. Si l'architecture qui vous intéresse n'est pas indiquée, veuillez consulter le responsable.

Vous ne devez jamais stabiliser des paquets sur des architectures pour lesquelles vous ne pouvez faire aucun test. À la place, vous devez remplir un formulaire de bogue destiné à l'équipe de l'architecture correspondante, comme par exemple sparc@gentoo.org pour que l'équipe s'occupant de l'architecture SPARC stabilise si possible l'ebuild. Sinon, vous pouvez également chercher des développeurs Gentoo sur IRC qui pourront vous aider dans votre demande.

Il vaut mieux éviter d'utiliser arch-maintainers@gentoo.org et préférer ajouter les équipes d'architecture dans le champ CC d'un rapport de bogue à la place. De cette manière les équipes peuvent s'enlever de la liste une fois qu'ils ont effectué le travail, ce qui permet de savoir de manière précise quelles sont les équipes qui doivent toujours stabiliser le paquet.

5.d. Règles pour stabiliser un ebuild

SPARC : vous devez avoir l'autorisation du responsable (actuellement Weeve). Vous devriez être inscrit dans l'alias sparc pour pouvoir suivre le processus d'assurance-qualité, mais d'autres dispositions peuvent être prises si vous ne travaillez que sur un petit nombre d'ebuilds.

ALPHA : les responsables de paquets peuvent marquer leurs paquets stables pour Alpha, mais il leur est demandé d'en informer l'équipe Alpha pour effectuer des tests supplémentaires et ainsi permettre de corriger les éventuelles erreurs.

MIPS : vous devez avoir l'autorisation d'un développeur MIPS expérimenté. À cause de la grande variété de matériel, vous devez être inscrit dans l'alias mips et avoir accès à des machines MIPS.

5.e. Mettre à jour des ebuilds

Les nouveaux ebuilds sont rarement proposés directement avec un mot-clef arch et, même s'ils le sont, les paquets doivent être testés sur toutes les architectures listées dans la variable KEYWORDS d'un nouvel ebuild.

Les exceptions à la règle qui consiste à ne jamais proposer directement un ebuild en arch sont les correctifs majeurs ou les mises à jour de sécurité. Si la version précédente d'un ebuild contient des mots-clefs KEYWORDS pour lesquels vous ne pouvez pas faire de tests, vous devez les replacer en instable en changeant tous les arch que vous ne pouvez pas tester en ~arch. Si vous pensez que votre paquet ne fonctionnera pas du tout même en le mettant comme ~arch, alors il est préférable d'enlever le mot-clef et de faire une demande de tests à l'équipe concernée : si vous êtes amenés à faire ce genre de chose, vous devez faire un rapport de bogue à destination de l'équipe en question.

Si une nouvelle version introduit de nouvelles dépendances qui ne sont pas disponibles sur certaines architectures, vous devez rapporter un bogue ou demander de l'aide sur IRC avant de mettre à jour le paquet. Si vous avez réellement besoin d'ajouter cet ebuild et que c'est urgent, par exemple, pour une correction de sécurité, alors vous devez enlever tous les KEYWORDS qui posent problème et mettre en CC les architectures en question dans le bogue rapporté. Vous devez pour cela ouvrir un nouveau bogue pour l'architecture en question, sauf si celui-ci existe déjà.

S'il n'y a pas de nouvelles dépendances, n'enlevez pas de mots-clefs. Si la soumission échoue avec repoman, essayez de faire un cvs update complet et si le problème subsiste, alors faites votre soumission avec repoman -I et rapportez un nouveau bogue pour l'architecture qui pose problème en indiquant le problème dans votre message de soumission de CVS.

5.f. Déplacer des ebuilds

Déplacer des ebuilds se fait en deux temps :

Tout d'abord, vous devez déplacer l'ebuild dans le CVS. Pour faire cela, vous devrez copier l'ebuild à sa nouvelle position et soumettre celui-ci comme si vous soumettiez un nouvel ebuild.

Ensuite, vous devez changer tous les ebuilds qui dépendent (via la variable DEPEND) de l'ancien ebuild pour qu'ils pointent vers le nouveau. Alors seulement, vous pourrez enlever l'ensemble des fichiers relatifs à l'ancien ebuild avec cvs remove dans l'ancien répertoire.

Une autre méthode consiste à utiliser epkgmove qui fera le travail pour vous :

# epkgmove net-ancien/paquet net-nouveau/paquet

Une fois que le déplacement a été fait, ajoutez une entrée au dernier fichier dans profiles/updates/ dans l'arbre de Portage, avec la syntaxe suivante :

move net-misc/fwbuilder net-firewall/fwbuilder

Cet exemple devrait déplacer de manière transparente net-misc/fwbuilder vers net-firewall si les utilisateurs l'ont installé. De cette manière, les utilisateurs pourront désormais récupérer les mises à jour sur net-firewall quand elles sont disponibles.

5.g. Enlever des ebuilds

Quand vous supprimez un ebuild, assurez-vous qu'aucune dépendance dans Portage ne se casse à cause de la suppression. De plus, votre message de soumission au CVS devra expliquer clairement pourquoi l'ebuild a été supprimé du CVS.

Si vous avez besoin d'enlever des ebuilds, assurez-vous de ne pas enlever de manière accidentelle des ebuilds nouveaux ou stables uniquement pour certaines architectures. Si vous voulez faire une nouvelle version marquée comme stable, merci de faire un rapport de bogue ou d'en discuter sur IRC.

Vous devez également éviter de diminuer les versions stables des paquets quand vous supprimez des ebuilds. À la place, le mieux est de prendre la plus récente version marquée comme ~arch en premier lieu, puis supprimez les versions redondantes de l'ebuild.

5.h. Collision de fichiers

Si vous trouvez des paquets qui essaient d'installer des fichiers déjà installés par un autre paquet (par exemple en utilisant FEATURES=collision-protect), vous devez résoudre ce problème avant de soumettre l'ebuild. Si l'ebuild est déjà dans l'arbre Portage, remplissez un rapport de bogue sur ce paquet (voir plus bas pour une liste d'exceptions). La raison pour laquelle les collisions de fichiers sont critiques est que si « foo » installe le fichier /usr/bin/exemple et « bar » essaie d'écrire un autre fichier par dessus, puis plus tard « bar » est désinstallé, Portage va supprimer /usr/bin/exemple, avec de grandes chances pour que cela empêche « foo » de fonctionner.

La solution la plus évidente est d'ajouter une dépendance bloquante sur les deux paquets qui veulent installer le même fichier, afin qu'ils ne puissent pas être installés tous les deux en même temps. Mais, à moins qu'il n'y ait d'autres raisons pour que ces paquets se bloquent entre eux, vous devriez éviter ce genre de manipulation et essayer plutôt de modifier les paquets en utilisant l'une des méthodes suivantes (liste non exhaustive) :

• Modifiez le (R)DEPEND de « foo » pour que ce dernier dépende de « bar ».
• Enlevez les fichiers qui engendrent la collision de « foo » dans src_install ou pkg_preinst.
• Déplacez les fichiers en conflit dans un nouveau sous-paquet et faites en sorte que « foo » et « bar » dépendent ((R)DEPEND) tous deux de ce paquet.
• Changez le répertoire dans lequel « foo » ou « bar » installent les fichiers en conflit.

Dans certains cas, les collisions de fichiers ne peuvent pas être résolues ou ne sont pas critiques. Les exceptions connues actuellement sont les pages de manuel des modules Perl (qui écrasent celles de Perl lui-même), ainsi que les fichiers protégés par CONFIG_PROTECT (les collisions sur ces fichiers devraient tout de même être corrigées, mais elles sont moins graves puisque Portage n'écrasera aucun de ces fichiers).

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

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