7 astuces pour rapporter les bogues Debian efficacement et voir vos problèmes résolus

Remplir des rapports de bogue constitue la façon la plus courante de contribuer pour les utilisateurs. Bien que cela ne soit pas très difficile, je vais vous donner quelques conseils pour améliorer la qualité de vos rapports. Après tout, lorsque vous prenez du temps pour rapporter un bogue, c’est dans l’espoir de le voir résolu… Alors voyons comment mettre le plus de chances de votre côté.

1. Essayez de reproduire le bug

Si vous ne pouvez pas reproduire le bogue, il sera alors impossible de trouver sa cause d’origine, et par conséquent de le résoudre. Dans ce cas, je vous suggère d’attendre jusqu’à ce que vous ayez rencontré ce bogue plusieurs fois. Vous trouverez peut-être ce qui le provoque (ou ce qui semble favoriser son apparition). Si l’application a un mode debug/verbose, ce serait une bonne idée de l’activer jusqu’à ce que le bug apparaisse une deuxième fois. Les logs générés seront très utiles au développeur pour comprendre ce qui s’est exactement passé.

Par conséquent, ne remplissez pas un rapport de bogue tout de suite, à moins que vous puissiez le reproduire. L’exception à la règle, c’est lorsque l’application donne quelques informations telles qu’un core-dump, une back-trace ou un message d’erreur.

Bien entendu, si le bogue apparaît lors d’une mise à jour, il est difficile de le reproduire (à moins de posséder plusieurs ordinateurs), mais vous devriez tout de même le rapporter. Assurez-vous d’y intégrer toutes les informations qui s’y rapportent (version des paquets avant et après la mise à jour logs de la mise à jour, etc).

2. Faîtes de votre mieux pour identifier le paquet mis en cause

Lorsque vous rapportez un bogue à Debian, vous devez l’assigner à un paquet. Bien qu’il existe des pseudo-paquets utiles pour les problèmes ne se rapportant pas directement à un véritable paquet, dans la plupart des cas vous devrez rapporter le bogue concernant le paquet particulier qui semble être la cause du problème rencontré.

De la même façon, vous devrez autant que possible attribuer le problème à un fichier (par exemple l’exécutable de l’application buggée). À partir du moment où vous connaissez le nom du fichier, vous pouvez utiliser dpkg -S pour identifier le paquet correspondant.

$ dpkg -S /usr/bin/hamster-time-tracker
hamster-applet: /usr/bin/hamster-time-tracker 

Notez que reportbug accepte pour paramètre un nom de fichier et fera la conversion ci-dessus à votre place.

Si vous ne connaissez que le nom de l’application (mais pas le nom du fichier de l’exécutable associé), vous pouvez utiliser dpkg -S avec un motif afin qu’il retourne tous les résultats correspondants :

$ dpkg -S hamster
hamster-applet: /usr/share/applications/hamster-applet.desktop
hamster-applet: /usr/share/gnome/help/hamster-applet/es/statistics.page
[…]
hamster-applet: /usr/bin/hamster-time-tracker
[…]

Ou vous pouvez aussi vérifier dans la liste des paquets installés :

$ dpkg -l "*hamster*"
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
| État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ Nom Version Architecture Description
+++-=========================-=================-=================-=======================================================
ii hamster-applet 2.91.3+git2012051 all time tracking applet for GNOME 

3. Vérifiez que le bogue n’est pas déjà signalé ou résolu

Si une nouvelle version du logiciel est disponible, c’est une bonne idée d’essayer de reproduire le problème aussi avec cette dernière version. Étant donné que les développeurs ont tendance à se préoccuper uniquement de la dernière version, ils essaieront de le reproduire dans cette version, et risquent d’être agacés si le bogue que vous rapportez est déjà résolu. C’est pourquoi les rapports de bogue des utilisateurs de testing/unstable ont tendance à être plus utile que les rapports des utilisateurs de la stable.

