Installation de tomcat 7 sous Ubunttu 10.10

Il ne suffit pas de lancer ces commandes ?

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install tomcat7

Bonne chance

Trois explications possibles :
1) Soit tu n'es pas root (ou tu as oublié le sudo),
2) Soit tu as déjà une instance du gestionnaire de paquet qui tourne (par exemple synaptic),
3) Soit tu as quitté salement ton gestionnaire de paquet la dernière fois et il reste un fichier verrou résiduel (/var/lib/dpkg/lock).

Le cas (1) s'explique facilement. Pour fonctionner correctement un fichier (/var/lib/dpkg/lock). doit être créé. Or seul root (l'administrateur) peut écrire dans le dossier /var/lib/dpkg/, donc le programme que tu lances doit avoir des droits suffisant pour écrire dedans (comprendre dans cet exemple : être lancé avec des droits administrateurs, donc dans un terminal root ou par le biais d'un "sudo").

Expliquons maintenant (2) et (3) plus précisément, et voyons comment résoudre ces deux cas.

Tu peux voir facilement si ce fichier "lock" est justifié en regardant quel processus le manipule. Dans l'exemple qui suit, je suis en train de faire une mise à jour avec aptitude (un équivalent d'apt-get) et qui au même titre que synaptic, met en jeu dpkg. Or pour des raisons techniques que je passerai sous silence ici, dpkg ne peut être manipulé que par un processus à la fois (c'est la raison pour laquelle un "verrou" est posé, pour garantir qu'il n'est lancé qu'une fois).

Exemple :

sudo lsof /var/lib/dpkg/lock

... renvoit :

COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
aptitude 3723 root    3uW  REG    8,6        0 130976 /var/lib/dpkg/lock

Ici on retrouve qu'aptitude (identifié par le PID 3723 dans cet exemple) accède à ce fichier. La présence de /var/lib/dpkg/lock dans cet exemple est donc justifiée. Par contre si aucun processus n'était apparu, ça aurait signifié que c'était un fichier résiduel (en d'autre termes, qui aurait dû être supprimé mais qui pour une raison obscure ne l'a pas été).

Un cas typique c'est si tu éteins brutalement ton PC alors qu'il faisait une mise à jour. Du coup ton gestionnaire de paquets (aptitude dans mon exemple) se ferme mal et n'a pas l'opportunité d'enlever le verrou. Du coup, la fois suivante, ton gestionnaire de paquets te dit "hé, y a un verrou". Dans ce cas, aucun gestionnaire de paquets ne serai en train de tourner. Du coup si tu lance la commande lsof dans un contexte comme celui-ci, rien n'apparaîtra, et ça signifiera que tu peux virer le verrou sans risque (il n'a pas/plus lieu d'être) :

sudo rm /var/lib/dpkg/lock

Ceci fait, il ne reste plus qu'à lancer son gestionnaire de paquet (comprendre : synaptic, une commande aptitude ou apt-get, etc...)

Bonne chance