Echec installation java
Résolu/Fermé
Dropshift
-
20 juil. 2015 à 08:47
mamiemando Messages postés 33072 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 16 avril 2024 - 20 juil. 2015 à 19:12
mamiemando Messages postés 33072 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 16 avril 2024 - 20 juil. 2015 à 19:12
A voir également:
- Impossible de trouver le paquet openjdk-8-jdk
- Mode sans echec - Guide
- Waptrick java football - Télécharger - Jeux vidéo
- Installation chromecast - Guide
- Java apk - Télécharger - Langages
- Ps4 mode sans echec - Guide
1 réponse
mamiemando
Messages postés
33072
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
16 avril 2024
7 747
Modifié par mamiemando le 20/07/2015 à 10:20
Modifié par mamiemando le 20/07/2015 à 10:20
Avec mes faibles connaissances en anglais, je comprends que "openjdk-7-jdk" à besoin de "openjdk-7-jre" pour être installé.
Oui
openjdk-7-jdk --> openjdk-7-jre --> openjdk-7-jre-headless --> tzdata-java --> tzdata
Oui tu as compris le principe, les paquets ont des dépendances en cascade et l'une d'elle bloque.
Sauf que pour le dernier ( tzdata ) j'obtiens ceci :
C'est qu'elle est déjà installée, en vrai c'est une dépendance précédente qui bloque. C'est parce qu'à ce stade tu n'as pas perçu un point important : il faut non seulement que les dépendances soient installées, mais en plus dans la bonne version. Pour en avoir le coeur net tu peux par exemple lancer :
La cause probable de ton problème est un paquet gelé (held) dans une version trop ancienne. Une manière simple pour résoudre ton problème consiste à le dégeler. De manière générale il n'est jamais bon de geler un paquet. Ce peut être nécessaire car une version récente de paquet est manifestement buggué mais c'est tout. Il peut arriver qu'apt décide de geler un paquet pour satisfaire certaines dépendances, mais généralement ce n'est pas un bon choix de sa part et il est toujours possible de trouver une manière de faire sans en geler.
Ce que je te conseille pour résoudre ce genre de problème et éviter qu'il ne se reproduise, c'est te familiariser avec aptitude en mode interactif.
https://www.mistra.fr/tutoriels-linux-outils-debian/tutoriel-linux-apt-migration.html
L'un des intérêts de cette interface est aussi qu'elle permet de "zoomer" sur un paquet (entrée) et de vérifier ses dépendances (en rouge : non satisfaite) et de comprendre ce qui bloque. On peut même zoomer sur cette dépendance (entrée) ou l'installer (
Voici ce que je ferais :
1) mise à jour :
2) si conflit :
3) résoudre les paquets gelés :
4) vérifier que tout ce qui peut être mis à jour va l'être :
5) si c'est bon (= pas de paquets cassés ou gelé) :
6) quitter :
Bonne chance
Oui
openjdk-7-jdk --> openjdk-7-jre --> openjdk-7-jre-headless --> tzdata-java --> tzdata
Oui tu as compris le principe, les paquets ont des dépendances en cascade et l'une d'elle bloque.
Sauf que pour le dernier ( tzdata ) j'obtiens ceci :
C'est qu'elle est déjà installée, en vrai c'est une dépendance précédente qui bloque. C'est parce qu'à ce stade tu n'as pas perçu un point important : il faut non seulement que les dépendances soient installées, mais en plus dans la bonne version. Pour en avoir le coeur net tu peux par exemple lancer :
aptitude show openjdk-7-jre-headless
La cause probable de ton problème est un paquet gelé (held) dans une version trop ancienne. Une manière simple pour résoudre ton problème consiste à le dégeler. De manière générale il n'est jamais bon de geler un paquet. Ce peut être nécessaire car une version récente de paquet est manifestement buggué mais c'est tout. Il peut arriver qu'apt décide de geler un paquet pour satisfaire certaines dépendances, mais généralement ce n'est pas un bon choix de sa part et il est toujours possible de trouver une manière de faire sans en geler.
Ce que je te conseille pour résoudre ce genre de problème et éviter qu'il ne se reproduise, c'est te familiariser avec aptitude en mode interactif.
https://www.mistra.fr/tutoriels-linux-outils-debian/tutoriel-linux-apt-migration.html
L'un des intérêts de cette interface est aussi qu'elle permet de "zoomer" sur un paquet (entrée) et de vérifier ses dépendances (en rouge : non satisfaite) et de comprendre ce qui bloque. On peut même zoomer sur cette dépendance (entrée) ou l'installer (
+).
Voici ce que je ferais :
1) mise à jour :
uU
2) si conflit :
!
3) résoudre les paquets gelés :
gpuis en se plaçant sur la section "paquets maintenus" (+)
4) vérifier que tout ce qui peut être mis à jour va l'être :
U
5) si c'est bon (= pas de paquets cassés ou gelé) :
g
6) quitter :
q
Bonne chance
20 juil. 2015 à 11:35
20 juil. 2015 à 11:48
sudo dpkg --force all --purge <paquet à supprimer>
sudo apt-get clean
sudo apt-get autoclean
sudo apt-get autoremove
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install openjdk-7-jdk
sudo apt-get -f install
Merci pour ton aide !
Modifié par mamiemando le 20/07/2015 à 19:13
Ce que tu as fait a probablement "dégelé" le paquet qui était source de blocage dans ton cas.
Je t'invite à essayer la méthode que je t'ai suggérée si tu venais à rencontrer à nouveau ce problème, car parfois ce que tu proposes ne sera pas faisable (en particulier si cela consiste à purger des paquets essentiels).
Bonne chance