Le problème que vous rencontrez est le suivant. Vous avez essayé d'exécuter une mise à jour régulière sur votre machine Linux, très probablement un système basé sur Ubuntu ou Debian qui utilise apt comme gestionnaire de paquets. Après avoir mis à jour le contenu du référentiel, vous avez exécuté la commande dist-upgrade et vous avez rapidement rencontré une erreur. Apt se plaignait de dépendances manquantes ou cassées et vous suggérait de relancer la commande avec --fix-broken ou similaire. Cependant, cela ne semble pas aider.
J'ai rencontré ce problème il y a quelques semaines sur KDE neon. Le problème m'a vraiment ennuyé, car sans connaissances d'expert, il n'y a pas d'issue. Vous vous retrouvez avec un système inutilisable qui ne peut pas être mis à jour de manière fiable. C'est tellement fragile, et nous sommes en 2020, quand on s'attendrait à un certain niveau de robustesse du logiciel. LELZ. J'ai fait l'éloge du néon dans le passé pour sa résilience, mais il est ensuite allé de l'avant et a annulé son propre travail. Quoi qu'il en soit, laissez-moi vous montrer comment vous pouvez résoudre ce problème.
Problème plus en détail
Voici ce que vous voyez sur la ligne de commande :
dpkg :erreur de traitement de l'archive /var/cache/apt/archives/calligraplan_1%3a3.2.2+p18.04+
git20191212.1837-0_amd64.deb (--unpack) :
tentative d'écrasement de '/ usr/share/locale/ar/LC_MESSAGES/calligraplan.mo', qui se trouve également dans le package calligra-data 1:3.1.0+p18.04+git20191222.0027-0
dpkg-deb :erreur :coller le sous-processus a été tué par le signal (tuyau brisé)
Des erreurs ont été rencontrées lors du traitement :
/var/cache/apt/archives/calligraplan_1%3a3.2.2+p18.04+
git20191212.1837-0_amd64 .deb
E :Le sous-processus /usr/bin/dpkg a renvoyé un code d'erreur (1)
Dans mon cas, le forfait bancal était Calligra. Je ne sais pas pourquoi c'était là en premier lieu, mais bon, nous devons résoudre ce problème, n'est-ce pas. La procédure standard consiste donc à exécuter apt avec l'option --fix-broken. Ou peut-être pourriez-vous essayer avec --ignore-missing, une autre option valide. Sauf que vous frappez un enfer de dépendance cyclique, et il n'y a pas d'issue.
sudo apt --fix-broken install
Lecture des listes de packages... Terminé
Construction de l'arborescence des dépendances
Lecture des informations d'état... Terminé
Vous pouvez exécuter 'apt -- fix-broken install' pour les corriger.
Les packages suivants ont des dépendances non satisfaites :
calligra :Dépend :calligraplan (>=1:3.1.0+p18.04+git20191222.0027-0) mais 1:3.1.0+p18.04+ git20191119.0027-0 est installé
calligraplan :Dépend :calligra-libs (=1:3.1.0+p18.04+git20191119.0027-0) mais 1:3.1.0+p18.04+git20191222.0027 -0 est installé
E :Dépendances non satisfaites. Essayez 'apt --fix-broken install' sans packages (ou spécifiez une solution).
À ce stade, vous ne pouvez pas vraiment supprimer Calligra, car le gestionnaire de packages est déjà dans un état instable. L'étape logique serait d'ignorer ce paquet spécifique, ou tout paquet cassé, en utilisant l'option --ignore-missing ou similaire, hélas, cela ne semble pas fonctionner non plus. Donc le système est bloqué.
Solution
Le seul moyen de contourner ce problème consiste à modifier le fichier d'état du gestionnaire de packages et à supprimer manuellement toute mention des packages concernés et de leurs dépendances, afin qu'apt puisse reprendre et installer la partie saine. Maintenant, ce n'est pas une bonne chose, car vous vous retrouverez avec un logiciel non corrigé - dans certains cas, cela pourrait être un élément important, accessible sur Internet, peut-être même avec une ou deux vulnérabilités réelles, ou peut-être un logiciel avec des bogues qui se manifestent lorsque vous travail (disons l'une des bibliothèques système critiques). Mais cela vous permet de continuer à travailler et peut-être de recevoir un bon lot de mises à jour dans le futur.
Ce dont vous avez besoin à ce stade est d'ouvrir /var/lib/dpkg/status dans un éditeur de texte en tant que root. À ce stade, j'ai rencontré un autre problème stupide, et c'est le fait que vous ne pouvez pas "soi-disant" lancer Kate en tant que root, à cause de failles de sécurité potentielles. Absurdité totale et totale.
sudo kate /var/lib/dpkg/status
L'exécution de Kate avec sudo n'est pas possible en raison de vulnérabilités de sécurité irréparables.
Mais vous pouvez sudo su -, puis exécuter Kate en tant que root, sans problème. C'est l'un de ces cas "trouvons un problème pour trouver une solution", car il n'a aucune incidence réelle sur le travail réel et ne fait aucune différence, sauf pour ennuyer les utilisateurs. Comme si vous ne pouviez pas simplement ouvrir une fenêtre de terminal et supprimer des éléments avec sudo si vous le souhaitez.
Ouvrez le fichier. Ceci n'est qu'une longue liste de packages qui vont être installés. Chaque package est livré avec une description, une version et toutes les dépendances. Pour moi, la solution consistait à rechercher toute mention du mot calligra, puis à supprimer simplement ces blocs de package du fichier d'état. En général, ce fichier illustre assez bien le désordre, avec toutes les différentes sections dépend, recommande, pauses et ainsi de suite.
Package :libzxingcore1
Statut :install ok installé
Priorité :facultatif
...
Version : 1.0.7-1+18.04+bionic+build2
Dépend :libc6 (>=2.14), libgcc1 (>=1:3.4), libstdc++6 (>=5.2)
...
Paquet :mokutil
Statut :install ok installé
Priorité :facultatif
...
Version :0.3.0+1538710437.fb6250f-0ubuntu2~18.04.1
Dépend :libc6 (>=2.14), libefivar1 (> =34), libssl1.1 (>=1.1.0)
...
Package :libkf5itemviews-dev
Statut :install ok installed
Priorité :facultative
...
Version :5.65.0+p18.04+git20191222.0152-0
Remplace :libkf5itemviews-doc (<<5.61.90-0)
Dépend :libkf5itemviews5 (=5.65.0+p18.04+git20191222.0152-0), qtbase5-dev (>=5.8.0~)
Recommande :libkf5itemviews-doc (=5.65.0+p18.04+git20191222. 0152-0)
Échecs :kio-dev (<< 5.28), libkf5iconthemes-dev (<< 5.51), libkf5kcmutils-dev (<< 5.51), libkf5kio-dev (<<5.51), libkf5xmlgui-dev (<<5.51)
Mais notre objectif est simple :supprimer les entrées en conflit et permettre à notre système de fonctionner. En effet, une fois que j'ai terminé cela, j'ai pu relancer le gestionnaire de paquets apt et terminer les mises à jour. Travail terminé.
Conclusion
Je suis surpris et consterné que nous soyons dans un état où un composant mal emballé peut complètement ruiner l'état du système sous Linux. Et le fait est qu'il existe de nombreuses façons d'empêcher cela, si seulement Linux était développé en tant que produit et non en tant que série de fonctions fragmentées par des développeurs qui ne voient pas l'image d'ensemble de l'utilisation réelle. Par exemple, vérifiez que tous les packages sont sains AVANT d'exécuter l'installation. Supprimez automatiquement les paquets défectueux s'ils sont identifiés. Invitez l'utilisateur. Mettez le mauvais composant sur liste noire. N'importe quoi, quelque chose.
Mais c'était un problème en 2000, et c'est toujours un problème en 2020, et c'est pourquoi j'utilise principalement Windows dans ma configuration de production, car la souffrance n'est pas mon deuxième prénom. Si vous vous retrouvez à utiliser la ligne de commande et que les choses tournent mal, vous voudrez peut-être consulter le fichier d'état. Cela vous aidera à contourner les dépendances brisées ou manquantes et vous permettra de mettre à jour votre boîte. Sur une note triste mais heureuse, nous en avons fini ici.