bruno a écritEn dehors de ces considérations, que se passe-t-il avec ton script si la mise à jour bloque à cause d'un conflit de paquets ? Que se passe-t-il si lors de la mise à jour, l'installation d'un paquet pose une question à laquelle on doit répondre ?
Faut bien voir le script comme un processus en cycle, qui est exécuté à chaque démarrage.
apt full-upgrade -y réponds par défaut oui et ne bloquera pas le processus, même si la réponse oui laissera un conflit de paquet. Quoiqu'il arrive, le processus continue après
full-upgrade. Les commandes suivantes, de nettoyage et réparation, vont justement débloquer le conflit, en répondant oui par défaut. En revanche,
dpkg --configure -a peux lui rester vraiment bloqué en cas de conflit supérieur. Sauf qu'il y aura eu des réparations de paquet avant dpkg, et du coup, au cycle suivant, c'est à dire update puis full-upgrade, le processus ne sera plus bloqué. Les résidus de confilt seront ensuite résolus, et ainsi de suite à chaque démarrage. J'utilise ce script depuis un long sur mes deux machines perso. L'icone du panel reste affiché durant le processus mais s'enlève juste avant dpkg. Du coup, si le processus resterai bloqué, l'icone resterai affiché longtemps, ce que je n'ai jamais observé sur mes deux machines. Sur mon desktop, utilisé quotidiennement, l'icone de la mise à jour du script reste affiché moins d'une minute maxi. Avec virtualbox, j'ai testé le script en interrompant brutalement le processus de mises à jour en fermant la machine virtuelle brutalement, afin de créer des conflits de paquet justement. Au cycle suivant, les confilts étaient résolus. Ces tests m'ont motivé à installer par défaut ce script sur toute les machines où j'installe linux.
Heureusement, si les commandes avec BAT0 échouent, cela va exécuter les mises à jour de toute façon car le test est "différent de déchargement"
if [ "${status}" != "Discharging" ]; then
echo "machine sur secteur : OK"
flag="true"
