1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
|
<?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>Principes généraux</title>
<subsection>
<body>
<p>
Il existe un certain nombre de principes de développement généraux à
suivre :
</p>
<ul>
<li>
Toujours vérifier les changements avec repoman : utilisez <e>repoman
commit</e> à la place de <e>cvs commit</e>.
</li>
<li>
Si un paquet est soit cassé dans sa version actuelle, soit utilise un
processus de construction/installation vraiment horrible, jetez un coup
d'œil sur ce que les autres distributions font pour ce paquet :
<ul>
<li><uri link="http://www.debian.org/distrib/packages">Debian</uri></li>
<li>
<uri link="http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/SPECS/">Mandriva</uri>
</li>
<li><uri link="http://cvs.fedora.redhat.com/">Fedora</uri></li>
</ul>
</li>
<li>
Votre paquet, une fois terminé et démasqué, est supposé « simplement
fonctionner » pour les utilisateurs finaux. Avoir à bidouiller un
paquet installé pour qu'il marche devrait être optionnel. Du coup, vous
devez installer le paquet en question avec une configuration par défaut
raisonnable.
</li>
<li>
N'ayez pas peur de consulter notre documentation en ligne et les ebuilds
écrits et maintenus par plusieurs développeurs expérimentés. Vous pouvez
aussi contacter les développeurs expérimentés directement pour poser des
questions techniques ou concernant la politique générale.
</li>
<li>
Faites attention à ce que vous soumettez. Souvenez-vous que vos soumissions
peuvent potentiellement affecter des milliers d'utilisateurs. Si votre
soumission entraîne des problèmes dans l'arbre de Portage, ils doivent être
résolu dans un temps très court.
</li>
<li>
Tous les paquets doivent être accompagnés d'un fichier
<uri link="?part=2&chap=4">metadata.xml</uri> qui liste, entre autres,
à quel groupe de travail (ou/et quels mainteneurs individuels) est affecté
la maintenance du paquet.
</li>
</ul>
</body>
</subsection>
</section>
<section>
<title>Principes spécifiques</title>
<subsection>
<title>fPIC</title>
<body>
<p>
Sur certaines architectures, les bibliothèques partagées doivent être
construites avec l'option -fPIC. Sur x86 et d'autres, les bibliothèques
partagées peuvent parfois être construites sans -fPIC, mais cela impliquerait
du gaspillage et peut causer une perte de performance. Si vous rencontrez un
paquet qui ne construit pas ses bibliothèques avec -fPIC, corrigez le Makefile
pour construire <b>uniquement ses bibliothèques partagées</b> avec -fPIC. Plus
d'informations sur -fPIC sont disponibles sur
<uri>http://www.gentoo.org/proj/en/hardened/pic-internals.xml</uri>. En cas de
doute, veuillez demander de l'aide, par exemple sur la liste de diffusion
gentoo-dev ou le canal IRC #gentoo-dev.
</p>
</body>
</subsection>
<subsection>
<title>Perl</title>
<body>
<p>
Les nouveaux modules Perl doivent être ajoutés dans Portage uniquement si l'une
des conditions suivantes est vérifiée :
</p>
<ul>
<li>le module est nécessaire pour satisfaire une dépendance ;</li>
<li>le module ne peut pas être récupéré avec <c>g-cpan</c> ;</li>
<li>le module ajoute une fonctionnalité à un ebuild déjà existant ;</li>
<li>
le module fournit des outils, des applications ou autres fonctionnalités
(c'est-à-dire plus que ce qu'offrent leurs .PM).
</li>
</ul>
<p>
Merci de vous assurer qu'au moins une personne du groupe de travail sur Perl
approuve votre ajout.
</p>
</body>
</subsection>
</section>
<section>
<title>Politique sur les ebuilds</title>
<subsection>
<title>Politique des noms des ebuilds</title>
<body>
<p>
Le nom des fichiers ebuilds comporte quatre sous-sections logiques :
</p>
<p>
<c>pkg-ver{_suf{#}}{-r#}.ebuild</c>
</p>
<note>
Les crochets (<c>{}</c>) délimitent des champs optionnels et n'apparaissent pas
dans le nom final pour le paquet. <c>#</c> représente un entier positif
différent de zéro.
</note>
<p>
La première sous-section, <c>pkg</c>, est le nom du paquet qui doit toujours
contenir des caractères choisis parmi les minuscules, les chiffres de 0 à 9, le
tiret <c>-</c>, le soulignement <c>_</c> ou le plus <c>+</c>. Par exemple, on a
<c>util-linux</c>, <c>sysklogd</c> et <c>gtk+</c>. Nous avons quelques paquets
dans Portage qui ne suivent pas cette règle, mais <e>les vôtres</e> devront la
respecter.
</p>
<p>
La seconde sous-section <c>ver</c> est la version du paquet qui doit
normalement être la même que la version de l'archive source principale. La
version est en général constituée de deux ou trois (ou plus) nombres séparés
par un point, comme <c>1.2</c> ou <c>4.5.2</c> et peuvent comporter une lettre
seule suivant immédiatement le dernier chiffre. Par exemple, <c>1.4b</c> ou
<c>2.6h</c>. La version du paquet est liée au nom du paquet par un tiret. Par
exemple, vous aurez <c>foo-1.0</c> ou <c>bar-2.4.6</c>.
</p>
<p>
La troisième sous-section, <c>{_suf{#}}</c>, est optionnelle et peut contenir
un suffixe pré-défini parmi ceux listés (du plus vieux au plus récent)
ci-dessous :
</p>
<table>
<tr><th>Suffixe</th>
<th>Sens</th>
</tr>
<tr>
<ti><c>_alpha</c></ti>
<ti>Sortie de type Alpha</ti>
</tr>
<tr>
<ti><c>_beta</c></ti>
<ti>Sortie de type Beta</ti>
</tr>
<tr>
<ti><c>_pre</c></ti>
<ti>Pré-sortie</ti>
</tr>
<tr>
<ti><c>_rc</c></ti>
<ti>Candidat à la sortie</ti>
</tr>
<tr>
<ti>(aucun)</ti>
<ti>Sortie officielle</ti>
</tr>
<tr>
<ti><c>_p</c></ti>
<ti>Niveau de correctif (normalement suivi d'un entier)</ti>
</tr>
</table>
<p>
Tous ces suffixes doivent être suivis immédiatement d'un entier positif non nul,
comme par exemple <c>linux-2.4.0_pre10</c>. En supposant des versions
identiques, les suffixes sont ordonnés ainsi (le premier étant le plus
vieux) : <c>_alpha</c> < <c>_beta</c> < <c>_pre</c> < <c>_rc</c>
< (aucun suffixe) < <c>_p</c>.
</p>
<p>
En comparant deux suffixes identiques avec les entiers qui les suivent, celui
qui a le numéro le plus grand sera considéré comme plus récent. Par exemple,
<c>foo-1.0_alpha4</c> est plus récent que <c>foo-1.0_alpha3</c>.
</p>
<p>
La quatrième sous-section dans le nom du paquet est le numéro de révision
spécifique à Gentoo Linux (<c>{-r#}</c>). Cette sous-section comme le suffixe
est optionnelle. <c>#</c> est un entier positif non nul, ce qui donne par
exemple <c>paquet-4.5.3-r3</c>.
</p>
<p>
Le numéro de révision est indépendant de la version de l'archive source et est
utilisé pour informer les utilisateurs qu'une révision provenant de Gentoo
Linux, pour un paquet particulier, est disponible. Les sorties initiales
d'ebuilds ne doivent pas avoir de numéro de révision. Par exemple,
<c>paquet-4.5.3</c> est considéré par Portage comme ayant un numéro de révision
de zéro. Cela signifie que le décompte se fait ainsi : <c>1.0</c> (version
initiale), <c>1.0-r1</c>, <c>1.0-r2</c>, etc.
</p>
</body>
</subsection>
<subsection>
<title>Choisir la version et incrémenter une révision</title>
<body>
<p>
Le numéro de révision d'un paquet doit être augmenté par les développeurs
Gentoo quand l'ebuild a changé à un point tel que les utilisateurs peuvent
vouloir faire une mise à jour. Typiquement, c'est le cas quand des correctifs
sont fait sur un ebuild qui affectent les fichiers installés résultant, mais
l'ebuild utilise la même archive source, comme pour l'ebuild précédent. Si vous
faites un changement interne stylistique à un ebuild qui ne change aucun
fichier installé alors il n'y a pas besoin de remonter le numéro de révision.
D'ailleurs, si vous corrigez un problème de compilation sur un ebuild qui
affecte des utilisateurs, il n'y a pas besoin de remonter le numéro de version,
dans la mesure où ceux pour qui cela fonctionnait parfaitement ne verront
aucune différence en installant la nouvelle révision et ceux qui avaient un
problème n'ont pas pu installer leur paquet (puisque la compilation avait
échoué), et donc n'ont pas besoin d'avoir un nouveau numéro de révision pour
les forcer à mettre à jour. Une incrémentation de révision n'est également pas
nécessaire si une minorité d'utilisateurs seraient affectés et que le paquet
prend un temps de compilation important : faites appel à votre bon sens
pour juger de la circonstance.
</p>
<impo>
Quand vous créez une nouvelle révision pour un ebuild, assurez-vous de mettre à
jour le <path>ChangeLog</path> dans le répertoire de l'ebuild. Ne pas le faire
est considéré comme une faute importante et peut entraîner des sanctions
disciplinaires.
</impo>
<p>
Les ebuilds devraient se calquer sur la version précédente pour s'assurer que
des correctifs ne sont pas supprimés accidentellement. Les correctifs doivent
inclure des commentaires appropriés dans l'ebuild pour expliquer ce qu'ils font
et pourquoi ils sont nécessaires. Si vous n'êtes pas très familier avec les
correctifs ou que vous n'arrivez pas à déterminer si ils sont toujours
nécessaires, vous ne devez pas mettre à jour l'ebuild.
</p>
</body>
</subsection>
<subsection>
<title>Virtuals</title>
<body>
<p>
Portage supporte un concept appelé les paquets virtuels (virtual packages en
anglais). En les utilisant, vous permettez d'avoir un nom catégorie/paquet
particulier qui pointe vers un autre.
</p>
<p>
Voici un exemple d'utilisation des paquets virtuels. Imaginons que vous créez un
nouveau paquet cron appelé <c>foocron</c>. Gentoo Linux est préparé actuellement
pour que tout ce qui nécessite l'usage d'un paquet cron dépend du paquet
<c>virtual/cron</c>. Cela permet aux ebuilds de s'assurer qu'il y a plusieurs
paquets pour cron disponibles et l'utilisateur peut de manière arbitraire
choisir l'un ou l'autre, selon ses préférences. Pour ajouter
<path>foocron-1.0.ebuild</path> dans le système, vous devrez ajouter une ligne
dans l'ebuild comme suit :
</p>
<pre caption="Comment utiliser un paquet virtuel">
PROVIDE="virtual/cron"
</pre>
<p>
Maintenant, dès que <c>foocron-1.0</c> sera installé, le paquet
<c>virtual/cron</c> sera enregistré. Si vous n'aviez aucun paquet cron installé
auparavant, cela signifiera que tous les paquets <e>dépendant</e> de
<c>virtual/cron</c> auront cette dépendance satisfaite de manière complète.
Remarquez qu'il est possible de spécifier une valeur <c>PROVIDE</c> à tous les
types de paquets. Il faut juste ne pas commencer par <c>virtual</c>. Cela dit,
vous devez utiliser la catégorie <c>virtual/</c>, sauf dans le cas où vous
utilisez la fonctionnalité proposée par <c>PROVIDE</c> pour pointer vers des
paquets qui ont été renommés.
</p>
<p>
Il y a une seconde composante dans l'implémentation des paquets virtuels dans
Gentoo. Qu'arrive-t-il si aucun paquet n'est installé pour fournir
<c>virtual/cron</c> ? Comment Portage choisira-t-il le « bon »
cron à installer pour satisfaire une dépendance à <c>virtual/cron</c> ?
Portage s'en charge en utilisant un fichier de correspondance de profil
spécifique de paquets virtuels, nommé <path>virtuals</path> qui est présent
dans <path>/etc/make.profile</path>. Si vous jetez un coup d'œil dans le vôtre,
vous verrez que le contenu ressemble un peu à ceci :
</p>
<pre caption="Exemple de fichier virtuals">
virtual/lpr net-print/cups
virtual/python dev-lang/python
virtual/mta net-mail/ssmtp
</pre>
<p>
La première ligne de ce fichier indique à Portage que si un paquet dépend de
<c>virtual/lpr</c> et qu'aucun paquet fournissant cette dépendance n'est
installé et que le paquet <c>virtual/lpr</c> n'est pas disponible dans l'arbre
de Portage, alors <c>net-print/cups</c> devra être installé pour satisfaire
cette dépendance. <c>net-print/cups</c> contient une ligne
<c>PROVIDE="virtual/lpr"</c> pour que les prochaines dépendances sur
<c>virtual/lpr</c> puissent être satisfaites.
</p>
<p>
Parlons désormais de la conduite à suivre pour les développeurs. Si vous devez
ajouter un paquet <c>foocron</c>, vous devrez évidemment vous assurez que tous
les programmes qui dépendent de <c>virtual/cron</c> peuvent fonctionner
correctement avec votre paquet. Si vous voulez ajouter un paquet
<c>foobarosité</c> qui dépend de <c>virtual/cron</c>, vous devrez probablement
vous assurer que tous les paquets proposant <c>virtual/cron</c> pourront faire
fonctionner correctement votre paquet.
</p>
<p>
Avant de créer des nouveaux paquets virtuels, merci de commencer à en parler sur
la liste de diffusion interne pour les développeurs. Maintenir informés les
développeurs de nouveaux paquets virtuels est essentiel pour s'assurer de leur
utilisation uniforme.
</p>
</body>
</subsection>
<subsection>
<title>Visibilité des variables</title>
<body>
<p>
Quand un ebuild est lu par Portage, les fonctions et les variables qu'il
définit sont chargées en mémoire par l'interpréteur. Cependant, seules les
variables et les instructions qui ne font pas partie d'une fonction telle que
<c>src_compile()</c> sont exécutées lors de la compilatin de l'ebuild.
</p>
<p>
Le code compris dans des fonctions a une visibilité locale alors que tout ce
qui n'est pas dans une fonction a une visibilité globale et est exécuté à
chaque utilisation de l'ebuild.
</p>
<p>
Une application externe comme grep, sed ou awk ne devrait jamais être utilisée
dans la partie à visibilité globale pour des raisons de performance. De plus,
les fonctionnalités internes de bash telles que le remplacement de texte
doivent être utilisées au maximum. Veuillez consulter <uri
link="http://www.tldp.org/LDP/abs/html/">Advanced Bash Scripting Guide</uri>
pour les détails.
</p>
<p>
De plus, une application externe n'est pas nécessairement disponible sur le
système de l'utilisateur. En utilisant l'application externe dans une fonction
telle que <c>pkg_setup()</c>, il est possible de garantir sa présence en
l'ajoutant dans la variable <c>${DEPEND}</c> de l'ebuild.
</p>
</body>
</subsection>
<subsection>
<title>Politique des sources CVS</title>
<body>
<p>
Il y a deux moyens de construire un ebuild basé sur des sources à partir de
l'arbre de développement CVS. Le premier moyen (traditionnel) est de créer un
ebuild « instantané CVS » en créant votre propre instantané archivé de
l'arbre CVS récupéré, en mettant les sources en miroir avec les dépôts officiels
de fichiers distribués, puis vous écrivez un ebuild qui utilise spécifiquement
cette archive. Nous appellerons désormais ce type d'ebuilds « ebuilds d'instantané CVS ».
</p>
<p>
L'autre méthode pour créer un ebuild utilisant le CVS consiste à utiliser
<path>cvs.eclass</path> pour créer un ebuild CVS « live ». Un tel
ebuild récupérera de manière dynamique la dernière archive sur le dépôt CVS mise
sur le CVS, assurant ainsi que les sources sont les plus à jour possible. Nous
les nommerons les « ebuilds 'live' ».
</p>
<p>
Les paragraphes suivants détaillent la politique relative à l'utilisation des
ebuilds basés sur CVS. Remarquez qu'elle définit des règles strictes à propos de
l'ajout de ce type d'ebuilds dans l'arbre de Portage.
</p>
<p>
Les ebuilds d'instantané CVS sont largement préférés aux ebuilds
« live » utilisant <path>cvs.eclass</path>.
</p>
<p>
Les ebuilds d'instantané CVS sont autorisés si un instantané du CVS
contient les correctifs connus qui sont nécessaires au bon
fonctionnement du paquet logiciel ou si la version CVS d'un paquet
logiciel particulier est connue pour ou a été prouvée comme
fonctionnant mieux que les versions sorties sous forme de paquet.
</p>
<p>
Les ebuilds « live » sont généralement utilisés uniquement pour les
commodités des développeurs et devraient toujours être masqués avec un mot-clef
de type <c>~[arch]</c>. Il est impossible de garantir le bon fonctionnement d'un
ebuild « live » dans la mesure où l'arbre cvs du serveur peut changer
à tout moment, ce qui explique le masquage systématique.
</p>
<p>
Que ce soit pour un ebuild « live » ou un ebuild d'instantané CVS,
<b>vous, développeur serez responsable du bon fonctionnement de l'ebuild</b>. Il
est particulièrement difficile de s'en assurer pour les ebuilds
« live » pour des raisons évidentes.
</p>
<p>
Si les ebuilds (quel que soit le type) ne fonctionnent pas correctement, ils
doivent être corrigés ou supprimés de l'arbre de Portage. Si ce sont des ebuilds
« live », ils doivent être marqués en <c>~[arch]</c> à vie. Cette
exception est expliquée plus bas.
</p>
<p>
Si un ou plusieurs utilisateurs demandent un ebuild « live », vous
pouvez en ajouter un pour eux. Il doit avoir des mots-clef en <c>~[arch]</c>
afin que les autres utilisateurs ne puissent l'installer inconsciemment.
</p>
<p>
De cette manière, les utilisateurs qui le veulent peuvent l'installer, mais les
autres utilisateurs seront protégés de son installation accidentelle. Encore une
fois, cela ne s'applique que dans les situations où les utilisateurs demandent
de manière spécifique un ebuild « live ». Les ebuilds d'instantanés
CVS ne doivent être ajoutés à l'arbre de Portage que dans l'intention de les
mettre en stable ou pour proposer des fonctionnalités améliorées par rapport aux
versions habituelles de sortie d'un même logiciel.
</p>
<impo>
Les ebuilds d'instantanés CVS de sources CVS de <e>pré-sortie</e> doivent être
nommés ainsi : <path>foo-x.y_preYYYYMMDD.ebuild</path>. <c>foo</c> est le
nom du paquet, <c>x.y</c> est le numéro de version de la sortie
<e>antérieure</e>, <c>_pre</c> est utilisé tel quel et <c>YYYYMMDD</c> est une
marque indiquant le jour auquel l'instantané CVS a été fait. Utilisez cette
convention de nom pour vous assurer que la version de sortie <c>x.y.1</c> ne
sera pas considérée comme plus ancienne que l'instantané <c>x.y</c> et pour
vous assurer en même temps que la sortie officielle <c>x.y</c> sera considérée
comme plus récente que votre version d'instantané CVS. Pour les instantanés
CVS de sources CVS <e>déjà sorties</e>, utilisez le format
<path>foo-x.y_pYYYYMMDD.ebuild</path> (notez le <c>_p</c> pour
« patchlevel »). Cela assurera que votre ebuild CVS sera considéré
comme <e>plus récent</e> que la sortie <c>x.y</c> standard.
</impo>
<impo>
Actuellement, la politique des noms des ebuilds « live » est de
s'assurer que le nom du paquet se termine par <c>-cvs</c>. Dans le futur, un
suffixe de version <c>-cvs</c> pourra être ajouté aux fonctionnalités de Portage
et cette politique de nommage sera alors mise à jour.
</impo>
</body>
</subsection>
<subsection>
<title>ebuilds soumis par les utilisateurs</title>
<body>
<p>
Les ebuilds soumis par les utilisateurs ne doivent jamais être considérés comme
sûr et doivent toujours être audités et testés de manière suffisante, avant de
les soumettre au CVS. <b>Si un ebuild soumis par un utilisateur a des problèmes,
vous en serez tenu pour responsable direct.</b> En l'incorporant au CVS, vous
affirmez que cet ebuild suit tous les standards de développement de Gentoo
Linux.
</p>
<p>
Assurez-vous que l'ebuild soumis par l'utilisateur ne contient pas d'en-tête
personnalisées comme celle-ci :
</p>
<pre caption="Un en-tête personnel qui doit être déplacé dans le ChangeLog">
# Ebuild updated by: me <me@me.com>
</pre>
<p>
Ces informations doivent être ajoutées au <path>ChangeLog</path> en utilisant la
syntaxe correcte des commentaires de ChangeLog. <b>Toujours s'assurer que le
ChangeLog attribue les crédits à l'utilisateur qui a proposé l'ebuild. Ces
informations doivent apparaître dans la première entrée du ChangeLog.</b>
</p>
<p>
Assurez-vous également que tous les nouveaux ebuilds que vous soumettez au CVS
contiennent la ligne suivante :
</p>
<pre caption="En-tête d'un ebuild">
# $Header: $
</pre>
<p>
Un certain nombre d'ebuilds soumis par les utilisateurs sont basés sur des
fichiers utilisant rsync qui peuvent contenir des lignes d'en-tête incorrectes.
</p>
<p>
Encouragez les utilisateurs à proposer des « diffs » sur les ebuilds
existants s'ils proposent une mise à jour. En faisant cela, nous pouvons mieux
éviter d'avoir à réintroduire des correctifs de bogues déjà identifiés et
corrigés auparavant dans les nouveaux ebuilds. Si vous ne travaillez pas à
partir d'un diff soumis par un utilisateur, alors utilisez la commande
<c>diff</c> pour voir les changements, en gardant un œil sur tout ce qui
devrait apparaître dans le nouveau ebuild et qui était présent dans l'actuel, ou
sur tout ce qui dans le nouvel ebuild devrait être corrigé ou supprimé.
</p>
<p>
En général, laissez l'utilisateur faire ce travail pour qu'il obtienne de
lui-même un ebuild correct, sauf si vous <e>voulez</e> nettoyer l'ebuild sans
le consulter. Toutefois, il est toujours meilleur de laisser l'utilisateur
faire ce travail pour qu'il puisse apprendre de ses erreurs et soumettre des
ebuilds plus propres dans le futur. N'oubliez pas de toujours remercier pour
toute soumission, même si elle n'est pas vraiment bonne. Soyez poli, mais
honnête. Si un ebuild n'est pas utilisable, on peut dire à l'utilisateur d'une
manière non insultante que leur ebuild ne convient pas, sans porter atteinte à
leur capacité actuelle à écrire un ebuild. Souvenez-vous que les utilisateurs
qui proposent des ebuilds cassés peuvent être dans le futur des membres
productifs et expérimentés pour notre projet dans le futur, c'est-à-dire s'ils
reçoivent suffisamment d'encouragements et de support et continuent à
s'améliorer.
</p>
</body>
</subsection>
</section>
<section>
<title>Politique QA</title>
<subsection>
<title>Politique de sortie de Portage et baselayout</title>
<body>
<p>
Seul les membres de l'équipe Portage peuvent sortir des nouvelles versions de
Portage. <b>Personne d'autre</b> n'est autorisé à sortie de nouvelle version
de Portage.
</p>
<p>
Seul les membres de l'équipe baselayout peuvent sortir des nouvelles versions.
<b>Personne d'autre</b> n'est autorisé à sortie de nouvelle version de
<c>sys-apps/baselayout</c>.
</p>
</body>
</subsection>
<subsection>
<title>Paquets masqués</title>
<body>
<p>
<path>/usr/portage/profiles/package.mask</path> contient une liste des paquets
qui ne doivent pas être installés par les utilisateurs et des commentaires
détaillant la raison du masquage. Package.mask est utilisé pour empêcher
d'installer des paquets qui sont cassés, qui cassent d'autres éléments ou qui
ont mal été testés avant d'avoir un mot-clef en ~ARCH dans l'arbre. Quand vous
ajoutez un ebuild à package.mask, toujours soumettre package.mask avant de
soumettre l'ebuild masqué. Cela empêche l'ebuild d'être récupéré par des
utilisateurs avant que la mise à jour de package.mask ait été faite.
</p>
<p>
Une attention particulière doit être apportée quand un paquet est enlevé de
<path>package.mask</path>. Gardez à l'esprit que si un ebuild est dans
<path>package.mask</path>, c'est pour une bonne raison. Si vous n'avez pas
masqué vous-même l'ebuild, toujours contacter le développeur cité dans les
commentaires de <path>package.mask</path> avant de prendre une initiative. De
plus, si le paquet masqué est un paquet core, une dépendance d'un paquet core,
ou si démasquer le paquet peut avoir des effets secondaires, le changement
doit être fait après discussion interne sur la liste de diffusion des
développeurs.
</p>
</body>
</subsection>
<subsection>
<title>~ARCH dans la variable KEYWORDS</title>
<body>
<p>
L'objectif de ~arch est de permettre de tester des nouveaux paquets ajoutés dans
Portage.
</p>
<p>
Il y a une différence entre utiliser <path>package.mask</path> et ~arch pour
les ebuilds. L'utilisation de ~arch dénote que l'<b>ebuild</b> a besoin d'être
testé. L'utilisation de <path>package.mask</path> dénote que l'application ou
la bibliothèque est clairement instable. Par exemple si <c>gimp-1.2.0</c> est
une version stable des développeurs de Gimp et qu'un nouveau correctif est
disponible en tant que 1.2.1, alors le développeur doit marquer l'ebuild comme
~arch pour qu'il soit testé dans Portage parce que la version est considérée
comme stable par Gimp. Un autre exemple, si Gimp décide de proposer une version
de développement ou instable marquée 1.3.0, alors les ebuilds résultant doivent
être mis dans <path>package.mask</path> car le logiciel lui-même est qualifié
de logiciel en développement et qu'il n'est pas recommandé par les développeurs
à la distribution.
</p>
<p>
Tous les nouveaux paquets qui entrent dans Portage doivent être marqués d'un
~arch pour les architectures sur lesquelles cette version est connue comme
fonctionnant. Le développeur qui soumet l'ebuild doit vérifier qu'il est en
état de fonctionnement et que la variable KEYWORDS est correcte.
</p>
</body>
</subsection>
<subsection>
<title>Déplacer des versions de paquet de ~ARCH à ARCH</title>
<body>
<p>
Quand une version de paquet a été testée pendant une période de temps
suffisante et considérée comme stable, et quand le mainteneur Gentoo de ce
paquet est sûr que la mise à jour n'entraînera pas de problèmes sur une machine
d'utilisateur normal, alors cette version peut passer de ~ARCH à ARCH. Une
indication pour savoir si un paquet est stable peut être de constater qu'aucun
rapport de bogue sur un mois après l'introduction du nouveau paquet n'a été
effectué pour cette version.
</p>
<p>
C'est au mainteneur du paquet de décider quelles versions sont stables ou si les
versions de développement doivent être mises dans <path>package.mask</path> ou
laissés en ~arch.
</p>
<p>
Vous devez également vous assurer que toutes les dépendances pour cette version
de paquet sont également en ARCH.
</p>
<warn>
L'étape ~ARCH peut être ignorée <e>uniquement si</e> la version en
question du paquet contient un correctif de sécurité ou est nécessaire
pour corriger un bogue important dans le système Gentoo.
</warn>
</body>
</subsection>
</section>
<section>
<title>Variables</title>
<subsection>
<title>Variables requises</title>
<body>
<p>
La politique de Gentoo Linux requiert que tous les ebuilds contiennent les
variables <c>KEYWORDS</c>, <c>LICENSE</c> et <c>SLOT</c>. <c>HOMEPAGE</c>,
<c>SRC_URI</c> et <c>DESCRIPTION</c> doivent être ajoutés sauf dans certains
cas très spéciaux. <c>DEPEND</c> (et si besoin est, <c>RDEPEND</c>) doivent
être inclus si votre paquet a respectivement des dépendances à la compilation
ou à l'exécution.
</p>
</body>
</subsection>
<subsection>
<title>DEPEND et RDEPEND</title>
<body>
<p>
Utilisez <c>DEPEND</c> pour définir les dépendances nécessaires à la
compilation d'un paquet particulier et <c>RDEPEND</c> pour les dépendances
nécessaires à <e>l'exécution</e> d'un paquet particulier. Vous n'avez besoin de
spécifier explicitement <c>RDEPEND</c> que si les dépendances de lancement de
l'ebuild sont différentes de celles spécifiées dans <c>DEPEND</c> ; Si
<c>RDEPEND</c> n'est pas spécifié, la valeur par défaut sera celle de
<c>DEPEND</c>. <b>Ne jamais</b> initialiser <c>RDEPEND</c> à <c>DEPEND</c> par
vous-même dans un ebuild.
</p>
<pre caption="variable RDEPEND mauvaise et correcte">
# Acceptable :
RDEPEND="${DEPEND}
net-ftp/curl
virtual/libc"
# Non acceptable :
RDEPEND="${DEPEND}"
</pre>
<p>
Il est également important de remarquer que seules les dépendances de
<c>RDEPEND</c> sont satisfaites quand on installe un paquet binaire
<c>.tbz2</c>. Utilisez ces informations pour vous aider à choisir les bonnes
dépendances <c>RDEPEND</c>. Sinon, <c>RDEPEND</c> aura les dépendances de
<c>DEPEND</c>.
</p>
<p>
Un paquet doit dépendre de la version la plus ancienne qui satisfait la
dépendance. Si le paquet fonctionne avec <c>libfoo-1.2.x</c>, ne le faites pas
dépendre de <c>libfoo-2.x</c> juste parce que c'est la version que vous avez
d'installée.
</p>
<p>
En général, les paquets doivent dépendre de <c>=libfoo-1.2*</c> à la place de
<c>>=libfoo-1.2</c>. Sinon, votre paquet va commencer à créer des problèmes
quand le paquet <c>libfoo-2.0</c> sera disponible.
</p>
<p>
Dépendre d'un paquet virtuel comme <c>virtual/foo</c> ne fonctionne que si les
différents paquets proposant de valider la dépendance <c>virtual/foo</c> ont
des interfaces identiques. Considérons par exemple <c>virtual/jdk-1.3</c>.
Certains paquets ne fonctionnent pas avec <c>ibm-jdk-1.3</c> alors qu'ils
fonctionneront bien avec <c>sun-jdk-1.3</c>. Pour cette raison, assurez-vous
que votre paquet a été testé avec tous les paquets ayant une correspondance
virtuelle avant de le démasquer. Il peut arriver que la dépendance soit
correcte seulement pour un certain nombre d'entre eux, mais qu'elle ne soit pas
correcte pour le paquet virtuel lui-même.
</p>
</body>
</subsection>
</section>
</sections>
|
GitWeb