summaryrefslogtreecommitdiffstats
path: root/man/fr/dpkg-maintscript-helper.pod
blob: f54c550013109ff39fe9f3851944c219d11e7b13 (plain)
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
        *****************************************************
        *           GENERATED FILE, DO NOT EDIT             *
        * THIS IS NO SOURCE FILE, BUT RESULT OF COMPILATION *
        *****************************************************

This file was generated by po4a(7). Do not store it (in VCS, for example),
but store the PO file used as source file by po4a-translate.

In fact, consider this as a binary, and the PO file as a regular .c file:
If the PO get lost, keeping this translation up-to-date will be harder.

=encoding UTF-8

=head1 NOM

dpkg-maintscript-helper - Contournement des limitations connues de dpkg dans
les scripts du responsable

=head1 SYNOPSIS

B<dpkg-maintscript-helper> I<commande> [I<paramètre>...] B<-->
I<paramètre-script-responsable>...

=head1 COMMANDES ET PARAMÈTRES

=over 

=item B<supports> I<commande>

=item B<rm_conffile> I<fichier-de-configuration> [I<version-précédente>
[I<paquet>]]

=item B<mv_conffile> I<ancien-fichier-de-configuration>
I<nouveau-fichier-de-configuration> [I<dernière-version> [I<paquet>]]

=item B<symlink_to_dir> I<nom-de-chemin> I<ancienne-cible> [I<version-précédente>
[I<paquet>]]

=item B<dir_to_symlink> I<nom-de-chemin> I<nouvelle-cible> [I<version-précédente>
[I<paquet>]]

=back

=head1 DESCRIPTION

Ce programme est prévu pour être exécuté dans les scripts du responsable
afin de réaliser certaines tâches que B<dpkg> ne peut pas (encore) prendre
en charge directement à cause de limites de conception ou de limitations
actuelles.

La plupart de ces tâches nécessitent la coordination de plusieurs scripts du
responsable (B<preinst>, B<postinst>, B<prerm>, B<postrm>). Pour éviter des
erreurs, le même appel a simplement besoin d'être placé dans tous les
scripts. Le programme adaptera alors son comportement en fonction de la
variable d'environnement B<DPKG_MAINTSCRIPT_NAME> et des paramètres des
scripts du responsable qui doivent être passés avec un double tiret.

=head1 PARAMÈTRES COMMUNS

=over 

=item I<version-précédente>

Indique la dernière version du paquet pour laquelle la mise à niveau doit
provoquer l'opération. Il est important de déterminer correctement
I<version-précédente> afin que les opérations s'accomplissent correctement
même si l'utilisateur reconstruit le paquet avec une version locale. Si le
paramètre I<version-précédente> est vide ou omis, l'opération sera tentée à
chaque mise à niveau (il est toutefois plus sûr d'indiquer la version afin
que l'opération n'ait lieu qu'une fois).

Si le fichier de configuration n'était pas fourni pour une raison ou une
autre dans plusieurs versions et que vous modifiez les scripts du
responsable pour nettoyer l'ancien fichier, I<version-précédente> doit être
basé sur la version actuellement préparée et non la première version qui ne
fournissait plus ce fichier de configuration. Cela s'applique à toutes les
autres actions de la même manière

Par exemple, pour un fichier de configuration supprimé dans la version
B<2.0-1> d'un paquet, I<version-précédente> doit être B<2.0-1~>. Cela
provoquera la suppression du fichier même si la version précédente B<1.0-1>
a été reconstruite avec B<1.0-1local1> comme numéro de version. Ou bien, si
un paquet substitue un chemin d'un lien symbolique (fourni dans la version
B<1.0-1>) à un répertoire (fourni dans la version B<2.0-1>), mais ne réalise
réellement la substitution que dans les scripts du responsable dans la
version B<3.0-1>, I<version-précédente> doit être B<3.0-1~>.

=item I<paquet>

