Go to:
Gentoo Home
Documentation
Forums
Lists
Bugs
Planet
Store
Wiki
Get Gentoo!
Gentoo's Bugzilla – Attachment 45893 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]
hb-guide-ebuild-maintaining.xml
devrel-hb-guide-ebuild-maintaining.xml (text/plain), 8.87 KB, created by
Clément VARALDI
on 2004-12-13 03:32:35 UTC
(
hide
)
Description:
hb-guide-ebuild-maintaining.xml
Filename:
MIME Type:
Creator:
Clément VARALDI
Created:
2004-12-13 03:32:35 UTC
Size:
8.87 KB
patch
obsolete
><!-- Le contenu de ce document est sous licence CC-BY-SA --> <!-- Voir http://creativecommons.org/licenses/by-sa/1.0 --> > <!-- $Header: /var/www/www.gentoo.org/raw_cvs/gentoo/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild-maintaining.xml,v1.1 2004/08/24 21:07:26 plasmaroo Exp $ --> > ><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 confirme qu'il fonctionne effectivement bien > comme attendu de lui, 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 comme s'assurer que l'application se lance bien, sans > erreurs, doit toujours être effectué. > </p> > > <p> > Si vous ajoutez un ebuild proposé par un utilisateur, faites comme si > celui-ci n'avait pas fait de vérification sur diverses > architectures : il arrive souvent que les <c>KEYWORDS</c> ont été > récupérés sur d'autres paquets, ou générez à 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 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 > correspondance, 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érez 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 en CC 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 reportez un nouveau bogue pour l'architecture > pour laquelle le paquet est cassé, en le notant 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 vide, 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 ils sont disponibles. > </p> > </body> > </section> > > > <section> > <title>Enlever des ebuilds</title> > <body> > <p> > Quand vous supprimez un ebuild assurez-vous qu'aucune dépendances 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