[quote=“ricardo”]Il t’appartient ce dossier ?
Moi, il était placé dans /root[/quote]
Sans doute que non, même si je l’ai trouvé dans /home. Je vais voir si je peux adapter le rm -r et je reviens dire ce que ça donne.
PS : Ça a fonctionné.
Pour tes paquets posant question, chez moi, avec une Sid super propre maintenant 
, seuls
libgdu0 et python-central sont installés
Tous les autres sont présents mais non installés.
Pompeur, va ! 
J’ai attaqué les orphelins au burin (aptitude show) et au marteau (vérification que les paquets désinstallés n’entraînaient pas la disparition de la moitié du système) et voilà, c’est propre.
# 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...
deborphan : aucune bibliothèque orpheline (2 ignorées).
J’ai juste gardé ttf-sil-gentium-basic qui m’emmenait trop loin dans la vérification des paquets associés et libdvdcss2.
Merci. 
Bah c’est open source hein, je vois pas pourquoi je me ferais ch*er pour rien.
[quote=“wetaskiwin”]J’ai juste gardé ttf-sil-gentium-basic qui m’emmenait trop loin dans la vérification des paquets associés[/quote]aptitude unmarkauto fonts-sil-gentium-basic
aptitude purge ttf-sil-gentium-basic
deborphan -R ttf-sil-gentium-basic 
C’est mieux, il s’en va sans entraîner toute sa bande de potes. 
# aptitude purge ttf-sil-gentium-basic
Les paquets suivants seront ENLEVÉS :
ttf-sil-gentium-basic{p}
0 paquets mis à jour, 0 nouvellement installés, 1 à enlever et 2 non mis à jour.
Il est nécessaire de télécharger 0 o d'archives. Après dépaquetage, 34,8 ko seront libérés.
Voulez-vous continuer ? [Y/n/?] y
(Lecture de la base de données... 117233 fichiers et répertoires déjà installés.)
Suppression de ttf-sil-gentium-basic ...
Heureusement que tu étais là parce que, après une journée de boulot bien remplie, j’ai du mal à faire (voir ?) la différence entre fonts-sil-gentium-basic et ttf-sil-gentium-basic.
Y’a pas vraiment de différence, c’est juste que le paquet change de nom (tous les ttf-* deviennent petit à petit des fonts-*). Donc le temps que ça se stabilise les deux paquets existent mais l’ancien (ttf-) ne contient plus rien à part des dépendances vers le nouveau (fonts-) – un paquet de transition quoi.
J’aime pas trop le principe de collecter des emails, mais de toutes façons Gérard m’a donné une piste : smxi sait se mettre à jour lui-même (je savais pas vu que je l’utilise pas), y’a plus qu’à aller voir comment il est fait… [/quote]
Et passer par : faire-un-paquet-version-complete-t4691.html ?
Ça simplifierais en plus l’installation et l’éventuelle désinstallation.
Oui ça serait une solution idéale, faut juste que j’aie le courage de monter l’architecture pour un dépôt (obligatoire pour des MAJ automatiques)…
Ce sont justement les noms très proches qui me jouent des tours. L’informatique ne supporte pas la lecture en diagonale. 
Pour info :
[ul][li] J’ai migré le script en perl au lieu de shell.
Avantage : ça sera beaucoup moins compliqué pour moi à maintenir.
Inconvénient : il va falloir modifier votre fichier de config /etc/apt/fix-aptitude-dependencies.conf[/li]
[li] J’ai enfin fait un .deb, à l’avenir ça vous simplifiera l’installation / mise à jour / suppression.[/li][/ul]
Concrètement pour migrer depuis l’ancienne version vers la nouvelle :
[code]# rm /usr/local/sbin/fix-aptitude-dependencies
aptitude install debianutils libappconfig-perl libreadonly-perl libreadonly-xs-perl deborphan ncurses-bin
wget https://github.com/syam44/fix-aptitude-dependencies/raw/master/fix-aptitude-dependencies.deb
dpkg -i fix-aptitude-dependencies.deb
rm fix-aptitude-dependencies.deb[/code]
Pendant l’installation du paquet avec dpkg il vous avertira d’un conflit concernant le fichier de configuration. Il faut installer la version du responsable du paquet (Y).
Ensuite, recopiez à la main les différentes sections de votre ancienne configuration (/etc/apt/fix-aptitude-dependencies.conf.dpkg-old) dans le nouveau fichier (/etc/apt/fix-aptitude-dependencies.conf). Je pense que le nouveau format est assez explicite, il ne devrait pas y avoir besoin d’expliquer en détails mais en cas de problème n’hésitez pas à demander. Vous pouvez aussi regarder mon fichier de config pour prendre modèle dessus.
Promis, c’est la dernière fois que je change le format du fichier de config, mais malheureusement le passage à perl ne m’a pas laissé beaucoup de choix.
Fait mais j’attends qq mn pour tester car j’ai un cron qui doit être effectué au quart (rien à voir avec fix).
Réponse après test.
Test concluant, essai avant et après reboute = no problem
Super. De mon côté j’envisage de faire un vrai dépôt Debian à mettre dans le sources.list, mais c’est plus compliqué que prévu à héberger sur github (idéalement j’aurais aimé que le dépôt soit versionné en même temps que tout le reste). Ça va venir…
Pas mal ce neologisme, je retiens et je cultiverai à l’occasion
Il est pourtant très courant en informatique.
Versionner / versionnage / …
Ce sont en effet des termes informatiques tout à fait corrects et acceptés :
Je regrette Martin mais je n’ai trouvé ce verbe dans aucun dictionnaire français de France.
Qu’il soit accepté au Québec, je comprends, qu’il soit présent dans des ouvrages informatiques, je comprends aussi mais je suis preneur si vous m’indiquez un dictionnaire français qui l’accepte.
Il est fort possible qu’il “entre” prochainement chez Larousse, Robert ou Littré mais je ne l’y ai pas encore vu.
Même Reverso ne connait pas. Wictionnaire non plus.
Par contre, on trouve “partitionner” avec la mention 'informatique’
Cela dit, je n’en fais pas un combat et je trouve ce verbe parfaitement digne de figurer.
Salut,
Cool de faire du perl. J’aurais juste 3 remarques :
[ul]
[li]pourquoi tu n’utilise pas die ?[/li]
[li]pourquoi tu fait une méthode trimArrayLR là où un
suffirait[/li]
[li]j’aurais préféré yaml comme format de fichier de configuration[/li][/ul]
La sortie est trop verbeuse à mon goût.
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.
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. 