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
|
<!--
The FreeBSD Documentation Project
The FreeBSD French Documentation Project
$FreeBSD$
Original revision: 1.7
-->
<chapter id="policies">
<title>Gestion de l'arborescence des sources</title>
<para><emphasis>Contribution de &a.phk;.</emphasis></para>
&trans.a.haby;
<para>Ce document décrit différents principes et recommandations
en vigueur pour la gestion de l'arborescence des sources de FreeBSD.</para>
<sect1 id="policies-maintainer">
<title><makevar>MAINTAINER</makevar> dans les
<filename>Makefile</filename>s</title>
<para>Juin 1996.</para>
<para>Si un sous-ensemble particulier de la distribution de FreeBSD est
maintenu par une personne ou un groupe de personne, ils peuvent le
faire savoir à l'extérieur en ajoutant une
ligne :</para>
<programlisting>
MAINTAINER= email-addresses
</programlisting>
<para>aux <filename>Makefile</filename>s correspondant à cette partie
de l'arborescence.</para>
<para>Cela signifie que :</para>
<para>La personne détient et assume la responsabilité de ce
code. Ce qui veut dire qu'il est responsable de la corrections des bogues
et des réponses aux rapports d'anomalie se rapportant à ce
code, et, dans le cas de logiciels d'origine extérieure, du suivi
des nouvelles versions, selon les besoins.</para>
<para>Les modifications dans les répertoires pour lesquels il existe
un responsable de la maintenance devront être transmises à ce
responsable pour qu'il les passe en revue. Il n'est admis
d'intégrer de modifications sans passer par cette étape
qu'aux seuls cas où le responsable ne répond pas dans un
délai acceptable, et après plusieurs courriers
électroniques. Il est cependant suggeré d'insister et de
faire en sorte que les modifications soient revues par quelqu'un d'autre,
si c'est possible.</para>
<para>Il n'est bien sûr pas acceptable d'ajouter une personne ou un
groupe de personnes comme responsable de la maintenance, s'ils ne sont pas
d'accord pour assumer cette obligation. D'un autre côté, il
n'est pas nécessaire que ce soit une personne ayant les droits
d'écriture dans
l'arborescence - “<foreignphrase>committer</foreignphrase>” - et
ce peut sans problème être un groupe de personnes.</para>
</sect1>
<sect1>
<title>Logiciels de provenance
extérieure - “contribués”</title>
<para><emphasis>Contribution de &a.phk; et &a.obrien;.</emphasis></para>
<para>Juin 1996.</para>
<para>Certaines parties de la distribution de FreeBSD consistent en
logiciels qui sont activement maintenus extérieurement au projet
FreeBSD. Pour des raisons historiques, on appelle cela des logiciels
<emphasis>contribués</emphasis>. Perl, gcc et patch en sont des
exemples.</para>
<para>Ces deux dernières années, nous avons employé
différentes méthodes pour gérer ce type de logiciels, elles ont toutes leurs avantages et leurs inconvénients. Aucune ne
s'est avérée incontestablement meilleure.</para>
<para>De ce fait, après discussion, une de ces méthode a
été retenue comme méthode “officielle” et
devra être utilisée pour les prochaines adjonctions de
logiciels de ce type. De plus, il est fortement suggéré que
les logiciels déjà intégrés convergent avec le
temps vers cette méthode, parce qu'elle présente des
avantages significatifs sur l'ancienne méthode, dont la
possibilité pour chacun d'obtenir facilement des
<filename>diff</filename>s avec les versions “officielles” du
source (même sans accès cvs). Cela rendra beaucoup plus
facile la communication en retour des modifications aux
développeurs d'origine des logiciels.</para>
<para>Au final, néanmoins, tout dépend des personnes qui ont
en charge la maintenance. Si ce modèle est particulièrement
mal adapté au paquetage concerné, il peut y avoir des
exceptions à ces règles, à condition expresse
d'approbation par l'équipe de base et de consensus
général des autres développeurs, la
maintenabilité ultérieure du paquetage étant le
principal critère de décision.</para>
<note>
<para>Du fait de limitations malheureuses de conception du format des
fichiers RCS et de l'utilisation par CVS des branches d'origine, les
modifications mineures, triviales et/ou cosmétiques sont
<emphasis>fortement découragées</emphasis> sur les
fichiers qui sont toujours gérés sur la branche
d'origine. Les fichiers de “localisation” sont explicitement
inclus ici dans la catégorie “cosmétique” et
ne doivent pas avoir de numéros de révision
<literal>1.1.x.x</literal>. La modification d'un seul caractère
peut congestionner de façon relativement dramatique l'ensemble
des archives.</para>
</note>
<para>Nous utiliserons le langage de programmation
<application>Tcl</application> pour illustrer la façon dont ce
modèle s'applique :</para>
<para><filename>src/contrib/tcl</filename> contient le source tel qu'il est
distribué par les gens qui maintiennent ce paquetage. Les parties
qui ne s'appliquent pas du tout à FreeBSD peuvent être
supprimées. Dans le cas de Tcl, les sous-répertoires
<filename>mac</filename>, <filename>win</filename> et
<filename>compat</filename> ont été éliminés
avant l'importation.</para>
<para><filename>src/lib/libtcl</filename> ne contient qu'un
<filename>Makefile</filename> de “style bmake” qui utilise les
règles standard de <filename>bsd.lib.mk</filename> pour
générer la bibliothèque et installer la
documentation.</para>
<para><filename>src/usr.bin/tclsh</filename> ne contient qu'un
<filename>Makefile</filename> de “style bmake” qui
génère et installe le programme
<command>tclsh</command> et les pages de manuel correspondantes en
utilisant les règles standard de
<filename>bsd.prog.mk</filename>.</para>
<para><filename>src/tools/tools/tcl_bmake</filename> contient une paire de
procédures qui peuvent être utiles quand il faut mettre
à jour le logiciel Tcl. Elles ne font pas partie du logiciel
compilé et installé.</para>
<para>L'important ici est que le répertoire
<filename>src/contrib/tcl</filename> est créé en respectant
les règles suivantes : il est supposé contenir les
sources tels que distribués (sur une branche CVS d'origine ad hoc
et sans extensions RCS des mots-clés) avec aussi peu de
modifications spécifiques à FreeBSD que possible. L'outil
d'“importation facile” sur <hostid>freefall</hostid>
aidera à importer le logiciel, mais, au moindre doute, il est
impératif de se renseigner auparavant et de ne pas aller à
l'aveuglette en espérant que “cela marchera”. CVS ne
pardonne pas les erreurs d'importation et il n'est pas trivial de
récupérer d'erreurs majeures.</para>
<para>Du fait des limitations conceptuelles déjà
mentionnées des branches d'origine de CVS, les correctifs
“officiels” du distributeur doivent être
appliqués aux sources d'origine et le résultat
réimporté dans la branche principale. Ces correctifs
officiels ne doivent jamais être appliqués aux versions
extraites pour FreeBSD et “soumis” ensuite, parce que cela
détruit la cohérence de la branche d'origine et rend
l'importation des versions ultérieures assez difficile, parce qu'il
y aura des conflits.</para>
<para>Comme de nombreux paquetages contiennent des fichiers
dédiés à la compatibilité avec d'autres
architectures et environnements que FreeBSD, il est admissible de
supprimer les parties de la distribution qui ne concernent pas FreeBSD
pour gagner de la place. Les fichiers qui contiennent les notices de
<foreignphrase>copyright</foreignphrase> et des informations du type
“notes de version” qui s'appliquent aux autres fichiers ne
doivent <emphasis>pas</emphasis> être supprimés.</para>
<para>Si cela s'avère plus facile, les <filename>Makefile</filename>s
<command>bmake</command> de l'arborescence de la distribution peuvent
être générés avec un utilitaire, ce qui peut
le cas échéant faciliter les montées de version. Si
tel est le cas, veillez à administrer ces utilitaires (si besoin
est) dans le répertoire <filename>src/tools</filename> en
même temps que le logiciel lui-même, de sorte qu'ils soient
disponibles pour les personnes qui assureront par la suite la
maintenance.</para>
<para>Dans le répertoire <filename>src/contrib/tcl</filename>, il
faut ajouter un fichier appelé <filename>FREEBSD-upgrade</filename> qui mentionne des choses telles que :</para>
<itemizedlist>
<listitem>
<para>Quels fichiers ont été laissés de
côté,</para>
</listitem>
<listitem>
<para>Où a été obtenue la distribution originale
et/ou quel est le site principal officiel,</para>
</listitem>
<listitem>
<para>Où réadresser les correctifs à l'auteur
original,</para>
</listitem>
<listitem>
<para>Eventuellement un résumé des modifications
apportées propres à FreeBSD.</para>
</listitem>
</itemizedlist>
<para>Cependant, n'importez pas <filename>FREEBSD-upgrade</filename> en
même temps que le source du logiciel. Vous devriez plutôt
effectuer un <command>cvs add FREEBSD-upgrade ; cvs ci</command>
après le premier <command>import</command>. Voici par exemple
ce que cela donne pour <filename>src/contrib/cpio</filename>
<footnote><para>Traduction :</para>
<programlisting>
Ce répertoire contient les sources d'origine non modifiés sur la
branche “d'origine”. N'essayez en aucun cas de mettre à jour
les fichiers de ce répertoire via des correctifs et un “commit”
cvs. Les nouvelles versions ou les versions officiellement
rectifiées doivent être importées. N'oubliez pas d'importer
avec l'option “-ko” pour ne pas écraser les IDentifiants
RCS d'origine.
A l'importation de GNU cpio 2.4.2, les fichiers suivants ont été
éliminés :
INSTALL cpio.info mkdir.c
Makefile.in cpio.texi mkinstalldirs
Pour passer à une nouvelle version de cpio, quand elle sera disponible :
1. Décompactez la nouvelle version dans un sous-répertoire vide
[Ne modifiez en AUCUN cas les fichiers.]
2. Supprimez les fichiers listés ci-dessus et tous autres fichiers
qui ne s'appliquent pas à FreeBSD.
3. Utilisez la commande :
cvs import -ko -m 'Virgin import of GNU cpio v<version>' \
src/contrib/cpio GNU cpio_<version>
Voici par example comment j'ai importé la version 2.4.2 de cpio :
cvs import -ko -m 'Virgin import of GNU v2.4.2' \
src/contrib/cpio GNU cpio_2_4_2
4. Suivez les instructions affichées à l'étape 3 pour résoudre les
conflits entre les modifications locales pour FreeBSD et la
nouvelle version.
Ne déviez en aucun cas de cette procédure.
Pour appliquer les modifications locales à cpio, “patchez”
simplement et soumettez sur la branche principale (aka HEAD).
N'appliquez jamais les modifications locales à la branche GNU.
Toutes les modifications locales doivent être soumises à
“cpio@gnu.ai.mit.edu” pour inclusion dans la prochaine
version originale.
obrien@freebsd.org - 30 Mars 1997
</programlisting></footnote> :</para>
<programlisting>
This directory contains virgin sources of the original distribution files
on a "vendor" branch. Do not, under any circumstances, attempt to upgrade
the files in this directory via patches and a cvs commit. New versions or
official-patch versions must be imported. Please remember to import with
"-ko" to prevent CVS from corrupting any vendor RCS Ids.
For the import of GNU cpio 2.4.2, the following files were removed:
INSTALL cpio.info mkdir.c
Makefile.in cpio.texi mkinstalldirs
To upgrade to a newer version of cpio, when it is available:
1. Unpack the new version into an empty directory.
[Do not make ANY changes to the files.]
2. Remove the files listed above and any others that don't apply to
FreeBSD.
3. Use the command:
cvs import -ko -m 'Virgin import of GNU cpio v<version>' \
src/contrib/cpio GNU cpio_<version>
For example, to do the import of version 2.4.2, I typed:
cvs import -ko -m 'Virgin import of GNU v2.4.2' \
src/contrib/cpio GNU cpio_2_4_2
4. Follow the instructions printed out in step 3 to resolve any
conflicts between local FreeBSD changes and the newer version.
Do not, under any circumstances, deviate from this procedure.
To make local changes to cpio, simply patch and commit to the main
branch (aka HEAD). Never make local changes on the GNU branch.
All local changes should be submitted to "cpio@gnu.ai.mit.edu" for
inclusion in the next vendor release.
obrien@freebsd.org - 30 March 1997
</programlisting>
</sect1>
<sect1 id="policies-shlib">
<title>Bibliothèques partagées</title>
<para><emphasis>Contribution de &a.asami;, &a.peter;, and &a.obrien; 9
Décembre 1996.</emphasis></para>
<para>Si vous ajoutez à des logiciels portés ou d'autres
logiciels, le support des bibliothèques partagées qu'ils
n'ont pas encore, les numéros de version des bibliothèques
doivent suivre les règles ci-dessous. De façon
générale, ces numéros n'ont pas de rapport avec les
numéros de version du logiciel.</para>
<para>Les trois principes de génération des
bibliothèques partagées sont :</para>
<itemizedlist>
<listitem>
<para>Commencez à <literal>1.0</literal>,</para>
</listitem>
<listitem>
<para>Si la modification est rétro-compatible, augmentez le
numéro de version mineure,</para>
</listitem>
<listitem>
<para>Si la modification est incompatible avec les versions
antérieures, augmentez le numéro de version
majeure.</para>
</listitem>
</itemizedlist>
<para>Par exemple, l'ajout de fonctions et les corrections de bogues
résultent en une incrémentation du numéro de version
mineure, alors que la suppression de fonctions ou la modification de
syntaxes d'appel de fonctions imposent un changement de numéro de
version majeure.</para>
<para>Tenez-vous en à des numéros de version de la forme
majeure.mineure
(<replaceable>x</replaceable>.<replaceable>y</replaceable>). Notre
éditeur de liens dynamiques ne gère pas très bien
les numéros de version de la forme
<replaceable>x</replaceable>.<replaceable>y</replaceable>.<replaceable>z</replaceable>.
Tout numéro de version après le
<replaceable>y</replaceable> (i.e., le troisième chiffre) est
totalement ignoré lors de la comparaison des numéros de
version des bibliothèques partagées pour décider
avec quelle bibliothèque effectuer le lien. Si deux
bibliothèques partagées diffèrent d'une
“micro” révision, <command>ld.so</command> fera le lien
avec la plus élevée. I.e. : si vous éditez les liens
avec <filename>libfoo.so.3.3.3</filename>, l'éditeur de liens
n'enregistre que <literal>3.3</literal> dans les en-têtes, et fera
le lien avec n'importe quoi qui commence par
<replaceable>libfoo.so.3</replaceable>.<replaceable>(quelque chose >=
3)</replaceable>.<replaceable>(le numéro le plus
élevé disponible)</replaceable>.</para>
<note>
<para><command>ld.so</command> utilisera toujours la révision
“mineure” la plus élevée. I.e. : il
choisira <filename>libc.so.2.2</filename> plutôt que
<filename>libc.so.2.0</filename>, même si le programme a
été initialement lié avec
<filename>libc.so.2.0</filename>.</para>
</note>
<para>Pour les bibliothèques autres que celles des logiciels
portés, c'est aussi notre politique de ne changer de numéro
de version de bibliothèque partagée qu'une seule fois par
version de FreeBSD. Si vous modifiez une bibliothèque
système de telle sorte que cela réclame une
incrémentation du numéro de version, consultez l'historique
des soumissions du <filename>Makefile</filename>. C'est la personne qui
soumet qui doit s'assurer que le numéro de version de la
bibliothèque partagée est bien incrémenté
à la première modification et que les modifications
suivantes n'y touchent plus.</para>
</sect1>
</chapter>
<!--
Local Variables:
mode: sgml
sgml-declaration: "../chapter.decl"
sgml-indent-data: t
sgml-omittag: nil
sgml-always-quote-attributes: t
sgml-parent-document: ("../handbook.sgml" "part" "chapter")
End:
-->
|