Le nom du paquet propriétaire du (des) nom(s) de chemin. Si le paquet est
S<« Multi-Arch:> S<same »> ce paramètre doit inclure le type d'architecture,
sinon, il ne devrait B<pas> habituellement inclure le type d'architecture
(parce qu'il pourrait interdire les catégories croisées, ou le passage d'une
architecture spécifique à l'architecture B<all> ou vice-versa). Si le
paramètre est vide ou omis, les variables d'environnement
B<DPKG_MAINTSCRIPT_PACKAGE> et B<DPKG_MAINTSCRIPT_ARCH> (telles que définies
par B<dpkg> lors de l'exécution des scripts du responsable) seront utilisées
pour créer un nom de paquet avec une qualification d'architecture.

=item B<-->

Tous les paramètres des scripts du responsable doivent être passés au
programme après B<-->.

=back

=head1 TÂCHES LIÉES AUX FICHIERS DE CONFIGURATION

Lors de la mise à niveau d'un paquet, B<dpkg> ne supprime pas un fichier de
configuration automatiquement (comportant des modifications locales à
préserver) s'il n'est pas présent dans la nouvelle version. Il existe deux
raisons principales à cela. En premier lieu, le fichier de configuration
peut avoir été supprimé par accident, être réintégré dans la version
suivante et il peut être nécessaire de retrouver les modifications
locales. Ensuite, l'objectif est également de permettre d'effectuer la
transition depuis des fichiers de configuration gérés par dpkg vers un
fichier géré à l'aide des scripts du responsable, en général à l'aide d'un
outil comme debconf ou ucf.

Cela signifie que si un paquet a besoin de renommer ou supprimer un fichier
de configuration, il doit le faire explicitement. L'objectif de
B<dpkg-maintscript-helper> est donc de fournir des méthodes de suppression
ou renommage de fichiers de configuration à l'aide de scripts du
responsable.

=head2 Supprimer un fichier de configuration

Note: This can be replaced in most cases by the C<remove-on-upgrade> flag in
F<DEBIAN/conffiles> (since dpkg 1.20.6), see L<deb-conffiles(5)>.

Si un fichier de configuration est complètement supprimé, il doit être
effacé du disque sauf si l'administrateur local l'a modifié. Les éventuelles
modifications locales doivent être conservées. Si la mise à jour du paquet
est interrompue, le fichier de configuration rendu obsolète ne doit pas
avoir disparu.

L'ensemble de ces pré-requis est mis en œuvre en utilisant les commandes
shell suivantes dans les scripts B<preinst>, B<postinst> et S<B<postrm> :>

=over 

Z<>
 dpkg-maintscript-helper rm_conffile \
    I<conffile> I<prior-version> I<package> -- "$@"

=back

I<fichier-de-configuration> est le nom du fichier de configuration à
supprimer.

Détails de la mise en œuvre S<actuelle : dans> le script B<preinst>, il est
vérifié si le fichier de configuration a été modifié. Celui-ci est alors
renommé, soit en I<fichier-de-configuration>B<.dpkg-remove> s'il n'a pas été
modifié, soit en I<fichier-de-configuration>B<.dpkg-backup> s'il l'a
été. Dans le script B<postinst>, ce dernier fichier est ensuite renommé en
I<fichier-de-configuration>B<.dpkg-bak> et conservé pour référence puisqu'il
contient des modifications locales, mais le premier est supprimé. Si la mise
à jour du paquet est interrompue, le script B<postrm> remet en place le
fichier de configuration d'origine. À la purge du paquet, le script
B<postrm> supprimera également le fichier B<.dpkg-bak> qui avait été
conservé jusque là.

=head2 Renommer un fichier de configuration

Si un fichier de configuration est déplacé à un autre endroit, il est
nécessaire de garantir la préservation des modifications locales. À première
vue, cela peut sembler être une simple modification dans le script
B<preinst>, mais cela risque de résulter en une demande, par B<dpkg>,
d'approbation de modifications locales qui n'existent pas réellement.

Un renommage élégant peut être mis en œuvre avec les extraits shell qui
suivent, dans les scripts B<preinst>, B<postinst> et S<B<postrm> :>

=over 

Z<>
 dpkg-maintscript-helper mv_conffile \
    I<old-conffile> I<new-conffile> I<prior-version> I<package> -- "$@"

=back

I<ancien-fichier-configuration> et I<nouveau-fichier-configuration> sont
l'ancien et le nouveau nom du fichier de configuration à renommer.

Détails de la mise en œuvre S<actuelle : dans> le script B<preinst>, il est
vérifié si le fichier de configuration a été modifié. Celui-ci est alors
soit laissé en place s'il a été modifié, soit renommé en
I<ancien-fichier-configuration>B<.dpkg-remove> s'il ne l'a pas été. Lors de
la configuration, le script B<postinst> supprime
I<ancien-fichier-configuration>B<.dpkg-remove> et renomme
I<ancien-fichier-configuration> et I<nouveau-fichier-configuration> si
I<ancien-fichier-configuration> existe toujours. Si la mise à jour ou
l'installation sont interrompues, le script B<postrm> renomme
I<ancien-fichier-configuration>B<.dpkg-remove> en
I<ancien-fichier-configuration> si c'est indispensable.

=head1 SUBSTITUTIONS DE LIENS SYMBOLIQUES ET DE RÉPERTOIRES

Lors de la mise à niveau d'un paquet, B<dpkg> ne substitue pas
automatiquement un lien symbolique à un répertoire ou le contraire. Les
retours à une version inférieure ne sont pas pris en charge et le chemin
sera laissé comme il est.

=head2 Substituer un lien symbolique à un répertoire

Si un lien symbolique est substitué à un répertoire réel, il est nécessaire
de garantir qu'avant le dépaquetage le lien symbolique est retiré. À
première vue, cela peut sembler être une simple modification dans le script
B<preinst>, mais cela risque de résulter en problèmes si l'administrateur
local a personnalisé le lien symbolique ou si l'on revient à une version
antérieure du paquet.

Un renommage élégant peut être mis en œuvre avec les extraits shell qui
suivent, dans les scripts B<preinst>, B<postinst> et S<B<postrm> :>

=over 

Z<>
 dpkg-maintscript-helper symlink_to_dir \
    I<pathname> I<old-target> I<prior-version> I<package> -- "$@"

=back

I<nom-de-chemin> est le nom absolu de l'ancien lien symbolique (le chemin
sera un répertoire à la fin de l'installation) et I<ancienne-cible> la cible
de l'ancien lien symbolique vers I<nom-de-chemin>. Cela peut être un chemin
absolu ou relatif vers le répertoire contenant I<nom-de-chemin>.

Détails de la mise en œuvre S<actuelle :> dans le script B<preinst>, il est
vérifié si le lien symbolique existe et pointe vers I<ancienne-cible>. Si ce
n'est pas le cas, il est alors soit laissé en place, soit renommé en
I<nom-de-chemin>B<.dpkg-backup>. Lors de la configuration, le script
B<postinst> supprime I<nom-de-chemin>B<.dpkg-backup> si
I<nom-de-chemin>B<.dpkg-backup> est encore un lien symbolique. Si la mise à
niveau ou l'installation sont interrompues, le script B<postrm> renomme
I<nom-de-chemin>B<.dpkg-backup> en I<nom-de-chemin> si c'est indispensable.

=head2 Substituer un répertoire à un lien symbolique

Si un répertoire réel est substitué à un lien symbolique, il est nécessaire
de garantir qu'avant le dépaquetage le répertoire est retiré. À première
vue, cela peut sembler être une simple modification dans le script
B<preinst>, mais cela risque de résulter en problèmes si le répertoire
contient des fichiers de configuration, des noms de chemins qui
appartiennent à d'autres paquets, des noms de chemin créés localement ou si
l'on revient à une version antérieure du paquet.

Une substitution élégante peut être mise en œuvre avec les extraits shell
qui suivent, dans les scripts B<preinst>, B<postinst> et S<B<postrm> :>

=over 

Z<>
 dpkg-maintscript-helper dir_to_symlink \
    I<pathname> I<new-target> I<prior-version> I<package> -- "$@"

=back

I<nom-de-chemin> est le nom absolu de l'ancien répertoire (le chemin sera un
lien symbolique à la fin de l'installation) et I<nouvelle-cible> la cible du
nouveau lien symbolique vers I<nom-de-chemin>. Cela peut être un chemin
absolu ou relatif vers le répertoire contenant I<nom-de-chemin>.

Détails de la mise en œuvre S<actuelle :> dans le script B<preinst>, il est
vérifié si le répertoire existe et ne contient pas de fichiers de
configuration, de noms de chemin qui appartiennent à d'autres paquets, de
noms de chemin créés localement. Si ce n'est pas le cas, il est alors soit
laissé en place, soit renommé en I<nom-de-chemin>B<.dpkg-backup> et un
répertoire vide provisoire nommé I<nom-de-chemin> est créé, marqué par un
fichier pour que dpkg le suive. Lors de la configuration, le script
B<postinst> achève la substitution si I<nom-de-chemin>B<.dpkg-backup>  est
encore un répertoire et si I<nom-de-chemin> est le répertoire provisoire. Il
supprime le fichier qui marque le fichier provisoire et déplace les fichiers
nouvellement créés dans le répertoire provisoire vers la cible du lien
symbolique I<nouvelle-cible>, remplace le répertoire provisoire
I<nom-de-chemin>, maintenant vide, par un lien symbolique vers la
I<nouvelle-cible> et, enfin supprime I<nom-de-chemin>B<.dpkg-backup>. Si la
mise à niveau ou l'installation sont interrompues, le script B<postrm>
renomme I<nom-de-chemin>B<.dpkg-backup> en I<nom-de-chemin> si c'est
indispensable.

=head1 INTÉGRATION DANS LES PAQUETS

Lors de l'utilisation d'un assistant d'empaquetage, veuillez vérifier s'il
ne dispose pas d'une intégration native de B<dpkg-maintscript-helper> ce qui
vous facilitera la tâche. Voir par exemple B<dh_installdeb>(1).

Comme B<dpkg-maintscript-helper> est utilisé dans le script B<preinst>,
l'utiliser sans conditions impose une pré-dépendance afin de garantir que la
version minimale nécessaire de B<dpkg> ait bien été préalablement
configurée. La version minimale dépend de la commande S<utilisée :> ainsi pour
B<rm_conffile> et B<mv_conffile>, cette version S<est 1.15.7.2,> pour
B<symlink_to_dir> et B<dir_to_symlink>, S<c'est 1.17.14 :>

=over 

 Pre-Depends: dpkg (>= 1.17.14)

=back

Cependant, dans de nombreux cas, l'opération réalisée par le programme n'est
pas critique pour le paquet et au lieu d'utiliser une pré-dépendance, il est
possible de ne lancer le programme que si on a la certitude que la commande
nécessaire est gérée par la version actuellement installée de S<B<dpkg> :>

=over 

Z<>
 if dpkg-maintscript-helper supports I<command>; then
    dpkg-maintscript-helper I<command> ...
 fi

=back

La commande B<supports> retournera B<0> en cas de réussite, B<1>
autrement. Elle vérifiera si les variables d'environnement telles que
définies par B<dpkg> et requises par le script sont présentes, et
considérera que c'est un échec si l'environnement n'est pas suffisant.

=head1 ENVIRONNEMENT

=over 

=item B<DPKG_ROOT>

If set, it will be used as the filesystem root directory.

=item B<DPKG_ADMINDIR>

If set, it will be used as the B<dpkg> data directory.

=item B<DPKG_COLORS>

Fixe le mode de couleur (depuis S<dpkg 1.19.1).> Les valeurs admises
actuellement sont B<auto> (par défaut), B<always> et B<never>.

=back

=head1 VOIR AUSSI

B<dh_installdeb>(1)


=head1 TRADUCTION

Ariel VARDI <ariel.vardi@freesbee.fr>, 2002.
Philippe Batailler, 2006.
Nicolas François, 2006.
Veuillez signaler toute erreur à <debian-l10n-french@lists.debian.org>.