PAQUETS ET DEPENDANCES SOUS UBUNTU

Paquets et dépendances

Un paquet A est une brique logicielle qui dépend potentiellement d’autres paquets B,C, D. Ainsi B, C, D doivent être installés avant A, puis seulement ensuite A peut s’installer.

La même problématique s’applique quand on désinstalle. Si on désinstalle B (ou C ou D) avant A, on casse A. On doit donc d’abord désinstaller A pour pouvoir déinstaller B. Le fait de déinstaller B ne requiert rien au niveau de C ou D.

On voit donc que l’ordre dans lequel on installe/désinstalle les paquets est important.

apt et dpkg

Le gestionnaire de paquets debian fonctionne en plusieurs couches. Les deux couches qui nous intéressent sont :

– dpkg : la couche « bas niveau » : quand je déploie A, je vérifie au préalable que B, C, D sont présents, sinon je plante. dpkg ne fait rien pour essayer d’arranger le problème, ce n’est pas son problème (c’est celui d’apt). dpkg sait donc ce qui est installé et dans quelle version, et il sait donc si A peut ou non être installé avec succès.

– apt : on voit que ce qui manque à dpkg c’est un plan de bataille : télécharger A, B, C, D, puis invoquer dpkg dans le bon ordre. Pour cela, apt doit savoir où télécharger les paquets, et c’est le rôle de /etc/apt/sources.list. apt peut demander à dpkg ce qui manque et dans ce cas là, télécharger ce qui manque. Ensuite il appelle dpkg dans le bon ordre pour faire le boulot.

Problème 1 : on voit que dpkg, au moment de vérifier les dépendances, fait des vérifications. Ainsi si un autre dpkg travaillait au même moment, les deux pourraient se tirer dans les pattes et faire n’importe quoi. C’est la raison pour laquelle seul un dpkg doit tourner à la fois.

Réponse au problème : pour garantir que dpkg n’est lancé qu’une seule fois, il place un verrou (c’est un fichier vide, en l’occurrence /var/lib/dpkg/lock) quand il travaillle. Si on lance un autre dpkg, il verra ce verrou et refusera de poursuivre car il craindra qu’un autre dpkg tourne déjà (cf le message d’erreur que tu as). Note que le choix d’utiliser un verrou plutôt que de regarder quels programmes tourne est un choix délibéré mais nous n’entrerons pas dans ces détails techniques : le choix qui a été fait, c’est de poser un verrou 🙂 S’il y a un verrou on stoppe ; sinon on enchaîne. Une fois que dpkg se termine, il retire le verrou. Ainsi on pourra par la suite à nouveau lancer dpkg.

Conséquence : si dpkg plante lamentablement avant d’avoir retiré le verrou, on se retrouve avec un verrou résiduel qui n’a plus lieu d’être. Ça peut arriver par exemple si tu as éteint violemment ta machine alors que dpkg travaillait. Dans ce cas, il faut vérifier que dpkg ne tourne pas est dans ce cas, supprimer le verrou avec la commande rm.

Précisions : installer/désinstaller un programme (ou le virer) a un impact important sur le système. On considère qu’un programme a un impact important s’il peut pénaliser certains utilisateurs de la machine. dpkg est donc clairement dans cette catégorie (et en conséquence, apt aussi). Ainsi toutes ces commandes requierent des droits administrateurs (root). Sous Ubuntu on les acquiert via sudo. C’est la raison pour laquelle on doit soit lancer « apt-get update » dans un terminal root, soit lancer « sudo apt-get install … ». Note que tous les utilisateurs n’ont pas forcément la possibilité d’utiliser sudo. Mais pour simplifier cette distinction, sous ubuntu, l’utilisateur qui a été créé à l’installation peut le faire.

Conclusion : la présence d’un verrou peut être justifiée ou non. On supprime ce verrou comme mentionné par boisdulait quand il est n’est pas justifié.

sudo rm /var/lib/dpkg/lock

Conséquence : on voit que la pose et la dépose de ce verrou n’est pas anodine. Ainsi créer ce fichier requiert des droits root. Si dpkg est lancé sans droits root, il ne peut pas poser ce verrou et donc poursuivre proprement la suite des opérations. Ainsi, oublier le sudo peut engendrer le message

E: Impossible d'ouvrir le fichier verrou /var/lib/dpkg/lock - open (13: Permission non accordée)
E: Impossible de verrouiller le répertoire d'administration (/var/lib/dpkg/). Avez-vous les privilèges du superutilisateur ?

Problème 2 : quand on installe un paquet, on le décompresse et ensuite on le configure. Si le gestionnaire de paquet plante entre ces deux étapes, il n’a pas fini le travail jusqu’au bout et donc le paquet est partiellement installé. On est typiquement dans ce cas quand ce message apparaît :

E: dpkg a été interrompu. Il est nécessaire d'utiliser « sudo dpkg --configure -a » pour corriger le problème

Réponse au problème : dpkg maintient à chaque fois dans quel état est un paquet (est-il décompressé, est-il configuré, est-il présent sur la machine…). Si quand on le relance, il détecte des paquets installés, il demande à être remis à plat typiquement avec la commande :

sudo dpkg --configure -a

Problème 3 : quand on installe un paquet, on décompresse en réalité une archive compressée au bon endroit. Mais parfois il faut au préalable préparer le terrain (avant de décompresser), ou au contraire le niveler :p (après avoir décompresser).

Réponse au problème : un paquet peut contenir des « scripts » qui se déclenchent juste avant ou juste après sa décompression (pre inst ; post inst). Le même principe existe pour une désinstallation (pre rm ; post rm). C’est visiblement dans ceux-ci que tu es allé farfouiller sur la fin, mais normalement tu n’es pas sensé le faire.

apt-get vs aptitude

Ce sont deux outils qui permettent tout deux de manipuler apt. Pour des raisons assez mystérieuses (pour ne pas dire constestables) ubuntu a délibérément décidé de ne plus installer aptitude par défaut sur ses dernières versions, ce qui à mon humble avis n’est pas le meilleur choix. En effet, dans sa résolution de dépendances, aptittude est souvent plus malin qu’apt-get et débloque des situations ou apt-get plante lamentablement.

C’est ce qui t’es arrivé quand tu as lancé :

e:~$ sudo aptitude update
sudo: aptitude: command not found

Ainsi pour résoudre le problème il suffit d’installer la commande aptitude, qui est fournie par le paquet aptitude (c’est quand même bien fait, le paquet porte le nom de la commande qu’il fournit, ils sont vraiment malins chez debian :p)

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install aptitude

Bon il faut bien voir que parfois le nom du paquet est moins intuitif. Mais encore une fois debian a tout prévu, il y a des moteurs de recherche pour toujours trouver quel est le paquet qu’il nous faut (apt-cache, apt-file). Mais bon ça on laisse de côté pour le moment 😉

Bon et mon problème dans tout ça ?

La première bonne nouvelle, c’est que cette longue introduction t’explique ce qui s’est passé jusqu’ici et donc si tu as pris le temps de lire et que tu as compris, si l’erreur se représente, tu sauras la résoudre par toi-même. Bref apt devrait être un peu plus obéissant.

But du jeu : aptitude marchant mieux qu’apt-get, on va lui demander de tout mettre à jour. Je n’ai pas suivi toute la discussion mais si j’ai bien suivi un paquet se désinstalle mal. Pour que je vois où on en est, copie colle le résultat de :

sudo aptitude update
sudo aptitude safe-upgrade

Bonne chance