Corrigé, ainsi que deux-trois autres explications en fonction de vos retours à tous.
J’ai également trouvé une commande plus simple pour annuler toutes les actions en attente : aptitude keep ‘!~v’ qui a l’avantage de ne pas dépendre de la version d’aptitude et qui est vachement moins pénible à taper. 
[quote=“syam”]Corrigé, ainsi que deux-trois autres explications en fonction de vos retours à tous.
J’ai également trouvé une commande plus simple pour annuler toutes les actions en attente : aptitude keep ‘!~v’ qui a l’avantage de ne pas dépendre de la version d’aptitude et qui est vachement moins pénible à taper. 
[/quote]
“annuler”, ce n’est pas clair dans mon esprit.
Tu veux dire que dans le cas du tuto : ‘id’, le paquet en question reste présent, n’est pa supprimé ?
Tu m’as dit le contraire, “il ne faut pas contrarier aptitude qui propose de supprimer ‘d’ un paquet installé ‘i’”.
[quote=“ricardo”]“annuler”, ce n’est pas clair dans mon esprit.
Tu veux dire que dans le cas du tuto : ‘id’, le paquet en question reste présent, n’est pa supprimé ?[/quote]
Dans le cas du tuto, effectivement je ne veux PAS supprimer amarok car je l’ai marqué moi-même artificiellement pour suppression (aptitude --schedule-only remove amarok), histoire de montrer ce qui se passe quand le script détecte des actions en attente.
Ça dépend des cas, il faut savoir faire la part des choses.
La première fois que tu as lancé le script tu avais toutes une flopée de paquets en attente (des à installer, des à supprimer, et des cassés, ceux qu’on a réglés en MP à coups d’aptitude keep). Clairement dans ce cas là tu ne voulais pas appliquer ces actions en attente, d’ailleurs ça aurait été impossible à cause des paquets cassés.
La fois d’après quand tu avais uniquement ces 3 paquets en attente de suppression, c’était juste après une mise à jour (réussie) via aptitude. Or, une mise à jour réussie via aptitude ne laisse pas d’actions en attente. C’est donc qu’à l’appel d’aptitude juste après ta mise à jour, il a détecté que ces paquets auto (A) ne servaient plus à rien et pouvaient être supprimés sans danger.
C’est une question de contexte… Autrement dit, il faut toujours chercher à comprendre pourquoi ces actions sont en attente, en fonction de ce que tu as fait précédemment (utilisation de --schedule-only, mise à jour réussie ou ratée, utilisation d’apt-get entre temps qui désynchronise l’état d’aptitude, …). Et quand tu as un doute, il faut regarder à quoi sert tel ou tel paquet (aptitude show) voire même ses dépendances amont et aval.
Comme pour deborphan quoi : la plupart du temps tu voudras suivre ce qu’il te propose de faire mais il y a toujours des exceptions, il faut toujours traiter ces listes de paquets au cas par cas.
J’adorerais pouvoir pondre un script “intelligent” qui se charge de tout, mais malheureusement la gestion des paquets est tellement complexe avec tous ses cas de figure que c’est totalement impossible et même dangereux pour le système si jamais je me plante dans mon algorithme. Du coup je me rabats sur l’option opposée : un script le plus bête possible, qui ne fait que que le strict minimum et te laisse prendre les décisions toi-même.
Et puis bon faut bien l’avouer : dur dur de penser à tout expliquer correctement du premier coup.
Ok !
Que veut dire le mot ‘schedule’ dans le contexte de cette commande ?
J’ai tellement trouvé de traduction que je ne sais pas laquelle est adaptée.
EDIT :
Je reviens à la charge, youkours dans les mêmes lignes, il y a :
...parfois vous voudrez conserver vos paquets en l'état, et [color=#0000FF][b]d'autres fois appliquer ce qu'aptitude propose[/b][/color]...
La commande pour le faire serait un plus pour les “nuls”.
[quote] --schedule-only
Pour les commandes qui modifient l’état des paquets, programme les actions à faire pour plus tard, mais ne les fait pas. Vous pouvez exécuter les actions programmées en lançant aptitude install sans paramètre. Cela revient à faire la sélection correspondante en mode visuel, puis à quitter aptitude normalement.[/quote]
Désinstallation d’amarok = action prévue
[quote=“syam”]# fix-aptitude-dependencies
Recherche des actions prévues et des dépendances cassées…
État Depuis Vers Paquet
id 2.4.3-1+b2 2.4.3-1+b2 amarok[/quote]
Dans ce cas, si tu veux suivre l’action prévue par aptitude : aptitude remove --purge le_nom_du-paquet, il me semble.
Sinon : aptitude keep ‘!~v’
Merci Wetas, comme à mon habitude, tout est marqué mais suffit de le lire 
Bon, je vais sévir si ça continue 
Il est bourré d’erreurs ce script 
Si tu le trouves avec ce lien, appelle-moi “menteur”
Je viens de l’installer sur mon serveur, pendant que ma mémoire est encore tiède, je vérifie si le script est bien passé dans le dossier donné et je ne le vois pas … 
Allez, tu en seras pour l’apéro la prochaine fois.
Oups il fallait lire sbin et non pas bin. 
Oui, j’ai bien sûr compris l’erreur assez vite 
Je l’ai installé sur le serveur (Squeeze), ce qui m’a permis de me rendre compte que aptitude datait encore de lenny, ce que fix- n’aime pas … mis à jour ainsi qu’ajout de deborphan qui n 'était pas installé.
Il me reste encore le dernier truc à contrôler ‘12 orphelins’ que j’essaierai de faire seul comme un grand ce soir.
Alors, les deniers “orphelins” qu’il me reste à traiter (un à la fois) sachant que c’est un serveur (liaison ssh) sous Sqeeze en 32 avec NVIDIA (courrier, www, ftp).
[quote]ricardo@serveur:~$ aptitude show libc6-i386
Paquet : libc6-i386
État: installé
Automatiquement installé: non
Version : 2.11.3-2
Priorité : standard
Section : libs
Responsable : GNU Libc Maintainers debian-glibc@lists.debian.org
Taille décompressée : 9 228 k
Dépend: libc6 (= 2.11.3-2)
Casse: fakechroot (< 2.9-1.1), fakeroot (< 1.12.3), fglrx-glx-ia32 (< 1:9-6-1), gnu-efi (< 3.0e-3), ia32-libs (< 20090804), ia32-libs-gtk (< 20090804), lib32asound2 (<
1.0.20-3), lib32asound2-dev (< 1.0.20-3), lib32bz2-1.0 (< 1.0.5-3), lib32bz2-dev (< 1.0.5-3), lib32ffi-dev (< 3.0.9~rc9-1), lib32ffi5 (< 3.0.9~rc9-1), lib32g2c0 (<
1:3.4.6-10), lib32gcc1 (< 1:4.4.0-7), lib32gfortran3 (< 4.4.0-7), lib32gmp3 (< 2:4.3.1+dfsg-3), lib32gmp3-dev (< 2:4.3.1+dfsg-3), lib32gmpxx4 (< 2:4.3.1+dfsg-3),
lib32gomp1 (< 4.4.0-7), lib32icu-dev (< 4.0.1-3), lib32icu40 (< 4.0.1-3), lib32mudflap0 (< 4.4.0-7), lib32ncurses5 (< 5.7+20090523-1), lib32ncurses5-dev (<
5.7+20090530-1), lib32ncursesw5 (< 5.7+20090530-1), lib32ncursesw5-dev (< 5.7+20090530-1), lib32nss-mdns (< 0.10-3.1), lib32objc2 (< 4.4.0-7), lib32readline5 (<
5.2-5), lib32readline5-dev (< 5.2-5), lib32stdc++6 (< 4.4.0-7), lib32stdc++6-4.4-dbg (< 4.4.0-7), lib32z1 (< 1:1.2.3.3.dfsg-14), lib32z1-dev (< 1:1.2.3.3.dfsg-14),
libc6-dev-i386 (< 2.9-15), nvidia-glx-ia32 (< 185.18.14-2), nvidia-libvdpau1-ia32 (< 185.18.14-2)
Remplace: libc6-dev-i386
Description : Embedded GNU C Library: 32-bit shared libraries for AMD64
This package includes shared versions of the standard C library and the standard math library, as well as many others. This is the 32bit version of the library, meant for
AMD64 systems.
Site : http://www.eglibc.org
[/quote]
casse ???
J’en fais quoi de ce “libc6-i386” : virer, manuel, deborphan -A ?
Ça veut dire que ce paquet est incompatible avec tous ceux listés, par exemple tu ne peux pas avoir libc6-i386 (= 2.11.3-2) et fakechroot (< 2.9-1.1) installés en même temps sur ta machine.
Y’a un truc que je comprends pas : tu dis que ta machine est en 32 bits, mais ce paquet n’est disponible que pour l’architecture AMD64 : packages.debian.org/search?keywords=libc6-i386
T’es sûr que t’es bien sur une machine/installation 32 bits ??
De toutes façons, la question à résoudre c’est : pourquoi ça a été installé ? Tu as des programmes 32 bits à faire tourner (probablement des trucs qui ne viennent pas des dépôts, sinon soit ils seraient en 64 bits soit ils dépendraient de cette lib) ?
Tu as raison, c’est moi qui déconne, mon serveur est en 64 mais comme j’ai l’habitude de le “visiter” en ssh via mon P4, en 32 bits, lui, j’ai fait la confonderie absurditionnelle
Grosse fatigation le Ricardo
EDIT :
J’en déduis donc que ta réponse est : purge ?
Tout nettoyé, serveur propre 
[quote=“syam”]
Avec ce script, plus besoin de s’emmerder : on peut tout marquer en manuel comme un bourrin (aptitude unmarkauto ~i), on supprime le paquet concerné (et seul le strict minimum partira avec, sans toucher aux autres programmes qu’on veut conserver), et enfin on utilise le script pour remettre en place les infos de dépendances automatiques / identifier les orphelins.
Pour la différence avant/après :
aptitude search '~i!~M' -F '%p' | sort > paquets-manuels-avant.txt
fix-aptitude-dependencies
aptitude search '~i!~M' -F '%p' | sort > paquets-manuels-apres.txt
diff -u paquets-manuels-avant.txt paquets-manuels-apres.txt
[/quote]
Question suite à mon fil sur kate/kwrite :
En faisant comme tu le dis plus haut :
aptitude unmarkauto ~i
on marque en manuel TOUS les paquets qui sont installés ?
Si oui, quand on fait ensuite un , ça replace exactement tout comme avant automatiquement, sans se retaper à la main un par un ?
[quote=“ricardo”]En faisant comme tu le dis plus haut :
aptitude unmarkauto ~i
on marque en manuel TOUS les paquets qui sont installés ?
Si oui, quand on fait ensuite un , ça replace exactement tout comme avant automatiquement, sans se retaper à la main un par un ?[/quote]
C’est exactement ça. L’idée c’est qu’en marquant tous les paquets en manuel, quand tu supprimes un paquet alors seul le strict minimum est supprimé avec (dans le cas de kwrite, les méta-paquets qui dépendent de kwrite), et comme il n’y a plus aucun paquet en automatique tu ne risques pas de supprimer “par accident” tout KDE. Une fois la suppression effectuée, lancer le script se chargera de remettre au mieux l’état automatique des paquets restants (clairement ça ne pourra pas être exactement comme avant puisque certaines dépendances auront changé dû à la suppression de kwrite et des méta-paquets, mais c’est tout à fait normal). Si la suppression de kwrite laisse des libs orphelines, elles seront détectées par deborphan et tu pourras les supprimer manuellement.
Ok, je vais faire ça.
je vais supprimer les deux : kwrite et Kate car j’ai le même problème avec les deux. Ensuite, je ne réinstallerai que kate, ce qui sera suffisant.
Ben il est têtu
J’ai eu beau placer tout en manuel, quand je veux ensuite purger kwrite, il me propose encore de virer les autres. J’ai refusé et la seule proposition qui envoie c’est de rétrograder de version.
[code]ricardo@sid-sda8:~$ sudo aptitude unmarkauto ~i
Aucun paquet ne va être installé, mis à jour ou enlevé.
0 paquets mis à jour, 0 nouvellement installés, 0 à enlever et 10 non mis à jour.
Il est nécessaire de télécharger 0 o d’archives. Après dépaquetage, 0 o seront utilisés.
localepurge: Disk space freed in /usr/share/locale: 0 KiB
localepurge: Disk space freed in /usr/share/man: 0 KiB
localepurge: Disk space freed in /usr/share/gnome/help: 0 KiB
localepurge: Disk space freed in /usr/share/omf: 0 KiB
localepurge: Disk space freed in /usr/share/doc/kde/HTML: 0 KiB
Total disk space freed by localepurge: 0 KiB
État actuel : 0 nouveau paquet [-1].
[/code]
[code]ricardo@sid-sda8:~$ sudo aptitude purge kwrite
Les paquets suivants seront ENLEVÉS :
kwrite{p}
0 paquets mis à jour, 0 nouvellement installés, 1 à enlever et 10 non mis à jour.
Il est nécessaire de télécharger 0 o d’archives. Après dépaquetage, 330 ko seront libérés.
Les paquets suivants ont des dépendances non satisfaites :
kde-baseapps : Dépend: kwrite mais il ne sera pas installé.
Les actions suivantes permettront de résoudre ces dépendances :
Supprimer les paquets suivants :
-
kde-baseapps -
kde-plasma-desktop -
kde-standard
Accepter cette solution ? [Y/n/q/?]n[/code]
[code]Les actions suivantes permettront de résoudre ces dépendances :
Réinstaller à une version antérieure les paquets suivants :
-
kwrite [4:4.7.4-2 (now, testing, unstable) -> 4:4.4.5-2 (stable)]
Accepter cette solution ? [Y/n/q/?] n
*** Aucune autre solution disponible ***
[/code]
MOI, JE VEUX LE VIRER
Évidemment qu’il veut virer ces 3 méta-paquets en plus de kwrite :
- kde-baseapps dépend de kwrite
- kde-plasma-desktop dépend de kde-baseapps
- kde-standard dépend de kde-plasma-desktop
Si tu veux supprimer kwrite tu ne peux pas faire autrement, de toutes façons ça ne porte pas à conséquence c’est que des méta-paquets.
La différence en passant tout en manuel c’est que la suppression de ces 3 méta-paquets ne va pas provoquer la suppression de KDE, alors que si tu n’avais pas fait unmarkauto ~i y’a tout KDE qui partait à cause des dépendances automatiques.
Je n’avais pas compris comme ça.
Je fais.
à demain 
Je viens de remarquer quelque chose, à propos des paquets qui apparaissent en “id”, au premier lancement de fix-aptitude-dependencies.
Premier lancement d’aptitude safe-upgrade = paquets à installer + paquets à enlever + paquets à mettre à jour + 1 bug signalé par apt-listbugs.
aptitude hold nom_du_paquet_buggué
Second lancement d’aptitude safe-upgrade = paquets à installer + paquets à mettre à jour.
La liste des paquets à enlever a disparu.
J’ignore si elle reviendra avec la disparition du bug précédemment signalé mais, en attendant, les paquets qui devaient être enlevés à l’origine et ne l’ont pas été se retrouvent en “id”.
Chercher à comprendre…