[Script] Aptitude : gestion des dépendances et orphelins

[Golmut]

Merci Syam pour toutes ces explications!
j’ai donc mis tout à “plat” avec ta commande:

[code]root@debian:~# apt-cache policy aptitude
aptitude:
Installé : 0.6.6-1+b1
Candidat : 0.6.6-1+b1
Table de version :
*** 0.6.6-1+b1 0
990 http://ftp2.fr.debian.org/debian/ sid/main amd64 Packages
100 /var/lib/dpkg/status
0.6.6-1 0
980 http://ftp2.fr.debian.org/debian/ testing/main amd64 Packages
0.6.3-3.2+squeeze1 0
970 http://ftp2.fr.debian.org/debian/ stable/main amd64 Packages
root@debian:~# aptitude keep $(aptitude search ‘~ainstall|~areinstall|~aupgrade|~adowngrade|~aremove|~apurge’ -F ‘%p’)
Aucun paquet ne va être installé, mis à jour ou enlevé.
0 paquets mis à jour, 0 nouvellement installés, 0 à enlever et 5 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

Total disk space freed by localepurge: 0 KiB

root@debian:~# fix-aptitude-dependencies
Recherche des actions prévues et des dépendances cassées…

État Depuis Vers Paquet

iB 3:11.2.202.233 3:11.2.202.233 flashplayer-mozilla
pB 1:2.8.3 flashplugin-nonfree
pB 0.7.pristine-2 freedesktop-sound-theme
pB 0.4.1-1 gnome-sushi
pB 2.8.4.forreal- libarchive1
pB 2.4.25-1~bpo60 libgmime2.4-cil
pB 1.10.0-1 tomboy
pB 1:0.4.2-4+b3 xserver-xorg-video-fbdev
pB 10.0.4esr-2 xulrunner-10.0

ATTENTION : fix-aptitude-dependencies ne peut pas continuer. Veuillez appliquer ou annuler les actions prévues, et résoudre les dépendances cassées avant de relancer fix-aptitude-dependencies.
[/code]

Apparemment tout n’est pas encore tout plat!
Mes problèmes viennent peut être effectivement du fait qu’il m’arrive de temps en temps de pas utiliser exclusivement aptitude, mais parfois apt-get voir même synaptic et jamais eu de problème de dépendance et/ou de paquets cassés… je précise que j’utilise un sources-list au carré avec pinning et épingle tous paquets bugués en tapant la lettre p (avec apt-listbugs). Peut-être que cela n’a rien à voir? Je fais que des suppositions…

merci.

[syam]

Oups j’en avais oublié un bout : les paquets cassés ne répondent pas aux motifs de recherche ~a… car l’état cassé (~b) semble prendre le dessus.
J’ai corrigé dans mon message précédent la ligne de commande à utiliser, ce qui donne pour toi (aptitude >= 0.6.6) :

[Golmut]

le script se lance correctement maintenant:

[code]root@debian:~# fix-aptitude-dependenciesRecherche des actions prévues et des dépendances cassées…
Marquage des paquets en « Automatique » en fonction des dépendances des paquets…
Recherche des dépendances circulaires…

ATTENTION : des paquets marqués en « Automatique » contiennent des dépendances circulaires.

État Version Paquet

i 0.0.0+r11339-1 0ad
i 0.0.0+r11339-1 0ad-data
i 0.0.0+r11339-1 0ad-data-common
i 2.0b4-12 bsh
i 2.0b4-12 bsh-gcj
i 1.6-1 childsplay
i 0.9.1-2 childsplay-alphabet-sounds-fr
i 12.01-1 gcompris
i 12.01-1 gcompris-data
i 12.01-1 gcompris-sound-fr
i 0.1.18-3 grilo-plugins-0.1
i 3.12.2-1 hpijs-ppds
i 0.20111110-1 intel-microcode
i 0.8.2-6 libgpod-common
i 0.8.2-6 libgpod4
i 0.1.18-2 libgrilo-0.1-0
i 1.17-13.2 microcode.ctl
i 3.12.2-1 printer-driver-hpijs
i 2.96-4 rhythmbox
i 2.96-4 rhythmbox-data
i 2.96-4 rhythmbox-plugins
i 1:0.9.21-1.1 tuxpaint
i 1:0.9.21-1.1 tuxpaint-data
i 2009.06.28-1 tuxpaint-stamps-default
i 568-1 unetbootin
i 568-1 unetbootin-translations
i 1.2.3+repack0- usb-modeswitch
i 20120120-1 usb-modeswitch-data

