Avoir le bon comportement avec paquet cassé lors d'une mise a jour

[Grhim]

Salut à tous ,

cela arrive parfois que lors d'une mise a jours system Debian une mise a jours est bloqué a cause d'un paquet defectueux ..

je ne suis pas un ultra expert mais je me suis toujours debrouiller avec les tutos et aides de forums, notre cher forum inclus .

suivant ceci :

Code : Tout sélectionner

┌──(Grhim㉿kali)-[~]
└─$ sudo apt full-upgrade
[sudo] password for Grhim: 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Error!
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 ca-certificates-java : Breaks: openjdk-17-jre-headless (< 17.0.8~6-3~) but 17.0.6+10-1 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.

le bon comportement serait lequel ? supprimer openjdk puis faire la mise a jour de ca-certif ?

cependant aujourd'hui j'ai pu faire le full-upgrade via aptitude safe* , donc pour ce coup-ci c'est bon

Code : Tout sélectionner

┌──(Grhim㉿kali)-[~]
└─$ sudo aptitude safe-upgrade 
[sudo] password for Grhim: 
Resolving dependencies...                
open: 3970; closed: 7548; defer: 2234; conflict: 13                                                                                                                                                                                        .The following NEW packages will be installed:
  cpp-13{a} fonts-dejavu-mono{a} g++-13{a} gcc-13{a} gcc-13-base{a} kismet-capture-hak5-wifi-coconut{a} libavcodec-extra60{a} libavfilter9{a} libavformat60{a} libavutil58{a} libblockdev-crypto3{a} libblockdev-fs3{a} 
  libblockdev-loop3{a} libblockdev-mdraid3{a} libblockdev-nvme3{a} libblockdev-part3{a} libblockdev-swap3{a} libblockdev-utils3{a} libblockdev3{a} libbytesize-common{a} libbytesize1{a} libcodec2-1.1{a} libconfig++9v5{a} 
  libffado2{a} libgcc-13-dev{a} libgeos3.12.0{a} libhwasan0{a} liblc3-1{a} libnvme1{a} libobjc-13-dev{a} libplacebo292{a} libpostproc57{a} libsframe1{a} libspatialite8{a} libstdc++-13-dev{a} libsuperlu6{a} libswscale7{a} libvpl2{a} 
  libwebsockets19{a} systemd-dev{a} 
The following packages will be REMOVED:

tout éclaircissements est le bien venu

[lol]

le bon comportement serait lequel ?

Ne pas faire du full-upgrade à tout bout de champ,, car c'est le meilleur moyen de tout casser ?

En ce qui me concerne le full-upgrade c'est uniquement lors d'un changement de release.
Au quotidien je me contente d'apt upgrade.

Je n'utilise (quasi) jamais aptitude. A part pour chercher une solution à un problème de paquet cassé.
Évidemment ça n'arrive jamais sur mes stables d'avoir un paquet cassé.

Pour avoir un paquet cassé sur une stable il faut le faire exprès...
J'ai plusieurs serveurs en prod qui tournent depuis des années sur lesquels je n'ai jamais eu de problème de paquets cassés malgré deux changement de release (Buster > Bullseye > Bookworm).

[vv222]

Code : Tout sélectionner

The following packages have unmet dependencies:
 ca-certificates-java : Breaks: openjdk-17-jre-headless (< 17.0.8~6-3~) but 17.0.6+10-1 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.

le bon comportement serait lequel ? supprimer openjdk puis faire la mise a jour de ca-certif ?

Cette erreur est liée à un état incohérent des dépôts de la distribution utilisée. Face à ce genre d’erreur, il y a plusieurs approches possibles :

• comme le suggère lol, ne pas utiliser apt full-upgrade là où apt upgrade suffit ;
• lancer un apt update, et réessayer ;
• attendre que la situation soit corrigée au niveau des dépôts ;
• ne pas utiliser de distributions bancales comme Kali ou Debian testing, privilégier des distributions robustes comme Debian stable et Debian Sid.

[Grhim]

@lol ok , je prend note de cela .

@vv222 points très intéressants, merci.

il y a quelques mois Burp ne voulais plus se lancer car il lui fallait le jre-17 et restait en 16*, j'ai donc installer jre-17 a partir des dépôts. il arrive qu'avec Kali il se passe se genre de petit soucis passager de temps en temps.

pour le point

ne pas utiliser de distributions bancales comme Kali ou Debian testing, privilégier des distributions robustes comme Debian stable et Debian Sid.

je suis tomber sur le fameux debian SID versus debian Testing http://unix.stackexchange.com/questions/20513/ddg#20593

c'est mitiger, il faudrait donc utiliser SID lorsque l'on sais se dépatouiller tout seul en cas de problème sinon c'est testing et stable qui est privilégier .

Stable est solide comme le roc. Il ne se casse pas.