Dans tous les cas, vous devrez vérifier que le bogue n’a pas encore été rapporté : créer un doublon est inutile et génère seulement plus de travail pour le développeur qui doit fusionner les deux bogues.

Notez que reportbug vous montrera automatiquement la liste des bogues ouverts avant de vous permettre d’en soumettre un nouveau.

4. Utilisez reportbug

Bien que le système de rapport de bogue Debian permette à quiconque de soumettre un nouveau bug avec un simple mail, vous devriez vraiment utiliser un programme fait pour ça tel que reportbug (ou reportbug-ng) car il inclura automatiquement de nombreuses informations utiles dans le rapport généré (version des dépendances, architecture actuelle, etc.) et vous assistera à chaque étape.

5. Décrivez le problème afin que le développeur puisse le reproduire

Idéalement, votre rapport devrait inclure tout ce qui est nécessaire au développeur pour reproduire le problème sur son système. Si un quelconque document provoque le bogue, attachez-le au rapport.

Décrivez les étapes permettant de reproduire le bogue avec autant de détails que si vous vouliez l’expliquer à votre grand-mère. Expliquez le comportement attendu du programme, et ce qui s’est passé à la place.

Vous pouvez en apprendre bien plus sur la façon d’écrire un bon rapport de bug dans cet article : How to report bugs effectively. C’est un peu long mais ça en vaut la peine si vous envisagez de rapporter des bogues, et donc d’interagir avec les développeurs.

6. Soyez sympa et prêt à aider

Lorsque vous remplissez un rapport de bogue, gardez à l’esprit que vous êtes en train d’écrire à un développeur bénévole de logiciel libre, et non à un service consommateur. Vous devriez être respectueux et suivre les règles usuelles de courtoisie. Le temps disponible des développeurs est limité, et de devrait pas être gaspillé.

Soyez prêt à aider, car si un développeur commence à examiner votre problème, il peut avoir besoin d’informations supplémentaires (en particulier s’il ne peut le reproduire), et vous devriez être prêt à lui fournir. C’est pourquoi il est important de garder tout ce dont vous avez besoin pour reproduire le problème.

Dans certains cas, le mainteneur Debian peut être surchargé de travail. Vous pouvez offrir votre aide en transférant le bogue au traqueur de bogue amont.(Voir Upstream bug tracker) Ce sera toujours apprécié. Si vous êtes à peu près certain que le problème n’est pas spécifique à Debian, vous pouvez faire ça directement et définir l’URL du rapport de bug amont dans le champ « transféré » (par exemple avec bts forwarded <bogue> <url>).

7. Utilisez le niveau de gravité convenable

Le système de suivi de bug Debian vous permet de définir la gravité initiale du rapport de bug (en ordre décroissant de gravité : critical, grave, serious, important, normal, minor, wishlist). Choisissez la gravité convenable selon les définitions officielles et ne les interprétez pas de travers.

En particulier, n’exagérez pas la gravité : par exemple, si vous avez perdu des données à cause d’une mauvaise utilisation du logiciel, il ne s’agit pas d’une sévérité « critical » (i.e. "rm -rf *" n’est pas un bogue critique de rm). Si vous utilisez seulement une petite partie d’un logiciel, et que cette partie ne fonctionne pas, le paquet peut être inutilisable pour vous, mais pas pour tout le monde. Il ne s’agit donc pas d’une gravité « grave ». La gravité « important » est la plupart du temps un bon choix dans ce cas.

Ne sous-estimez pas non plus la gravité, si un problème est suffisamment important pour devoir être réparé avec la prochaine version stable (par exemple une régression par rapport à la version précédente), choisissez alors une gravité de niveau release-critical (i.e au moins « serious »). Le mainteneur et le gestionnaire de version peut toujours abaisser le niveau de gravité s’il n’est pas en accord avec votre jugement initial.

Et maintenant, lancez-vous à cœur joie dans la soumission de bogues ! Vous pouvez vous référer à cet article via cette URL raccourcie : https://raphaelhertzog.fr/go/bugreporting/