Les différentes chaînes de dépendances circulaires sont :
* 0ad 0ad-data 0ad-data-common
* bsh bsh-gcj
* childsplay childsplay-alphabet-sounds-fr
* gcompris gcompris-data gcompris-sound-fr
* grilo-plugins-0.1 libgpod-common libgpod4 libgrilo-0.1-0 rhythmbox rhythmbox-data rhythmbox-plugins
* grilo-plugins-0.1 libgrilo-0.1-0
* hpijs-ppds printer-driver-hpijs
* intel-microcode microcode.ctl
* libgpod-common libgpod4
* tuxpaint tuxpaint-data tuxpaint-stamps-default
* unetbootin unetbootin-translations
* usb-modeswitch usb-modeswitch-data
La procédure correcte est de rajouter à la liste « paquets manuels » de fix-aptitude-dependencies.conf au moins un paquet de chaque chaîne de dépendances circulaires afin de casser les cycles de dépendances, puis de relancer fix-aptitude-dependencies pour appliquer la nouvelle configuration. En attendant, ces paquets ont tous été marqués en « Manuel », ce qui n’est probablement pas le résultat souhaité mais permet d’éviter leur suppression accidentelle.

deborphan : 6 bibliothèques orphelines (0 ignorées). Si vous êtes certain(e) que ces paquets ne vous sont pas utiles, vous pouvez les supprimer manuellement.
Pour que ces paquets n’apparaissent plus comme orphelins, utilisez « deborphan -A » (cf. man deborphan).

État Version Paquet

i 0.7.4-2 gstreamer0.10-packagekit
i 0.28-4 libcanberra-gtk0
i 1.2.12-0.1 libdvdcss2
i 2.0.18-stable- libevent-2.0-5
i 295.40-1 libgl1-nvidia-glx-ia32
i 2.0.3-2 ttf-lyx[/code]

Donc si je comprends bien, maintenant, je dois rajouter dans fix-aptitude-dependencies.conf:

MANUAL_PACKAGES="0ad bsh childsplay gcompris grilo-plugins-0.1 hpijs-ppds intel-microcode libgpod-common tuxpaint unetbootin usb-modeswitch"
Puis relancer le script?

[Golmut]

[code]root@debian:~/syam44-fix-aptitude-dependencies-aa361bb# cat fix-aptitude-dependencies.conf
#!/bin/bash

fix-aptitude-dependencies

https://github.com/syam44/fix-aptitude-dependencies

Distributed under the GNU General Public License version 3

https://www.gnu.org/copyleft/gpl.html

Authors: syam (aks92@free.fr)

Description: Fichier de configuration

Explications: https://www.debian-fr.org/aptitude-gestion-des-dependances-et-orphelins-t35575.html

TODO: i18n

#-----------------------------------------------------------------------------

Variables personnalisables

#-----------------------------------------------------------------------------

Liste des paquets à forcer en Manuel, séparés par des espaces, tabulations,

ou retours chariots.

À minima, indiquer ici des paquets possédant des dépendances circulaires

(par exemple, tasksel pour le groupe tasksel et tasksel-data) faute de quoi ces

paquets seront tous marqués en Manuel et le script grognera à chaque exécution.

Pas d’inquiétude à avoir, ce script vous avertira dans tous les cas pour que

vous puissiez rajouter les paquets correspondants dans cette liste.

Vous pouvez aussi indiquer ici les paquets que vous souhaitez absolument garder