Les Testing se cassent moins souvent que l'instable. Mais lorsqu'il y a des pannes, il faut beaucoup de temps pour que les choses soient rectifiées. Parfois, cela peut prendre des jours, parfois des mois.(voir https://www.debian.org/doc/manuals/debi ... ng.fr.html point 3.1.7

Unstable change beaucoup et peut tomber en panne à tout moment. Cependant, les corrections sont souvent effectuées en quelques jours et il y a toujours les dernières versions des logiciels empaquetés pour Debian.

L'utilisation d'un système instable implique que vous "sachiez ce que vous faites". Vous devez être en mesure de résoudre les problèmes s'ils surviennent. Unstable a tendance à se casser occasionnellement de manière importante. Tout le monde n'a pas ce niveau d'expertise. En général, je conseille aux gens d'utiliser testing, qui n'a pratiquement jamais les problèmes majeurs d'unstable, puisque les problèmes avec les paquets sont généralement détectés lors de leur passage dans unstable. Je pense que c'est un cas de, si vous devez demander, vous ne devriez pas le faire :-) De plus, il est préférable d'utiliser testing vers la fin du cycle de publication, une fois qu'il est gelé et en route pour devenir le prochain stable.

je me demande si il ne faudrait pas utiliser la stable et rajouter du sid et testing pour certains paquets pluss à jours .

perso tout les deux trois an sous SID avec les driver Nvdia et à un moment ...tout foirait , obliger de supprimer les driver proprio , les backports, etc... et donc je suis depuis en testing et pas vraiment de prob...pour l'instant .

pour finir c'est tout de même SID>Testing>stable a part pour les paquets super à jour pourquoi SID serait plus Solide que Testing ... ? https://www.debian.org/doc/manuals/debi ... ng.fr.html voir le point 3.1.8

[vv222]

a part pour les paquets super à jour pourquoi SID serait plus Solide que Testing ... ?

Sid est la version de développement de Debian, c’est sur celle-ci (et uniquement sur celle-ci) que sont testés les nouveaux paquets et nouvelles versions de paquets rejoignant les dépôts Debian (hors mises-à-jour de sécurité à destination de Debian stable).

Testing est automatiquement construite à partir de Sid, sans contrôle humain pour s’assurer qu’elle fonctionne correctement. En-dehors des rapports de bug de la part des utilisateurs, le seul moment où testing est réellement testée c’est lors du freeze préparant son passage en stable.

En cas de bug détecté sur Sid ou sur testing, le correctif est toujours envoyé sur Sid en premier. Il n’arrivera sur testing qu’après plusieurs jours. Ce délai n’est pas raccourci dans le cas de correctifs de sécurité, et est de plus remis à zéro à chaque mise-à-jour du paquet dans Sid. Dans le meilleur des cas, une testing c’est une Sid avec 5 jours de retard sur les mises-à-jour et correctifs. Dans la pratique, ça peut facilement devenir plusieurs semaines voire plusieurs mois pour certains paquets.

[piratebab]

Je suis en testing, et ne fait que ded apt full-upgrade.
Je n'ai que exceptionnellement de paquets cassés.Dans ce cas, je suis patient ça se résous en quelques jours.
si ça reste coincé trop longtemps, je désinstalle le ou les paquets qui bloquent, jusqu'à ce que le full upgrade passe. Puis je réinstalle les paquets que j'ai supprimés (soit le jour même , soit quelques jours plus tard).
si çacoince toujours, je lance une recherche internet sur ce paquet. Il arrive qu'il ai disparu et soit remplacé par un autre (comme youtube-dl il y a quelques temps).

[lol]

Salut,

Je suis en testing, et ne fait que ded apt full-upgrade
...

Il faut dire que Debian, même en testing qui est bien casse gueule, est tout de même plus costaud que Kali...

Pour moi Kali ça ne s'upgrade pas. Quand une nouvelle version sort tu l'installes et tu l'utilises "as it"
Le troll du mardi: Un peu comme Ubuntu...

[piratebab]

j'ai toujours utilisé backtrack en live uniquement. Et je ferais pareil si un jour j'ai besoin de kali (je n'utilise ces outils que ce pour quoi ils sont conçus: du pentest).
Installer ce genre d'outils en dur, et s'en servir au quotidien pour surfer sur internet est un non sens, ce n'est pas fait pour ça.
bon bon, aprés tout, certains se servent bien d'ubuntu au quotidien à grand coup de sudo .....

[Grhim]

j'ai toujours utilisé backtrack en live uniquement. Et je ferais pareil si un jour j'ai besoin de kali (je n'utilise ces outils que ce pour quoi ils sont conçus: du pentest).
Installer ce genre d'outils en dur, et s'en servir au quotidien pour surfer sur internet est un non sens, ce n'est pas fait pour ça.
bon bon, aprés tout, certains se servent bien d'ubuntu au quotidien à grand coup de sudo .....

Effectivement, d'ailleurs je ne l'utilise en aucuns cas pour de l'administration quotidienne ou surfing on the web.

[lol]

Re,

apt full-upgrade est l'équivalent de apt dist-upgrade
C'est plus agressif que apt upgrade comme approche et ça prend en compte les paquets dont les dépendances auraient été modifiées.
Bien entendu ça installe tous les nouveaux paquets nécessaires dans les dépendances ET enlève ceux qui seraient en conflits.


Sur un serveur en production ce n'est pas conseillé car c'est plus casse-gueule.
Sur une machine de bureau c'est évidemment moins emmerdant...