Ceci est une traduction sous licence CC-BY-SA 3.0 de mon article 7 tips de file useful Debian bug reports and get your problem solved contribuée par Xavier Cartron. Si vous avez apprécié cet article, cliquez ici pour découvrir comment m’encourager à en fournir d’autres.

Firmwares manquants dans Debian ? Apprenez à gérer le problème

Vous en avez déjà certainement entendu parler : Debian Squeeze est la première version de Debian dont l’installation standard est dépourvue de firmwares non libres. Ce qui peut entraîner quelques difficultés pour les utilisateurs en ayant besoin. Après une rapide introduction du sujet, nous allons voir comment remédier aux désagréments engendrés par ce changement.

Les firmwares : que sont-ils et comment sont-ils utilisés ?

Du point de vue de l’utilisateur, un firmware (ou microprogramme/microcode) n’est qu’un ensemble de données indispensable au bon fonctionnement d’un matériel donné. Généralement le pilote correspondant charge le firmware dans le périphérique au cours de son processus d’initialisation.

Au sein du noyau Linux, les pilotes utilisent tous la même interface normalisée (request_firmware) pour récupérer le firmware avant de l’envoyer au périphérique. Cette standardisation permet d’embarquer ce dernier directement dans le noyau, ou de le charger à la demande depuis l’espace utilisateur (lorsqu’il est requis).

Debian, à l’instar de la plupart des autres distributions, a choisi la deuxième option. Ainsi, lorsque le noyau a besoin d’un firmware, il envoie une requête en espace utilisateur : udev intercepte la demande (contenant le nom du firmware), et, grâce à sa configuration par défaut (cf. /lib/udev/rules.d/80-drivers.rules) exécute /lib/udev/firmware.agent en réponse.

Où sont enregistrés les firmwares ?

Le script shell firmware.agent essaye de localiser un firmware avant de le renvoyer au noyau via une entrée sysfs. Les répertoires analysés sont les suivants :

  • /lib/firmware/$(uname -r)
  • /lib/firmware
  • /usr/local/lib/firmware
  • /usr/lib/hotplug/firmware

Les paquets installant des firmwares les enregistrent habituellement dans /lib/firmware, et vous pouvez utiliser /usr/local/lib/firmware lorsque vous en installez manuellement.

Comment savoir si vous en avez besoin ?

Première source d’informations : les messages du noyau vous disant qu’il essaye de charger un firmware, mais n’y arrive pas. Ils ressemblent à ceci :

e100: eth0: e100_request_firmware: Failed to load firmware "e100/d101m_ucode.bin": -2

Ceci étant, le système peut vous informer du problème plus tôt : lorsque vous installez une nouvelle version du noyau Linux, le script de post-installation va parcourir tous les modules chargés (ceux listés par la commande lsmod) et vérifier si chacun de ces derniers, dans leurs versions installées par le dernier noyau, nécessitent ou pas des firmwares. Cette information est également disponible via modinfo :

$ modinfo -F firmware /lib/modules/2.6.32-5-amd64/kernel/drivers/net/e100.ko
e100/d102e_ucode.bin
e100/d101s_ucode.bin
e100/d101m_ucode.bin

Si certains des firmwares requis ne sont pas présents sur le système, vous obtiendrez un message d’avertissement semblable à celui-ci :

update-initramfs affiche également des avertissements similaires :

update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64
W: Possible missing firmware /lib/firmware/e100/d102e_ucode.bin for module e100
W: Possible missing firmware /lib/firmware/e100/d101s_ucode.bin for module e100
W: Possible missing firmware /lib/firmware/e100/d101m_ucode.bin for module e100

L’installateur Debian détecte également le matériel pouvant nécessiter un firmware manquant, et vous permet de le lui passer via une clé USB (soit directement, soit grâce aux paquets correspondants).

Comment trouver et installer les firmwares manquants ?

Maintenant que vous connaissez le nom du firmware manquant, il est relativement facile d’identifier le paquet le proposant. En effet, la description des paquets contient le nom des fichiers de firmwares qu’ils proposent, « apt-cache search <nom_du_firmware> » ramènera ainsi la liste des paquets le contenant.
Utiliser « apt-file » (fourni par le paquet du même nom) est également possible, comme le fait de rechercher via packages.debian.org.