en Manuel quoi qu’il arrive (notamment pour éviter que la désinstallation d’un

métapaquet n’entraîne la désinstallation automatique d’un paquet important).

MANUAL_PACKAGES=“0ad
bsh
childsplay
gcompris
grilo-plugins-0.1
hpijs-ppds
intel-microcode
libgpod-common
tuxpaint
unetbootin
usb-modeswitch”

Fonction appellée à la fin du script si tout s’est bien passé, permettant d’ajouter

des nettoyages personnalisés (par exemple « aptitude clean »).

user_defined_cleanup()
{

Ne rien faire (erreur de syntaxe sans cette ligne)

true
}

Fonction appellée pour déterminer les paquets orphelins.

Vous pouvez personnaliser le comportement de « deborphan » comme vous le souhaitez,

du moment que la liste retournée ne contient que des noms de paquets (un par ligne).

L’option « --no-show-section » est donc très importante.

user_defined_deborphan()
{
deborphan --ignore-suggests --guess-interpreters --no-show-section
}
root@debian:~/syam44-fix-aptitude-dependencies-aa361bb# fix-aptitude-dependencies
Recherche des actions prévues et des dépendances cassées…
Marquage des paquets en « Automatique » en fonction des dépendances des paquets…
Recherche des dépendances circulaires…

ATTENTION : des paquets marqués en « Automatique » contiennent des dépendances circulaires.

État Version Paquet

i 0.0.0+r11339-1 0ad
i 0.0.0+r11339-1 0ad-data
i 0.0.0+r11339-1 0ad-data-common
i 2.0b4-12 bsh
i 2.0b4-12 bsh-gcj
i 1.6-1 childsplay
i 0.9.1-2 childsplay-alphabet-sounds-fr
i 12.01-1 gcompris
i 12.01-1 gcompris-data
i 12.01-1 gcompris-sound-fr
i 0.1.18-3 grilo-plugins-0.1
i 3.12.2-1 hpijs-ppds
i 0.20111110-1 intel-microcode
i 0.8.2-6 libgpod-common
i 0.8.2-6 libgpod4
i 0.1.18-2 libgrilo-0.1-0
i 1.17-13.2 microcode.ctl
i 3.12.2-1 printer-driver-hpijs
i 2.96-4 rhythmbox
i 2.96-4 rhythmbox-data
i 2.96-4 rhythmbox-plugins
i 1:0.9.21-1.1 tuxpaint
i 1:0.9.21-1.1 tuxpaint-data
i 2009.06.28-1 tuxpaint-stamps-default
i 568-1 unetbootin
i 568-1 unetbootin-translations
i 1.2.3+repack0- usb-modeswitch
i 20120120-1 usb-modeswitch-data

Les différentes chaînes de dépendances circulaires sont :
* 0ad 0ad-data 0ad-data-common
* bsh bsh-gcj
* childsplay childsplay-alphabet-sounds-fr
* gcompris gcompris-data gcompris-sound-fr
* grilo-plugins-0.1 libgpod-common libgpod4 libgrilo-0.1-0 rhythmbox rhythmbox-data rhythmbox-plugins
* grilo-plugins-0.1 libgrilo-0.1-0
* hpijs-ppds printer-driver-hpijs
* intel-microcode microcode.ctl
* libgpod-common libgpod4
* tuxpaint tuxpaint-data tuxpaint-stamps-default
* unetbootin unetbootin-translations
* usb-modeswitch usb-modeswitch-data
La procédure correcte est de rajouter à la liste « paquets manuels » de fix-aptitude-dependencies.conf au moins un paquet de chaque chaîne de dépendances circulaires afin de casser les cycles de dépendances, puis de relancer fix-aptitude-dependencies pour appliquer la nouvelle configuration. En attendant, ces paquets ont tous été marqués en « Manuel », ce qui n’est probablement pas le résultat souhaité mais permet d’éviter leur suppression accidentelle.

