Supposons que j'ai un paquet debian A-1.0.0.deb
(qui contient une bibliothèque) et un autre paquet B-1.0.0.deb
(qui contient un service) qui dépend de la bibliothèque A
. Maintenant, disons que je veux passer à A-1.0.1.deb
.
Selon ce document , dpkg
utilise un algorithme assez complexe pour déterminer quels scripts de maintenance de paquet sont appelés pour chaque paquet dans le cadre du processus de mise à niveau. Si certaines de ces étapes échouent, alors A
peut être laissé dans un état incertain (par exemple, "Semi-installé").
Cependant, lorsque vous interrompez A
, alors B
est également interrompu car il dépend de A
. Ma question est donc la suivante: dpkg
a-t-il un moyen intégré de gérer cette situation? Le statut d'installation de B
change-t-il en fonction du statut de A
? Idéalement, dpkg
aurait une fonctionnalité intégrée pour déplacer B
de l'état installé à un autre état (afin que le service B
puisse être arrêté et redémarré lorsque A
est en bon état ), mais je ne trouve rien dans la documentation dpkg
suggérant que cela est fait.
Si dpkg
ne gère pas cette situation intelligemment, est-ce que apt
?
D'après ce que j'ai vécu, pas ce que j'ai lu.
Cependant, lorsque vous cassez A, alors B est aussi cassé puisque A en dépend. Ma question est donc la suivante: dpkg a-t-il un moyen intégré de gérer cette situation?
Oui, il essaiera de réinstaller ou de reconfigurer A lors de la prochaine exécution.
Si cela venait juste d'être interrompu, cela réglerait le problème et continuerait à fonctionner normalement.
Mais c'est un problème avec les scripts de contrôle, il échouera encore et encore et restera dans cette boucle. Ensuite, il s’agit d’un bogue et le rapport serait rempli avec ce paquet et un correctif manuel est requis.
Le statut d'installation de B change-t-il en fonction du statut de A?
Non, le statut reste tel qu'installé, aucun changement, mais il garde également une trace de la dépendance brisée, du moins pas dans le même fichier /var/lib/dpkg/status
.
Si dpkg ne gère pas cette situation intelligemment, apt?
Non, APT n'interfère pas dans ce cas. apt
utilise dpkg
, dpkg est l'outil de niveau inférieur et c'est le seul outil qui permet réellement d'installer, de construire et de supprimer des paquets Debian.
Essayons, mieux cela se fait dans une virtualbox.
Préparer des paquets factices
~$ Sudo apt install equivs
~$ mkdir deleteme
~$ cd deleteme
B 1.0.0 dépend de A
~/deleteme$ equivs-control b0
~/deleteme$ nano b0
...
Package: b
Version: 1.0.0
...
Depends: a
...
~/deleteme$ equivs-build b0
Une propre installation 1.0.0 & supprimer
~/deleteme$ equivs-control a0
~/deleteme$ nano a0
...
Package: a
Version: 1.0.0
...
~/deleteme$ equivs-build a0
Une installation 1.0.1 sale, mais nettoyer supprimer
~/deleteme$ cp a0 a1
~/deleteme$ nano a1
...
Package: a
Version: 1.0.1
...
Postinst: a1.postinst
...
~/deleteme$ nano a1.postinst
#!/bin/sh
exit 1
~/deleteme$ equivs-build a1
Maintenant, vous devriez avoir:
~/deleteme$ ls -1
a0
a1
a_1.0.0_all.deb
a_1.0.1_all.deb
a1.postinst
b0
b_1.0.0_all.deb
Essayez ce scénario
Sudo su
dpkg -i b_1.0.0_all.deb
dpkg --audit
dpkg -i a_1.0.0_all.deb
dpkg --audit
dpkg --configure -a
dpkg --audit
dpkg --remove a
dpkg --remove b
dpkg --remove a
dpkg -i a_1.0.0_all.deb
dpkg -i b_1.0.0_all.deb
dpkg --audit
dpkg -i a_1.0.1_all.deb
dpkg --audit
dpkg --remove a
apt purge a
Pour obtenir une boucle où vous ne pouvez pas terminer l'installation, supprimez-la.
Créer propre A 1.0.1, B 1.0.0 mais A 1.0.0 avec un script Prerm:
contenant exit 1
. Ainsi, lorsque vous essayez d'installer A 1.0.1, dpkg ne parvient pas à supprimer A 1.0.0.
Si les dépendances A
ont changé sur le package installé B
, vous verrez une erreur après l'exécution de apt-get update && apt-get upgrade
, le package sera marqué comme kept back
:
The following packages have been kept back
B-1.0.0
dpkg
ne vous aidera pas si une mise à niveau est disponible B-1.0.1
seulement apt-get dist-upgrade
sera utile.