$ apt-cache search d101m_ucode.bin
firmware-linux-nonfree - Binary firmware for various drivers in the Linux kernel
$ apt-file search d101m_ucode.bin
firmware-linux-nonfree: /lib/firmware/e100/d101m_ucode.bin

Si aucune des commandes précédentes ne retourne quoi que ce soit, vous devrez probablement ajouter le dépôt non-free à votre /etc/apt/sources.list (action réalisable également via synaptic). N’oubliez pas sudo apt-file update, afin de disposer des informations les plus à jour !

Il vous est maintenant possible d’installer le paquet requis, firmware-linux-nonfree dans l’exemple précédent.

Comment installer tous les firmwares, pour être sûr de n’en oublier aucun ?

Comme il n’existe aucun méta-paquet dépendant de tous les paquets de firmwares, la réponse n’est pas simple, et ce d’autant plus que tous les paquets embarquant des firmwares ne se conforment pas à la convention de nommage « firmware-* » (comme par exemple zd1211-firmware).

La « meilleure » option consiste peut-être à effectuer une recherche de termes génériques, comme par exemple :

$ apt-file --package-only search /lib/firmware/
atmel-firmware
[...]

et à installer les paquets listés.

Existe-t’il des images CD ou DVD comprenant les firmwares non libres ?

Oui, Debian propose de telles images « netinst » non-officielles pour les architectures i386, amd64 et powerpc. Elles sont téléchargeables ici : http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/.

De mon côté, un jeu de DVD avec les firmwares, et des CD/DVD multi-architectures avec firmwares, sont disponibles dans ma boutique DVD : https://raphaelhertzog.com/go/debian-cd/ (uniquement i386 ou amd64).

L’installateur Debian, avec ces disques, trouvera immédiatement les firmwares requis, vous évitant d’avoir à les charger au moyen d’une clé USB.

D’autres questions ?

Arrivant au terme de cet article, je pense avoir couvert les aspects les plus importants qu’il vous faut connaître au sujet des firmwares dans Debian. Ceci étant, s’il vous reste des questions, n’hésitez pas à les poser en commentaires ! Vos questions (et mes réponses) me permettront d’améliorer ce billet.

Ceci est une traduction de mon article Missing firmware in Debian? Learn how to deal with the problem contribuée par Weierstrass01.

Suivez moi sur Identi.ca, Google+, Twitter et Facebook. Ou abonnez-vous à ce blog par RSS ou par email.

Garder un système Debian propre, astuce n°6 : supprimer les paquets automatiquement installés devenus inutiles

Pour le dernier billet de cette série, et après avoir vu comment débarrasser son système des fichiers ne provenant pas d’un paquet Debian, nous allons voir aujourd’hui comment nettoyer les paquets ayant été installés comme dépendances, et dont vous n’avez plus besoin.

APT garde automatiquement la trace de l’installation des paquets

Vous n’installez que rarement un paquet tout seul : lorsque vous en sélectionnez un dans apt-get/aptitude/synaptic, ces derniers vous en rajoutent la plupart du temps plusieurs – ses dépendances, sans lesquelles ils ne veulent pas installer celui qui vous intéresse. Un exemple :

$ sudo apt-get install pino
[...]
Les paquets supplémentaires suivants seront installés :
  libdbusmenu-glib1 libgee2 libindicate4 libnotify1 notification-daemon
Les NOUVEAUX paquets suivants seront installés :
  libdbusmenu-glib1 libgee2 libindicate4 libnotify1 notification-daemon pino
0 mis à jour, 6 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 478 kB dans les archives.
Après cette opération, 2531 kB d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer [O/n] ? 

Les 5 paquets « supplémentaires » seront marqués à la fin de l’installation comme ayant été « automatiquement installés ». Qu’est-ce que cela signifie ? Tout simplement que vous n’avez pas explicitement demandé leur installation. Et, par conséquent, cela autorise le système à les retirer dès qu’il n’en a plus besoin.

apt-mark showauto, qui retourne une liste des paquets installés automatiquement, permet de vérifier que c’est bien le cas :

$ apt-mark showauto |grep libdbusmenu
libdbusmenu-glib1
$ apt-mark showauto |grep pino
$

aptitude montre cette information via la lettre « A » en regard du paquet (dans son interface ncurses), et nommément dans sa sortie en ligne de commande, par exemple aptitude show :

$ aptitude show libdbusmenu-glib1
Paquet : libdbusmenu-glib1               
Nouveau : oui
État: installé
Automatiquement installé: oui
Version: 0.3.7-1
[...]

L’information est moins visible dans synaptic : vous pouvez y avoir accès en sélectionnant un paquet installé, et en vérifiant dans le menu « paquet » si la case « installé automatiquement » est cochée ou non.

APT liste les paquets qui ne sont plus nécessaires

Certains paquets installés automatiquement peuvent, au fil du temps, ne plus être requis, car les paquets qui autrefois en dépendaient ne les appellent plus. Ce peut être car ils dépendent d’une version plus récente de la même bibliothèque, qu’ils dépendent d’autre chose pour assurer la même fonction, ou bien qu’ils sont dorénavant capables d’assurer tout seul la fonction.

Bref, quelle qu’en soit la raison, la dépendance originelle n’est plus, et le paquet automatiquement installé n’est plus requis pour le bon fonctionnement du système.

aptitude supprime automatiquement (à son prochain lancement) dans ce cas les paquets devenus inutiles, ce qui n’est pas le cas d’apt-get ou de synaptic.

apt-get, quant à lui, vous dresse par contre la liste des paquets superflus, et vous dit même parfois comment vous en débarrasser :

$ sudo apt-get remove pino
[...]
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
  notification-daemon libdbusmenu-glib1 libnotify1 libgee2 libindicate4
Veuillez utiliser « apt-get autoremove » pour les supprimer.
Les paquets suivants seront ENLEVÉS :
  pino
0 mis à jour, 0 nouvellement installés, 1 à enlever et 219 non mis à jour.
Après cette opération, 1225 kB d'espace disque seront libérés.
Souhaitez-vous continuer [O/n] ? 
[...]
$ sudo apt-get autoremove
[...]
Les paquets suivants seront ENLEVÉS :
  libdbusmenu-glib1 libgee2 libindicate4 libnotify1 notification-daemon
0 mis à jour, 0 nouvellement installés, 5 à enlever et 219 non mis à jour.
Après cette opération, 1307 kB d'espace disque seront libérés.
Souhaitez-vous continuer [O/n] ? 
[...]

synaptic, enfin, dispose dans ce but d’une nouvelle section accessible via le bouton « État » situé en bas à gauche : « Installés (pouvant être supprimés) ».

C’est une bonne habitude à prendre que de supprimer, à intervalle régulier, de tels paquets.

Drapeau d’installation automatique et réduction de la taille de votre système

Bien qu’APT positionne le drapeau « installé automatiquement » par lui-même, vous pouvez également le forcer manuellement. C’est une manière très simple de dire au système : « je n’ai pas particulièrement besoin de ce paquet, tu peux le désinstaller lorsque plus aucun autre n’en a besoin ».

# Avec apt-get
$ sudo apt-mark markauto libxml-simple-perl
# Ou avec aptitude
$ sudo aptitude markauto libxml-simple-perl

aptitude le permet également via son interface ncurses, grâce à la touche « M », pour marquer comme automatiquement installé le paquet sélectionné (et « m » pour enlever cet attribut). En ce qui concerne synaptic, il faut passer par le menu « Paquet > installé automatiquement ».

Un nombre important d’utilisateurs souhaiterait disposer d’une base installée minimale, tout en ne sachant pas réellement quels sont les paquets vraiment importants. Et la méthode consistant à « désinstaller le paquet et voir ce qui se passe » n’est pas une option très pratique…

Cette fonctionnalité permet donc, sans retirer (immédiatement) le paquet, de laisser le système décider, selon qu’il soit encore requis comme dépendance d’autres paquets ou non, s’il doit être désinstallé. Cette méthode comporte très peu de risques lorsqu’on l’applique aux bibliothèques (y compris les modules Python ou Perl).

Mon conseil serait de ne pas marquer comme « installés automatiquement » les paquets ayant une priorité supérieure ou égale à « important », ce afin d’éviter les surprises désagréables. Ceci étant, je dis cela uniquement pour me dédouaner d’éventuels problèmes créés parce que vous avez supprimé trop de paquets par ce biais. Car le système — en théorie — ne devrait pas supprimer ses constituants essentiels, le jeu des dépendances étant supposé être correctement et complètement renseigné.

Gardez également à l’esprit la conséquence du marquage d’un paquet tel que « gnome » : le système vous suggérera de supprimer entièrement votre bureau. Si tel est votre souhait, vous devriez alors dé-marquer les quelques paquets que vous souhaitez garder :

$ sudo apt-mark unmarkauto gnome-session gnome-panel

Ceci est une traduction de mon article Debian Cleanup Tip #6: Remove automatically installed packages that are no longer needed contribuée par Weierstrass01. Vous voulez d’autres tutoriels comme celui-ci ? Cliquez ici pour vous abonner à ma newsletter et recevoir les nouveaux articles par email.

Garder un système Debian propre, astuce n°5 : identifier et supprimer les fichiers ne provenant pas de paquets

Après avoir abordé l’altération des paquets installés et comment y remédier, nous allons nous concentrer aujourd’hui sur les fichiers ne provenant pas d’un quelconque paquet.

Fichiers non-empaquetés

Certains fichiers ne proviennent pas d’un paquet Debian. Autrement dit dpkg --search ne trouve aucun paquet associé :

$ dpkg --search /srv/cvs
dpkg-query : aucun chemin ne correspond à /srv/cvs

Votre système en contient forcément, ne serait-ce que les fichiers présents dans votre /home. Et ce ne sont certainement pas les seuls, puisque de nombreux démons créent ce type de fichiers (qui sont habituellement stockés dans /var) lors de leur fonctionnement normal : fichiers locaux pour un serveur de bases de données, pool d’emails pour un serveur de mails, … C’est tout à fait normal, et vous ne souhaitez absolument pas y toucher !

A l’inverse, certains fichiers dans /usr peuvent ne pas avoir été empaquetés, ce qui n’est pas normal si vous installez systématiquement à partir de paquets. Les lister permet donc de détecter un logiciel installé manuellement.

L’installation manuelle : une mauvaise idée

L’installation manuelle d’un logiciel peut être la source de nombreux problèmes. Prenons l’exemple d’un logiciel installé manuellement, et également à partir d’un paquet Debian. Au fil du temps, l’installation faite à partir du paquet sera mise à jour, tandis que celle manuelle non. Les autres paquets dépendant de ce logiciel « croiront » que leurs dépendances seront satisfaites, puisque ledit logiciel est censé être à jour, alors qu’il n’en sera rien : l’installation manuelle prenant l’ascendant sur celle du paquet, les vieux fichiers seront toujours utilisés…

Convaincu de vouloir vous en débarrasser ? Voyons déjà comment les trouver.

Identifier les fichiers non empaquetés grâce à cruft

Comme expliqué précédemment, beaucoup de fichiers ne provenant pas de paquets sont licites, et ne doivent pas être supprimés. cruft propose ainsi un traitement un peu plus élaboré qu’un simple balayage du système de fichiers, couplé à des requêtes sur la base dpkg.

Ainsi, cruft fournit aux paquets un moyen de déclarer les fichiers qu’ils créent durant leurs exécutions, et qu’il ne doit pas considérer comme illégitimes. Et il en connaît beaucoup. Mais cruft n’est ni exhaustif, ni à jour ! La sortie de cruft doit donc être considérée avec beaucoup de recul, et il vous faut regarder à deux fois avant de supprimer quelque fichier que ce soit ! Vous voilà prévenu…