deborphan : 2 bibliothèques orphelines (0 ignorées). Si vous êtes certain(e) que ces paquets ne vous sont pas utiles, vous pouvez les supprimer manuellement.
Pour que ces paquets n’apparaissent plus comme orphelins, utilisez « deborphan -A » (cf. man deborphan).

État Version Paquet

i 1.2.12-0.1 libdvdcss2
i 295.40-1 libgl1-nvidia-glx-ia32[/code]

Ai-je mal édité le fichier conf?

[syam]

C’est le mauvais fichier de config que tu as édité : il faut modifier celui dans /etc/apt/fix-aptitude-dependencies.conf
Mis à part ça, tes modifs en elles-mêmes semblent correctes.

Le dossier “syam44-fix-aptitude-dependencies-…” créé par le téléchargement (wget | tar) n’est plus utile une fois que tu as installé le script (./configure install), tu peux le supprimer si tu veux.

[Golmut]

Merci Syam et autant pour moi pour le mauvais fichier de conf
cependant, ton script me trouve de nouvelles dépendances circulaires:

[code]État Version Paquet

i 2.96-4 rhythmbox
i 2.96-4 rhythmbox-data
i 2.96-4 rhythmbox-plugins

Les différentes chaînes de dépendances circulaires sont :
* rhythmbox rhythmbox-data rhythmbox-plugins
[/code]
c’est normal? ton script n’aurait pas dû la détecter la 1ère fois?
je vais rajouter cette dépendance circulaire au fichier conf et relancer le script:

[code]Recherche des actions prévues et des dépendances cassées…
Marquage des paquets en « Automatique » en fonction des dépendances des paquets…
Recherche des dépendances circulaires…
deborphan : 2 bibliothèques orphelines (0 ignorées). Si vous êtes certain(e) que ces paquets ne vous sont pas utiles, vous pouvez les supprimer manuellement.
Pour que ces paquets n’apparaissent plus comme orphelins, utilisez « deborphan -A » (cf. man deborphan).

État Version Paquet

i 1.2.12-0.1 libdvdcss2
i 295.40-1 libgl1-nvidia-glx-ia32 [/code]

Tout semble ok désormais!

[syam]

[quote=“Golmut”]cependant, ton script me trouve de nouvelles dépendances circulaires:
[…]
c’est normal? ton script n’aurait pas dû la détecter la 1ère fois?[/quote]
Il aurait effectivement dû le détecter la première fois. À moins que les dépendances aient changé entre temps (va savoir… c’est tellement embrouillé des fois). Bref, le principal c’est que ça soit stabilisé.

Edit : euh, il l’a détecté la première fois… Si, si, regarde bien.

[ricardo]

Allez, à moi de poser mon problème :
Maj du matin : 3 paquets ‘id’

libopencv-core2.3
""""""""- imgproc2.3
libtbb2

Je fais un 'aptitude keep ~i’
puis re fix…
= 1 orphelin : libopencv-imgproc2.3 avec état = i
Les 5 paquets en dépendant sont tous état = i A
J’en déduis que je dois le deborphaniser A

C’est bon docteur ?

[syam]

Si la mise à jour propose de supprimer ces paquets, c’est qu’ils ne sont plus utiles (d’autant plus que ce ne sont que des bibliothèques, et que deborphan confirme). Pourquoi les conserver à tout prix ?
Le mieux c’est sans doute de faire ce qu’il te propose : aptitude -s remove libopencv-core2.3 libopencv-imgproc2.3 libtbb2 et de voir ce qui se passe précisément.

[wetaskiwin]

Lecture et relecture, en long, en large et en travers, prise de notes au fur et à mesure : j’y suis arrivée !
Sauf que

…Là c’est deborphan qui me prévient qu’une bibliothèque semble orpheline.

Hmm… C’est 'ach’ment propre, chez toi. Je fais quoi avec mes 196 bibliothèques orphelines (Installation datant de plus de 3 ans avec gnome à l’origine + pleins de morceaux de KDE + xfce + suppression de tous les bouts de KDE et de gnome que j’ai pu trouver) ?

