Go to:
Gentoo Home
Documentation
Forums
Lists
Bugs
Planet
Store
Wiki
Get Gentoo!
Gentoo's Bugzilla – Attachment 55257 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]
devrel-hb-guide-ebuild-maintaining.xml
devrel-hb-guide-ebuild-maintaining.xml (text/plain), 7.61 KB, created by
Clément VARALDI
on 2005-04-04 02:32:05 UTC
(
hide
)
Description:
devrel-hb-guide-ebuild-maintaining.xml
Filename:
MIME Type:
Creator:
Clément VARALDI
Created:
2005-04-04 02:32:05 UTC
Size:
7.61 KB
patch
obsolete
><?xml version='1.0' encoding='UTF-8'?> ><!DOCTYPE sections SYSTEM "/dtd/book.dtd"> > ><!-- The content of this document is licensed under the CC-BY-SA license --> ><!-- See http://creativecommons.org/licenses/by-sa/1.0 --> > ><sections> ><section> ><title>Introduction</title> ><body> ><p> >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. ></p> ></body> ></section> > ><section> ><title>Stabiliser des ebuilds</title> ><body> ><p> >Quand vous créez un nouvel ebuild, vous ne devez inclure que les <c>KEYWORDS</c> >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 <c>USE</c> 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. ></p> > ><p> >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 <c>KEYWORDS</c> 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. ></p> > ><p> >Les ebuilds ne peuvent être stabilisés, c'est à dire placés de <c>~arch</c> à ><c>arch</c> 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 ><e>jamais</e> 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 ><mail link="sparc@gentoo.org">sparc@gentoo.org</mail> 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. ></p> > ><p> >Il vaut mieux éviter d'utiliser ><mail link="arch-maintainers@gentoo.org">arch-maintainers@gentoo.org</mail> >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. ></p> ></body> ></section> > ><section> ><title>Mettre à jour des ebuilds</title> ><body> ><p> >Les nouveaux ebuilds sont rarement proposés directement avec un mot-clef ><c>arch</c>, et même s'ils le sont, les paquets <e>doivent</e> être testés sur >toutes les architectures listées dans la variable <c>KEYWORDS</c> d'un nouvel >ebuild. ></p> > ><p> >Les exceptions à la règle qui consiste à ne jamais proposer directement un >ebuild en <c>arch</c> sont les correctifs majeurs, ou les mises à jour de >sécurité. Si la version précédente d'un ebuild contient des mots-clefs ><c>KEYWORDS</c> pour lesquels vous ne pouvez pas faire de tests, vous devez les >replacer en instable, en changeant tous les <c>arch</c> que vous ne pouvez pas >tester en <c>~arch</c>. Si vous pensez que votre paquet ne fonctionnera pas du >tout, même en le mettant comme <c>~arch</c>, 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. ></p> > ><p> >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 <c>KEYWORDS</c> >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à . ></p> > ><p> >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 <c>cvs update</c> complet et >si le problème subsiste, alors faites votre soumission avec <c>repoman -I</c> et >rapportez un nouveau bogue pour l'architecture qui pose problème, en indiquant >le problème dans votre message de soumission de CVS. ></p> > ><warn> >Lorsque vous faites votre soumission CVS, assurez-vous que vous référencez bien >tous les bogues rencontrés, ainsi que le message CVS. Ne pas le faire est >considéré comme un geste de très mauvais goût, et peut donner lieu à une >sanction disciplinaire. ></warn> ></body> ></section> > ><section> ><title>Déplacer des ebuilds</title> ><body> ><p> >Déplacer des ebuilds se fait en deux temps : ></p> > ><p> >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 <uri link="?part=1&chap=3">nouvel ebuild</uri>. ></p> > ><p> >Ensuite, vous devez changer tous les ebuilds qui dépendent (via la variable ><c>DEPEND</c>) 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 <c>cvs remove</c> dans l'ancien répertoire. ></p> > ><note> >CVS ne peut pas détruire de répertoire : il ne recréera tout simplement pas >ceux-ci si ils sont vides, dans l'hypothèse ou vous utilisez l'option <c>-P</c> >de cvs. ></note> > ><p> >Une autre méthode consiste à utiliser <c>epkgmove</c> qui fera le travail pour >vous : ></p> > ><pre> >epkgmove net-ancien/paquet net-nouveau/paquet ></pre> > ><p> >Une fois que le déplacement a été fait, ajoutez une entrée au dernier fichier >dans <path>profiles/updates/</path> dans l'arbre de Portage, avec la syntaxe >suivante : ></p> > ><pre> move net-misc/fwbuilder net-firewall/fwbuilder </pre> > ><p> >Cet exemple devrait déplacer de manière transparente ><path>net-misc/fwbuilder</path> vers <path>net-firewall</path> si les >utilisateurs l'ont installé. De cette manière, les utilisateurs pourront >désormais récupérer les mises à jour sur <path>net-firewall</path> quand elles >sont disponibles. ></p> ></body> ></section> > ><section> ><title>Enlever des ebuilds</title> ><body> ><p> >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. ></p> > ><p> >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. ></p> > ><p> >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 <c>~arch</c> en premier lieu, puis supprimez les versions >redondantes de l'ebuild. ></p> ></body> ></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