Utilisation de cruft

Une liste de répertoires à ignorer peut (et devrait) être passée en argument, afin de réduire le nombre de faux-positifs en sortie. Par exemple :

$ sudo cruft -d / -r report --ignore /home --ignore /var --ignore /tmp
$ less report
cruft report: mercredi 23 février 2011, 15:45:34 (UTC+0100)

---- missing: ALTERNATIVES ----
        /etc/alternatives/cli-csc.1.gz
        /usr/share/man/man1/cli-csc.1.gz
---- missing: dpkg ----
        /etc/xdg/autostart/gnome-power-manager.desktop
        /usr/lib/libpython2.6_d.so.1.0-gdb.py
        /usr/share/fonts/X11/100dpi
        /usr/share/fonts/X11/75dpi
---- unexplained: / ----
        /boot
        /dev
        /etc/.java
        /etc/.java/.systemPrefs
[...]
        /usr/lib/pymodules/python2.6
        /usr/lib/pymodules/python2.6/.path
        /usr/lib/pymodules/python2.6/Brlapi-0.5.5.egg-info
[...]

Note : cruft ne suit pas les arborescences à travers les différents systèmes de fichiers : si votre /usr est sur une autre partition que /, il vous faudra passer -d "/ /usr" en argument pour que les deux soient scannés.

Analyse du résultat

Il est maintenant possible de parcourir la liste générée en sortie, et décider quels fichiers doivent être — ou non — supprimés. La liste présente également les fichiers « manquants », qui devraient être présents selon dpkg, mais sont manifestement absents. Mais ce qui nous préoccupe avant tout se trouve dans la section « unexplained » : il s’agit là des fichiers ne provenant d’aucun paquet, et dont la présence n’est expliquée par aucun des scripts que les paquets auraient pu fournir.

Je rappelle une fois encore que cette liste n’est pas à prendre pour argent comptant ! Si vous ne savez pas pourquoi tel fichier est présent, il vaudrait mieux ne pas le supprimer… Sur mon système, cruft liste par exemple un nombre important de fichiers sous /usr/lib/pymodules/, et tous ces fichiers sont parfaitement légitimes : ils proviennent de paquets Debian mais sont copiés là dynamiquement depuis /usr/{lib,share}/pyshared, afin de supporter les multiples versions de Python. Si vous supprimez ces fichiers, vous endommagez votre système.

Concernant Python, cruft rapportera également de nombreux fichiers .pyc. Ces derniers sont créés par les paquets Python, et correspondent à des fichiers .py compilés. Les supprimer ne casse rien, par contre vous perdrez un peu en performances.

A contrario de ces « faux-positifs », la plupart des fichiers trouvés sous /usr/local/ sont probablement le résultat d’installations manuelles de logiciels, et leur suppression peut être considérée comme sans risque (si vous n’utilisez pas lesdits logiciels !).

Conclusion: utile, mais à parfaire

En résumé, cruft peut effectivement être utilisé pour trouver les fichiers ne provenant d’aucun paquet. Il vous permettra ainsi d’étudier en détail ce qui est installé sur votre système. L’extraction des données utiles du rapport reste par contre très fastidieuse, vu le nombre conséquent de faux-positifs.

cruft a ainsi grandement besoin de bonnes volontés supplémentaires, ce afin de prendre en charge les nombreuses façons dont les paquets génèrent des fichiers. Les pré-requis pour s’y atteler sont faibles : le paquet est codé principalement en Python et en shell, et /usr/share/doc/cruft/README.gz détaille son fonctionnement.

Ceci est une traduction de mon article Debian Cleanup Tip #5: identify cruft that can be removed from your Debian system contribuée par Weierstrass01. Vous voulez d’autres tutoriels comme celui-ci ? Cliquez ici pour vous abonner à ma newsletter et recevoir les nouveaux articles par email.