Hi,
Je cherche une commande qui permet de vérifier si un paquet est cassé. Déjà… je ne suis pas sûr de ce que l’on entends par “cassé”. C’est un problème de dépendances?
Ensuite, il existe une commande qui permet de lister ces paquetages? J’ai bien trouvé “deborphan”, mais - je n’ai fait qu’entrelire, pour l’instant - il me semble que cela liste les paquetages non utilisés, et non pas cassé.
Merci d’avance 
Salut!
Tu as la commande check qui est un outil de diagnostic.
Il met à jour le cache des paquets et cherche des dépendances défectueuses.
pour plus d’info, fais un apt-get -h. Tu auras la liste des commandes et des options.
ou sinon, avec aptitude et ses fonctions de recherche étendues !$ aptitude search ~b
(b pour broken)
Ah ok… J’avais vu la commande check, en effet, mais je n’étais pas sûr du truc. Par contre, pour bien clarifier ta réponse, le man indique qu’effectivement, cela met à jour le cache des paquets et recherche le paquets deffectueux… bien, donc, tu me le dis si je me trompe, mais en définitif faire un apt-get check reviens à faire un apt-get update + vérification des paquets deffectueux?
Merci pour la commande aptitude. J’utilise essentiellement apt-get et dpkg, mais ça peut clairement être une alternative utile que je vais m’empresser de me noter dans un coin
bizarre. chez moi
apt-get check
ou
aptitude search ~b
n’indique aucun paquet cassé
par contre
dpkg -l | grep ^rc
m’indique qu’il y en a de casser
que faut-il croire ?
Mmmm
Personnellement, j’ai
sh-3.1# aptitude search ~b
iB libxml-libxml-perl - Perl module for using the GNOME libxml2 library
iB libxml-sax-expat-perl - Perl module for a SAX2 driver for Expat (XML::Parser)
iB libxml-simple-perl - Perl module for reading and writing XML
sh-3.1# dpkg -l | grep ^rc
(…)
rc network-manager-gnome 0.6.4-6 network management framework (GNOME frontend)
sh-3.1# dpkg -s network-manager-gnome | grep Status
Status: deinstall ok config-files
sh-3.1# apt-get check
Lecture des listes de paquets… Fait
Construction de l’arbre des dépendances… Fait
sh-3.1#
(là, je n’ai rien)
sh-3.1# apt-get check network-manager-gnome
Lecture des listes de paquets… Fait
Construction de l’arbre des dépendances… Fait
(là non plus)
A priori ce sont des résultats tout à fait différents.
le “rc” indique un paquetage partiellement désinstallé.Je ne sais pas à quoi correspond le “iB”
Synaptic fait ça très facilement aussi. 
Oui c’est l’idée. Mais c’est une recherche des dépendances défectueuses de la liste des paquets
avec en plus une reconstruction des embranchement paquets/dépendances.
rc ne signifie pas cassé mais qu’il reste des fichiers de configuration (i.e. paquets non purgés), ça correspond à ~c dans aptitude
iB signifie installé et avec des dépendances cassées
Ok,
Merci pour le complément d’information!
Ok,
Juste une chose:
apt-get check : recherche des dépendances défectueuses de la liste des paquets
avec reconstruction des embranchement paquets/dépendances.
aptitude search ~b : liste les paquetages dont les dépendances sont défectueuses.
un apt-get check devrait réparer les dépendances deffectueuses, si je comprends bien. Mais si je le lance suivit d’un aptitude search, je retrouve toujours les trois mêmes paquetages :
sh-3.1# aptitude search ~b
iB libxml-libxml-perl - Perl module for using the GNOME libxml2 library
iB libxml-sax-expat-perl - Perl module for a SAX2 driver for Expat (XML::Parser)
iB libxml-simple-perl - Perl module for reading and writing XML
Un apt-get check ou un apt-get --reinstall ne devrait pas corriger le problème, en principe? (ce n’est pas le cas, actuellement).
Lorsque les dépendances sont cassées, cela signifie qu’il y a un (ou des) conflit(s); donc ré-installer un paquet cassé implique souvent d’en supprimer d’autres. aptitude peut gérer cela et te proposer des solutions pour résoudre ces problèmes (au contraire de apt-get).
Mon conseil: lance aptitude en mode interactif (sans argument), (ré-)installe ton paquet cassé (avec +) et tu devrais avoir une barre rouge en bas, qui propose des solutions. Ensuite, tu peux les examiner toutes et choisir celle qui te convient le mieux. Bien sûr tu peux faire cela en ligne de commande aussi…
Il est conseillé (par le projet Debian) d’utiliser aptitude. Tout ce que tu fais avec apt-get, tu peux le faire avec aptitude.
ok… je suis juste un peu méfiant : en effet, si jamais aptitute me lourde un paquetage important pour autre chose, histoire de réparer un paquet par ci… ça risque de finir en galère, non?..
Mais je vais étudier la question. Il est sans doute temps que j’apprenne à bosser sur aptitude (chui un fan d’apt-get and cie, faut dire).
Trop simple! Pas assez mystérieux; et puis on fait ça sous *buntu, ici c’est Debian. C’est comme si tu supprimais l’immaculée conception au catholicisme.
[quote=“sonador”]ok… je suis juste un peu méfiant : en effet, si jamais aptitute me lourde un paquetage important pour autre chose, histoire de réparer un paquet par ci… ça risque de finir en galère, non?..[/quote] C’est ce qu’il y de moins risqué de toute façon. En plus, tu auras toujours la possibilité d’accepter ou non les solutions proposées: faut pas trop se laisser faire par la machine !!!
Trop simple! Pas assez mystérieux; et puis on fait ça sous *buntu, ici c’est Debian. C’est comme si tu supprimais l’immaculée conception au catholicisme.[/quote]Sans vouloir polémiquer, je doute que synaptic (à l’instar d’apt-get) puisse résoudre les problèmes de dépendances aussi bien qu’aptitude.
Un petit exemple pour vous convaincre:
1/ j’installe le paquet emacs22
2/ les dépendances emacs22-bin-common et emacs22-common et emacsen-common sont ajoutées automatiquement
3/ je désinstalle emacs22-common (avec dpkg) pour créer un problème de dépendances
4/ Devinez quoi ! Seul aptitude détecte que le paquet emacs22-bin-common est cassé et propose de le réparer en supprimant emacs22 et emacs22-bin-common… ensuite il me propose gentillement de désintaller emacsen-common qui n’est plus utile !
Dans synaptic ou apt-get check: rien à signaler. Pourtant l’exemple est simple 
+1 avec ursus aptitude a une gestion plus fine des dépendances.
@ sonador fais comme moi joues avec apt, aptitude, dpkg
et aussi synaptic pour faire plaisir à ricardo 
Hi,
En fait, j’ai “joué” avec aptitude, hier. Je ne suis pas encore très à l’aise avec sa manipulation, en tant qu’outil semi-graphique, mais… en effet, j’ai réparé les paquets cassés. Un aptitude ~b ne me renvoie plus rien .
Très intéressant, tout ça!
[quote=“rodmov”]+1 avec ursus aptitude a une gestion plus fine des dépendances.
@ sonador fais comme moi joues avec apt, aptitude, dpkg
et aussi synaptic pour faire plaisir à ricardo [/quote] mais je me sers aussi des trois autres cités. :smt002
Ah ça, je ne vais pas non plus lâcher mes outils préférés.
C’est la folie comme la gestion des paquetages est la grosse force de Debian. Rien n’est plus chiant que de repasser sous une Redhat, après. 
ce n’est pas le sujet exact de ce topic, mais puisque on en parle et que des personnes ont bien voulu répondre, je reste ici pour avoir des précision sur
dpkg -l | grep ^rc ou aptitude search ~c
comment puis-je savoir d’une façon rigoureuse que si je supprime les paquets indiqués par cette commande, je n’affecte pas d’autres paquets (dépendances) ?