[Flo1]

[quote=“wetaskiwin”]Lecture et relecture, en long, en large et en travers, prise de notes au fur et à mesure : j’y suis arrivée !
Sauf que

…Là c’est deborphan qui me prévient qu’une bibliothèque semble orpheline.

Hmm… C’est 'ach’ment propre, chez toi. Je fais quoi avec mes 196 bibliothèques orphelines (Installation datant de plus de 3 ans avec gnome à l’origine + pleins de morceaux de KDE + xfce + suppression de tous les bouts de KDE et de gnome que j’ai pu trouver) ? [/quote]
Là, un petit coup de debfoster d’impose peut-être.

Flo

[wetaskiwin]

J’ai commencé par aptitude search ‘~i!~M’. Instructif ! Plus que 180 orphelines.

Je vais garder debfoster pour un prochain épisode parce que, même si le fil parle de gestion des dépendances et orphelins, j’ai un peu l’impression de le polluer.

[ricardo]

[quote=“syam”]Si la mise à jour propose de supprimer ces paquets, c’est qu’ils ne sont plus utiles (d’autant plus que ce ne sont que des bibliothèques, et que deborphan confirme). Pourquoi les conserver à tout prix ?
Le mieux c’est sans doute de faire ce qu’il te propose : aptitude -s remove libopencv-core2.3 libopencv-imgproc2.3 libtbb2 et de voir ce qui se passe précisément.[/quote]
OK, je viens de comprendre un truc de plus sur lequel je n’avais pas percuté : le ‘d’ en seconde colonne n’est pas une simple information d’état mais une suggestion appuyée de suppression, presque un ordre en quelque sorte.
Je supprime donc et je surveille pour la suite.

@ Wetas :

[quote]Hmm… C’est 'ach’ment propre, chez toi. Je fais quoi avec mes 196 bibliothèques orphelines (Installation datant de plus de 3 ans avec gnome à l’origine + pleins de morceaux de KDE + xfce + suppression de tous les bouts de KDE et de gnome que j’ai pu trouver) ? [/quote]Petit bras, va ! moi j’en avais plus de 500
Tu es bonne pour l’opération que m’a faite Syam samedi
Prépare le café
Tu fais dans le flocon de neige maintenant ? C’est quand même un peu plus gai.

EDIT à Syam :
En fait, je me suis mal exprimé, ce n’est pas aptitude que m’a proposé la suppression des 3 paquets en question, c’est fix-aptitude-dependencies qui les a déclarés 'id".
Ça change quelque chose dans ta proposition ?

[ricardo]

J’ai repris cette partie du tuto et j’ai cherché …

[quote]Bonus : trouver et supprimer tous les paquets désinstallés non purgés

Lors d’un apt-get remove ou aptitude remove les fichiers de configuration des paquets supprimés restent sur le disque (contrairement aux commandes équivalentes utilisant l’option purge).
Pour trouver tous ces paquets “à moitié” désinstallés :
Code:

aptitude search ~c

Si vous voulez purger définitivement tous les paquets concernés :
Code:

aptitude purge ~c

[/quote]

J’en ai un GROS wagon
Parmi ceux-là, beaucoup de lib…, des “Gnome” que j’ai ( ) virés et quelques autres paquets virés sciemment.
Que fais-je, je purge sans problème mais en copiant les noms des paquets purgés ?

[wetaskiwin]

Lors d’un apt-get remove ou aptitude remove les fichiers de configuration des paquets supprimés restent sur le disque

Il me semble de l’option --purge ne les supprime pas toujours mais ça demande confirmation. Et quand aptitude impose la désinstallation de paquets, ils ne sont jamais purgés.
Je me suis donc lancée dans aptitude purge ~c sans trop de craintes, j’ai juste vérifié le nom des paquets, au cas où.

[quote=“ricardo”]Petit bras, va ! moi j’en avais plus de 500
Tu es bonne pour l’opération que m’a faite Syam samedi
Prépare le café
Tu fais dans le flocon de neige maintenant ? C’est quand même un peu plus gai.[/quote]
Je ne sais pas combien il y en avait avant que je commence mon opération “grand ménage” dans Gnome et KDE. Si tu as un mode d’emploi de l’opération pilotée par Syam, ça m’intéresse. J’ai déjà le café.

Pour le flocon de neige, je reste dans le thème “fabrication maison” puisqu’il s’agit de 7 motifs de dentelle crochetée. Tout est dans la façon de les assembler, comme ici (modèle en bas à gauche où le motif individuel n’est pas facilement reconnaissable, une fois associé à d’autres identiques) :
http://www.flickr.com/photos/iamsusie/3194494940/

[syam]

Je fais quoi avec mes 196 bibliothèques orphelines

À toi de voir… Le script ne fait que te retourner les résultats de deborphan, c’est à dire les paquets censés n’être plus utiles. En principe tu peux les supprimer, mais il faut tout de même faire attention aux faux positifs (ils sont rares mais ça arrive tout de même avec deborphan). Le mieux c’est d’y aller doucement, quelques paquets à la fois pour bien voir ce qui se passe. Et si dans le lot il y en a que tu veux conserver bien que deborphan les considère orphelins, il faut lui dire de les ignorer : deborphan -A paquetàignorer
Faut te dire que c’est qu’un mauvais moment à passer (même s’il promet d’être un peu long) : une fois tout remis à plat, si ensuite tu utilises le script régulièrement en “maintenance” tu n’auras plus grand chose à faire au jour le jour.

C’est 'ach’ment propre, chez toi.

Ça fait des années que j’utilise ce script, je l’avais déjà sous *buntu à l’époque donc mes Debian ont toujours été “propres”, en grande partie grâce à ça (et aussi un peu parce que je suis maniaque).

[quote=“ricardo”]OK, je viens de comprendre un truc de plus sur lequel je n’avais pas percuté : le ‘d’ en seconde colonne n’est pas une simple information d’état mais une suggestion appuyée de suppression, presque un ordre en quelque sorte.
[…]
EDIT à Syam :
En fait, je me suis mal exprimé, ce n’est pas aptitude que m’a proposé la suppression des 3 paquets en question, c’est fix-aptitude-dependencies qui les a déclarés 'id".[/quote]
À cette étape, le script ne fait qu’appeler aptitude search, il ne modifie en rien l’état des paquets (d’ailleurs en règle générale, il ne modifie que l’état auto/manuel et ne provoque jamais la suppression de paquets, c’est pour ça d’ailleurs qu’il s’arrête immédiatement si le aptitude search détecte des actions en attente). C’est donc bien aptitude lui-même qui les a marqués pour suppression.
Théoriquement, aptitude est censé supprimer automatiquement les paquets auto (A) qui ne servent plus, suite à une suppression ou à une mise à jour d’un autre paquet. Mais des fois il arrive que cette suppression automatique (qui est tout à fait normale, c’est l’équivalent d’un apt-get autoremove) ne se fasse pas immédiatement mais seulement au prochain appel d’aptitude. Pourquoi, je sais pas trop, j’imagine que lors de la mise à jour proprement dite il n’était pas encore capable de détecter qu’il fallait les supprimer.

Que fais-je, je purge sans problème mais en copiant les noms des paquets purgés ?

Copier le nom des paquets ne te servira pas à grand chose. La question que tu dois te poser avant de purger c’est : est-ce que tu comptes réinstaller ces paquets, et si oui est-ce que tu veux conserver leurs fichiers de configuration en attendant (les fichiers globaux hein, ceux dans le /home ne sont pas affectés). Si tu réponds non à n’importe laquelle de ces deux questions, tu peux purger ces paquets sans problème.

[syam]

Il me semble de l’option --purge ne les supprime pas toujours mais ça demande confirmation.

Pour apt-get je sais pas, mais aptitude ne m’a jamais demandé confirmation quand je purge des paquets.

