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

Trucs et Astuces
#101

La sortie est trop verbeuse à mon goût.[/quote]
Ok

De mémoire, au départ j’avais besoin du chomp pour nettoyer les résultats de qx{} (si je ne m’abuse ta regex ne traite pas les retours chariot ?) et je déteste me répéter donc j’ai bêtement collé ça dans une fonction que j’ai réutilisée partout.
Et puis honnêtement c’est pas super lisible pour moi ta suggestion, j’ai encore un peu de mal avec les “perlismes” trop compacts.[/quote]
Je comprends (même si c’est juste une regex et du map). Par contre oui ça gère les retours à la ligne, comme tout caractère séparateur.

J’avoue que je ne connais pas vraiment YAML. Je voulais pouvoir intégrer facilement des commandes shell dans le truc (donc il me fallait des variables multilignes qui ne nécessitent pas d’échapper des caractères à tout va) et AppConfig faisait l’affaire avec sa syntaxe HEREDOC, du coup j’ai pas cherché plus loin. :083 [/quote]
Je comprends c’est juste dommage de prendre un format assez spécifique et qui oblige à repasser derrière car il ne gère pas les listes (mais YAML peut être contraignant pour intégrer un script shell).

#102

@ricardo: j’ai corrigé un bug d’affichage concernant le comptage des paquets ignorés par deborphan (fix-… affichait toujours 1 suite à une erreur idiote de ma part).

C’est bien ça mon problème : en regardant ton bout de code je ne comprends pas immédiatement ce qu’il fait, je dois passer par une étape “décodage” et comme tu le sais c’est mauvais signe pour la maintenabilité. :wink: Du coup je serais quand même obligé de l’envelopper dans une fonction histoire de lui donner un nom.
Ne pas oublier que je débute en Perl, d’ailleurs ça doit se voir dans le code à certains endroits… :083

#103

C’est bien ça mon problème : en regardant ton bout de code je ne comprends pas immédiatement ce qu’il fait, je dois passer par une étape “décodage” et comme tu le sais c’est mauvais signe pour la maintenabilité. :wink: Du coup je serais quand même obligé de l’envelopper dans une fonction histoire de lui donner un nom.[/quote]
Ça peut toujours se mettre dans une fonction. Bien qu’il y ai toujours un tas de manière de faire en perl, je te propose du coup autre chose : tu définie une méthode trim qui gère une ou plusieurs arguments et tu l’utilise avec map :

C’est plus flexible et ça reste compréhensible;

Personnellement mes remarques ne sont que des questions de choix et de goût.

#104

[quote=“syam”]@ricardo: j’ai corrigé un bug d’affichage concernant le comptage des paquets ignorés par deborphan (fix-… affichait toujours 1 suite à une erreur idiote de ma part).
[/quote]
Oui, il me semble que nous en avions parlé lors de ma première install.
En tous cas, beau travail et, comme toujours avec toi, tuto a suivre à la lettre :023

#105

J’ai un peu ramé pour reporter la liste des “manual-packages” dans le nouveau fichier de configuration mais j’ai fini par comprendre qu’il valait mieux ne pas le recopier à l’identique et maintenant, tout baigne. Impec !
Merci.

#106

J’ai un peu ramé pour reporter la liste des “manual-packages” dans le nouveau fichier de configuration mais j’ai fini par comprendre qu’il valait mieux ne pas le recopier à l’identique et maintenant, tout baigne. Impec !
Merci.[/quote]
Moi j’ai copié/collé sur l’ancien et ça a fonctionné du 1er coup.

#107

J’ai d’abord gardé la forme manual-packages =“acpid audacity digikam enblend gimp konversation libmarblewidget12 vim-common” mais il n’a pas aimé : erreur ligne 31.
La liste après “aptitude” (qui figure déjà), c’est mieux. Comme ici :
https://www.debian-fr.org/aptitude-gestion-des-dependances-et-orphelins-t35575.html#p359323

#108

Oui, c’est comme ça aussi chez moi.

#109

[quote=“wetaskiwin”]J’ai d’abord gardé la forme manual-packages =“acpid audacity digikam enblend gimp konversation libmarblewidget12 vim-common” mais il n’a pas aimé : erreur ligne 31.
La liste après “aptitude” (qui figure déjà), c’est mieux. Comme ici : https://www.debian-fr.org/aptitude-gestion-des-dependances-et-orphelins-t35575.html#p359323[/quote]
Je viens de tester, la syntaxe que tu as essayée ne pose aucun problème :

Tu n’aurais pas laissé le EOF à la suite par hasard ? :wink: (j’ai enlevé les commentaires pour plus de clarté, mais quand ils y sont c’est bien ligne 31 que se trouve le EOF en trop)

manual-packages = "aptitude plasma-desktop alsa-utils acpi-support-base amarok audacity konversation kopete python3.1" EOF # <==== PROBLÈME ICI[quote]ERREUR : le fichier de configuration « /etc/apt/fix-aptitude-dependencies.conf » est incorrect. EOF: no such variable at /etc/apt/fix-aptitude-dependencies.conf line 31[/quote]
Cela dit, bien que la syntaxe “entre guillemets, tout sur une seule ligne” fonctionne, je préfère quand même la syntaxe <<HEREDOC qui me paraît plus claire au final : au moins on peut mettre un paquet par ligne, et c’est similaire aux deux autres sections ce qui ne gâche rien.

#110

