--- /dev/null
+[[!meta date="Sat, 13 Jul 2013 21:42:33 +0900"]]
+[[!meta updated="Sat, 13 Jul 2013 21:42:33 +0900"]]
+[[!tag Debian]]
+
+[[!meta title="Les _triggers_ de Dpkg et RPM : comparaison."]]
+
+Dpkg et RPM proposent un mécanisme appelé _[[triggers]]_ en anglais. Dans le
+cas de Dpkg, la traduction française est _actions différées_. Je ne connais
+pas de traductions pour RPM, et la version française ne s'appliquerait pas
+bien, pour les raisons qui suivent.
+
+Il existe deux types d'_actions différées_ pour Dpkg : _explicite_ et
+_fichier_. Dans le cas du type _explicite_, un script d'un paquet A va activer
+un paquet B. Le type _fichier_ est plus courant. Dans ce cas, l'installation,
+la modification ou l'effacement par un paquet A d'un ficher dans un chemin
+prédéterminé par un paquet B va activer le paquet B. Les _actions différées_
+sont souvent utiliées quand un paquet A doit enregistrer une information auprès
+d'un paquet B. Par exemple, lorsqu'une application graphique est installée,
+son paquet peut ajouter sa description dans le répertoire
+`/usr/share/applications`, ce qui va activer le paquet `desktop-file-utils`,
+qui fera le nécessaire pour ajouter une entrée dans le système de menu de
+l'interface graphique.
+
+Les _triggers_ de RPM fonctionnent différemment. L'installation, la mise à
+jour ou le retrait d'un paquet A va activer un paquet B si le paquet B déclare
+son intérêt pour le paquet A dans son fichier _SPEC_ (en mettant des conditions
+sur la version du paquet A si nécessaire). Les documentations de
+[RPM](http://rpm.org/api/4.4.2.2/triggers.html) et de
+[Fedora](http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch10s02.html)
+donnent quelques examples d'utilisation, comme la mise à jour de liens
+symboliques lors du remplacement d'un serveur de courriels par un autre.
+
+Au bout du compte, bien que les deux mécanismes portent le même nom en anglais,
+ils n'ont pas le même but. Dans le cas de Dpkg, les _actions différées_ sont
+particulièrement utiles pour regrouper des actions similaires. Par exemple,
+mettre à jour la liste des pages de manuels une seule fois après l'installation
+de cent paquets, plutôt que cent fois après l'installation de chaque paquet.
+Elles servent aussi à remplacer des commandes répétées dans un grand nombre de
+paquets par une commande unique dans un paquet central, et ainsi faciliter
+l'évolution du système. Dans le cas de RPM, les _triggers_ semblent plus
+spécialisées, puisqu'elles concernent à chaque instance la relation entre deux
+paquets.