Et quand aptitude impose la désinstallation de paquets, ils ne sont jamais purgés.

Effectivement. Je pense que c’est une mesure de sécurité : avec un remove “simple”, on peut facilement retrouver l’état précédent à l’identique en réinstallant simplement un paquet. Avec un purge, bah… faut refaire la config.

Si tu as un mode d’emploi de l’opération pilotée par Syam, ça m’intéresse.

C’est grosso modo la même chose dont je t’avais déjà fait un mini-tuto (résolution manuelle des dépendances avec aptitude interactif, à un moment quand c’est trop le bordel je trouve que c’est la méthode la plus fiable même si c’est aussi la plus longue). Chez ricardo, avec le temps et l’utilisation systématique de apt-get upgrade (équivalent à aptitude safe-upgrade je crois) il y avait plein de paquets non mis à jour (par exemple, il était encore en Gnome 2 et KDE 4.6 pour ne citer que ça). Je pense que cette situation venait du fait que apt-get upgrade (ou aptitude safe-upgrade) était incapable de faire ces mises à jour à cause de trop nombreux changements dans les dépendances. KDE a été un peu galère à mettre à jour, mais par contre Gnome3 était tellement bordélique qu’au final il a été supprimé (ricardo ne l’utilisait pas de toutes façons, du coup ça a fait gagner énormément de temps plutôt que d’essayer de résoudre les dépendances manuellement). On y a quand même passé plusieurs heures pour tout remettre à plat…

[wetaskiwin]

Pour apt-get je sais pas, mais aptitude ne m’a jamais demandé confirmation quand je purge des paquets.

Pour mon grand ménage, j’ai systématiquement utilisé aptitude remove --purge le_nom_du_paquet et il est arrivé que certains de ces paquets soient toujours présents lors d’un aptitude purge ~c. J’ai trouvé ça un peu bizarre mais bon, comme j’avais déjà passé l’aspirateur, j’ai fini le boulot avec une serpillière.

À toi de voir… Le script ne fait que te retourner les résultats de deborphan, c’est à dire les paquets censés n’être plus utiles. En principe tu peux les supprimer, mais il faut tout de même faire attention aux faux positifs (ils sont rares mais ça arrive tout de même avec deborphan). Le mieux c’est d’y aller doucement, quelques paquets à la fois pour bien voir ce qui se passe. Et si dans le lot il y en a que tu veux conserver bien que deborphan les considère orphelins, il faut lui dire de les ignorer : deborphan -A paquetàignorer

Je me doutais un peu de la réponse. Je vais peut-être me limiter à l’installation d’une nouvelle stable de secours.

[ricardo]

Merci pour toutes ces réponses détaillées à tous les deux.
J’ai bien compris qu’en somme, on ne risque que de devoir réinstaller un paquet et à le reconfigurer.
Je vais chercher l’huile de ricin de ce pas

@ Wetas : bravo pour ton ouvrage. Si tu as quelques belles photos de ton travail perso et que tu acceptes de les voir sur mon site, je suis preneur.
Pour avoir une “stable” de secours, j’estime que c’est une chose indispensable quand on joue avec Sid/testing.

[ricardo]

Ça y est, la purge a fait son effet, maintenant, c’est juré, MAJ chaque jour

Au fait Syam, je pense qu’il manque une info dans ton script à ce niveau :

[quote]…Pour des raisons de sécurité, le script refusera de faire quoi que ce soit s’il détecte qu’il y a des actions en attente sur certains paquets, ou que des paquets sont cassés. Il vous donne même la liste des paquets concernés…

On corrige donc cela (je dis à aptitude de garder amarok finalement) et on relance le script.
Code:

aptitude keep ~i

fix-aptitude-dependencies

Recherche des actions prévues et des dépendances cassées…
Marquage des paquets en « Automatique » en fonction des dépendances des paquets…
Recherche des dépendances circulaires…
[/quote]
Tu dis “on corrige cela” mais tu ne dis pas comment. Je pense qu’il serait utile de préciser la commande, non ?