Ben si. Evidemment ! :smiley:
En dépit de son nom, je ne sais pas où doit se mettre ce “End of File”. J’aurais dû garder une trace du message d’erreur complet mais comme j’avais trouvé une solution entre temps… Cela dit, je suis bien d"accord avec toi sur le fait que la liste en colonne est à la fois plus facile à compléter et plus lisible.

À propos de cette liste, d’ailleurs : est-ce qu’il faut la vider de temps en temps pour vérifier si tous ses composants ont toujours besoin d’y être ? En effet, j’ai lancé ton script une première fois sans avoir modifié le fichier de configuration et libmarblewidget12 n’apparaît plus dans la liste des dépendances circulaires alors que libmarblewidget13 (son remplaçant ?) n’y est pas non plus.

#111

Ben si. Evidemment ! :smiley:
En dépit de son nom, je ne sais pas où doit se mettre ce “End of File”.[/quote]
C’est la syntaxe HEREDOC classique (comme en shell) : le marqueur de début est <<MARQUEUR, et le marqueur de fin est MARQUEUR sur la première colonne d’une nouvelle ligne (ici, j’ai choisi MARQUEUR = EOF mais ça pourrait être n’importe quoi d’autre).

Moi c’est plus deborphan que je vide de temps en temps pour revérifier (deborphan -L puis -R), mais rien ne t’empêche de faire pareil pour la liste des paquets manuels / circulaires.
Par contre je trouve un peu étonnant de mettre une lib dans cette liste, rien ne t’en empêche bien sûr mais dans l’esprit c’est plutôt fait pour les paquets “principaux” de programmes (sachant que n’importe quel paquet d’un cycle de dépendances équivaut à un autre du même cycle, autant mettre le programme plutôt qu’une de ses dépendances).

#112

Moi c’est plus deborphan que je vide de temps en temps pour revérifier (deborphan -L puis -R), mais rien ne t’empêche de faire pareil pour la liste des paquets manuels / circulaires.
Par contre je trouve un peu étonnant de mettre une lib dans cette liste, rien ne t’en empêche bien sûr mais dans l’esprit c’est plutôt fait pour les paquets “principaux” de programmes (sachant que n’importe quel paquet d’un cycle de dépendances équivaut à un autre du même cycle, autant mettre le programme plutôt qu’une de ses dépendances).[/quote]
Sauf si tu code. J’ai ds biblio qui sont installées et utilisées par aucun programme de mon gestionnaire de paquets. J’ai un ami qui me montre ce qu’il arrive à faire avec les EFL par exemple (du coup j’ai pas installé les versions *-dev juste les lib normal).

#113

D’où l’utilité d’utiliser deborphan pour ça. :wink:
Bien que la variable manual-packages puisse aussi servir de “deborphan du pauvre”, l’idée de base était plutôt de ne s’en servir que pour les paquets appartenant à des dépendances cycliques, afin de casser les cycles.

#114

Euh… sûrement… si tu le dis… :whistle:
Je suis déjà incapable de te dire pourquoi et/ou comment libmarblewidget12 est arrivé dans ma liste. :doh:

#115

[quote=“syam”]D’où l’utilité d’utiliser deborphan pour ça. :wink:
Bien que la variable manual-packages puisse aussi servir de “deborphan du pauvre”, l’idée de base était plutôt de ne s’en servir que pour les paquets appartenant à des dépendances cycliques, afin de casser les cycles.[/quote]
A ok c’est ce que je fais puisque je n’utilise pas ton script (j’ai une excuse : je suis en stable).

#116

Il peut être très pratique aussi si tu testes (install puis désinstall) souvent beaucoup de paquets.

#117

[quote=“syam”]…
Moi c’est plus deborphan que je vide de temps en temps pour revérifier (deborphan -L puis -R), …[/quote]

Tu peux expliquer stp !
Le man n’est pas clair pour moi :

[code]-L, --list-keep
Affiche la liste des paquets à conserver.

   -R, --del-keep PKG1...PKGn
          Supprime des paquets de la liste des paquets à conserver. En utilisant -, l'entrée standard sera utili‐
          sée pour indiquer les paquets. Si aucune dépendance pour ces paquets n'est trouvée lors de la prochaine
          exécution de deborphan, ils seront affichés.

[/code]

-L : veut dire qu’il teste si des paquets placés ici ne devraient plus y être ?

EDIT :
Ou en réfléchissant un peu plus, le contraire ?

#118

Pour ajouter un paquet à la liste deborphan des ignorés, tu utilises deborphan -A.
Pour vider cette liste des ignorés, il faut d’abord connaître son contenu (deborphan -L) puis supprimer les paquets concernés de la liste (deborphan -R).
Ensuite tu relances soit deborphan (avec les bonnes options) soit fix-aptitude-dependencies et il te dira quels sont les paquets orphelins sans en ignorer aucun puisque ta liste d’ignorés sera vide. Charge à toi de voir si tu veux toujours les conserver (deborphan -A) ou si tu décides de les supprimer (aptitude remove).

#119

Il peut être très pratique aussi si tu testes (install puis désinstall) souvent beaucoup de paquets.[/quote]
Je viens de vérifier, je croyais qu’il n’était pas compatible avec le aptitude de stable 0.6.3, je regarderais à l’occasion.

#120

OK, c’est donc ce que j’avais compris au départ, ça ne fais rien d’automatique, ça liste mais ça te laisse le soin de décider : je garde ou je jette.
Tu sais ce qu’il te reste à faire … un script qui automatise tout ça :laughing: :laughing: :laughing: