dpkg
exécutera pour toi quand ton paquet est installé, mis à jour ou enlevé.
Ces scripts s'appellent preinst, postinst, prerm
et postrm
dans la zone de contrôle du paquet. Ce sont des fichiers exécutables
propres; si ce sont des scripts (ce qui est recommandé), ils doivent
commencer par la convention habituelle #!
. Ils doivent être
lisible et exécutable par n'importe qui, et non modifiable.
dpkg
teste le statut de sortie de ces scripts. Il est important
qu'ils se terminent avec un statut différent de zéro, s'il y a une
erreur, afin que dpkg
puisse arrêter son traitement. Pour les
scripts shell, ceci signifie que tu as presque toujours besoin
d'utiliser set -e
(ce qui est généralement vrai quand on écrit
des scripts shell, en fait). Il est aussi important, bien sûr, qu'ils ne
se terminent pas avec un statut différent de zéro si tout se passe bien.
Il est nécessaire pour les procédures de recouvrement d'erreurs que les scripts soient idempotents; c'est à dire, appeler le même script plusieurs fois dans la même situation ne doit pas provoquer de problèmes. Si le premier appel échoue, ou s'arrête au milieu du chemin pour une raison ou une autre, le second appel devrait faire les choses qui n'ont pas été faites la première fois, s'il y en a, et sortir avec succès.
Quand un paquet est mis à jour, une combinaison des scripts du vieux et du nouveau paquet est appelée dans presque toutes les autres étapes de la procédure de mise à jour. Si tes scripts sont devenus plus compliqués, tu dois faire attention à cela, et peut être vérifier les arguments de tes scripts.
Techniquement parlant, le script preinst
est appelé avant d'installer
(une version particulière de) un paquet, et postinst
après; le script prerm
avant d'effacer (une version de) un paquet
et postrm
après.
Les programmes appelés à partir des scripts ne devraient pas normalement
avoir de chemin préfixé. Avant que l'installation démarre, dpkg
vérifie pour voir si les programmes ldconfig, start-stop-daemon,
install-info
et update-rc.d
peuvent être trouvés via la
variable d'environnement PATH
. Ces programmes, et n'importe quel
autre programme qu'on s'attend à trouver dans le PATH
, devraient
donc être appelés sans nom de chemins absolu.
Les scripts de maintenance ne devraient pas non plus réinitialiser le
PATH
, bien qu'ils peuvent choisir de le modifier en ajoutant
devant ou à la fin un répertoire spécifique à un paquet.
Ces considérations s'appliquent vraiment à tous les scripts shell.
install
install
vieille-versionupgrade
vieille-versionabort-upgrade
nouvelle-versionconfigure
version-configurée-plus-
récemmentabort-upgrade
nouvelle-versionabort-remove in-favour
paquet nouvelle-versionabort-deconfigure in-favour
paquet-installation-échoué version removing
paquet-
conflictuel versionremove
vieille-versionupgrade
nouvelle-versionfailed-upgrade
nouvelle-versionremove in-favour
paquet nouvelle-versiondeconfigure in-favour
paquet-installé version removing
paquet-
conflictuel versionremove
purge
upgrade
nouvelle-versionfailed-upgrade
vieille-versionabort-install
abort-install
vieille-versionabort-upgrade
vieille-versiondisappear
ecraseur nouvelle-versiondpkg --unpack
, ou l'étape unpack de dpkg --
install
) est la suivante. Dans chaque cas, si un erreur se produit, les
actions sont généralement exécuter en arrière - ce qui signifie que les
scripts de maintenance sont exécutés avec des arguments différents dans
l'ordre inverse. Ce sont les appels 'recouvrement d'erreur' listés ci-
dessous.
vieux-prerm upgrade nouvelle-version
nouveau-prerm failed-upgrade vieille-versionRecouvrement d'erreurs, dans les deux cas ci-dessus:
vieux-postinst abort-upgrade nouvelle-version
--auto-deconfigure
est spécifié, appel pour chaque paquet:
prerm-déconfiguré deconfigure in-favour paquet-installé version removing paquet-conflictuel versionRecouvrement d'erreurs:
postrm-déconfiguré abort-deconfigure in-favour paquet-échoué-installé version removing paquet-conflictuel versionLes paquets déconfigurés sont indiqués comme nécessitant une configuration, afin que si
--install
est utilisé, ils seront
configurés de nouveau, si possible.
prerm-conflictuel remove in-favour paquet nouvelle-versionRecouvrement d'erreurs:
postinst-conflictuel abort-remove in-favour paquet nouvelle-version
nouvelle-preinst upgrade vieille-version
nouveau-preinst install vieille-version
nouveau-preinst installLes versions de recouvrement d'erreurs, respectivement:
nouveau-postrm abort-upgrade vieille-version nouveau-postrm abort-install vieille-version nouveau-postrm abort-install
C'est une erreur pour un paquet de contenir des fichiers qui sont sur le
système dans d'autre paquet, à moins que Replaces
soit utilisé
(voir Replaces
- écraser les fichiers et remplacer les
paquets, section 8.5). Pour
l'instant l'option --force-overwriting
est disponible, le
dégradant en un avertissement, mais ce ne sera pas toujours le cas.
C'est une erreur beaucoup plus grave pour un paquet de contenir un
fichier ou autre chose qu'un répertoire où un autre paquet a un
répertoire (de nouveau, à moins que Replaces
ne soit utilisé).
Cette erreur peut être éviter si c'est l'effet recherché, en utilisant
--force-overwrite-dir
, mais ce n'est pas conseillé.
Les paquets qui s'écrasent mutuellement des fichiers produisent des comportements qui bien que déterministe est difficile à comprendre pour un administrateur système. Cela nous amène à des programmes "manquants" si par exemple, un paquet est installé qui écrase un fichier d'un autre paquet, et puis est effacé de nouveau[20].
Un répertoire ne sera jamais remplacé par un lien symbolique vers un
répertoire et vice versa; à la place, l'état existant (lien symbolique
ou non) est conservé et dpkg
suivra les liens s'il y en a.
vieux-postrm upgrade nouvelle-version
dpkg
essayera:
nouveau-postrm failed-upgrade vieille-versionLes recouvrements d'erreur, dans les deux cas:
vieux-preinst abort-upgrade nouvelle-versionC'est le point de non retour - si
dpkg
atteint ce point,
il ne reviendra pas en arrière de ce point, si une erreur
survient. Ceci laissera le paquet dans un mauvais état, qui nécessitera
une réinstallation réussie pour remettre en état, mais c'est quand
dpkg
commence à faire des choses irréversibles.
dpkg
appelle:
postrm-disparu disappear ecraseur version-ecraseur
dpkg
). Remarque que ce
paquet disparu n'a pas appelé son script prerm, car dpkg
ne sait
pas à l'avance que le paquet est écrasé.
dpkg --
install
, ou avec --configure
), nous mettons à jour d'abord les
fichiers de configuration (conffiles) et ensuite appelons:
posinst configure version-configurée-la-plus-récenteAucune actions n'est tenté pour défaire les erreurs pendant la configuration.
S'il n'y a pas de version configurée plus récente, dpkg
passera
un argument nul; les vieilles versions de dpkg
peuvent passer
<unknow>
(avec les signes supérieur et inférieur) dans ce cas. Même
les plus vieux ne passent pas de second argument du tout, dans n'importe
quelles circonstances.
remove
remove
dpkg
.
#*#
files, %-files, .dpkg-{old, new, tmp}
, etc.) sont
effacés.
purge