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

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és 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.

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. 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.

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.

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.

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.