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.

Garder un système Debian propre, astuce n°4 : trouver et réinstaller les paquets altérés

Après avoir vu comment se débarrasser des paquets des éditeurs tiers, nous allons un peu plus loin aujourd’hui en nous intéressant à l’évolution des paquets installés. Plus précisément, ce billet explique comment vérifier que les fichiers composant les paquets sont toujours identiques à ce qu’ils étaient lors de l’installation.

En effet si, en bon bricoleur, vous avez modifié manuellement certains fichiers afin de procéder à quelques tests rapides, ou si vous installez les nouvelles versions de paquets à partir des sources, il est possible que vous ayez remplacé certains fichiers provenant du paquet originel. Ne serait-il pas intéressant de détecter ces modifications (et d’y remédier !) ? debsums est l’outil parfait pour cela.

Utiliser debsums pour identifier les fichiers modifiés

J’utilise fréquemment debsums lorsque je prends en charge la maintenance d’un serveur Debian, afin de dresser la liste des fichiers modifiés par le précédent administrateur.

Lancé sans argument, debsums est très verbeux : il listera chaque fichier installé (à l’exception des fichiers de configuration) en affichant son état en regard : « OK » s’il n’a pas été modifié, et « FAILED » dans le cas contraire.

$ sudo debsums
/usr/bin/a2ps                                               OK
[...]

L’option --all permet d’inclure les fichiers de configuration également. L’option --config permet, au contraire, de ne prendre en compte que les fichiers de configuration.

L’option --changed, enfin, permet de demander à debsums une liste restreinte aux seuls fichiers modifiés. La commande suivante va donc permettre de ne lister que les fichiers ayant été modifiés sur le système, et qui ne sont pas des fichiers de configuration :

$ sudo debsums --changed
/usr/lib/perl5/AptPkg/Config.pm
/usr/lib/perl5/AptPkg.pm
[...]

Remonter aux paquets concernés, et les réinstaller

Parmi les fichiers modifiés, debsums a trouvé /usr/lib/perl5/AptPkg.pm. C’est exact, je me souviens avoir manuellement installé une version modifiée de ce module Perl.

J’en ai déduit le paquet concerné grâce à la commande dpkg --search /usr/lib/perl5/AptPkg.pm : il s’agit de libapt-pkg-perl.

Tout ce qu’il me reste à faire alors est de réinstaller le paquet pour ré-écraser les fichiers modifiés avec les originaux :

$ sudo aptitude reinstall libapt-pkg-perl
[...]
# Ou avec apt-get
$ sudo apt-get --reinstall install libapt-pkg-perl
[...]

Il ne reste plus qu’à recommencer le processus jusqu’à ce que debsums ne remonte plus aucun fichier modifié.

Ceci est une traduction de mon article Debian Cleanup Tip #4: find broken packages and reinstall them 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°3 : se débarrasser des paquets externes à Debian

Le dernier billet de notre série évoquait la suppression des paquets obsolètes. Le billet d’aujourd’hui va vous montrer comment faire retrouver à votre ordinateur un état proche de celui obtenu après une installation de Debian/Ubuntu, sans paquets tiers.

APT a cela de puissant qu’il permet facilement l’ajout de nouveaux dépôts externes, et l’installation de logiciels à partir de ces derniers. Malheureusement, certains de ces logiciels ne s’avèrent pas être très bien maintenus : paquets de piètre qualité ou plus mis à jour. Un paquet fonctionnant parfaitement au début peut devenir une plaie pour la maintenance du système, par exemple en posant une dépendance sur un paquet devant être supprimé lors de la mise à jour.

Mon but ici est donc de vous montrer comment identifier ces paquets, qui ne proviennent ni de Debian, ni d’Ubuntu, de telle sorte que vous puissiez les passer en revue de temps en temps, et ne garder que ceux dont vous avez réellement besoin. Les paquets obsolètes sont en fait un sous-ensemble de ces paquets mais, les ayant traités dans le dernier billet, je n’y reviendrai pas.

Tout dépôt APT bien conçu est fourni avec un fichier Release le décrivant (celui-ci par exemple). Ces fichiers contiennent un certain nombre de valeurs permettant à APT d’identifier les paquets que contiennent les dépôts correspondants. Tous les dépôts officiels Debian mentionnent ainsi Origin=Debian (ou Origin=Ubuntu pour Ubuntu). L’attribut Origin de chaque dépôt présent dans votre fichier sources.list peut être vérifié grâce à apt-cache policy :

[...]
 500 http://ftp.debian.org/debian/ lenny/main i386 Packages
     release v=5.0.8,o=Debian,a=stable,n=lenny,l=Debian,c=main
     origin ftp.debian.org
[...]

Partant de là, il suffit de demander à aptitude de renvoyer la liste des paquets installés mais non présents dans un dépôt Debian officiel :

$ aptitude search '?narrow(?installed, !?origin(Debian))!?obsolete'
ou
$ aptitude search '~S ~i !~ODebian !~o'

search peut être remplacé par purge ou remove si vous souhaitez supprimer/purger tous les paquets correspondants. Ceci étant, il est plus probable que vous ne vouliez en supprimer que quelques-uns, intelligemment choisis : il y en a encore sûrement que vous utilisez !

synaptic vous permet également de parcourir le contenu de chaque dépôt : cliquez sur le bouton « Origine » et une liste de dépôts apparaît. Il suffit de parcourir les dépôts non-Debian à la recherche des paquets installés et à jour.

Mais il est possible de faire mieux : créer une vue personnalisée. Pour cela cliquez sur l’entrée « Filtres » du menu « Configuration ». Cliquez ensuite sur « Nouveau » pour créer un nouveau filtre, appelez-le par exemple « Paquet externe ». Décochez toutes les entrées de l’onglet « État », à l’exception de « Installés ».

Allez ensuite dans l’onglet « Propriété » pour ajouter une nouvelle entrée : « Origine » « exclut » « ftp.debian.org ». Remplacez évidemment ftp.debian.org par le nom du miroir que vous utilisez (il apparaît dans la sortie d’apt-cache policy, cf. l’exemple présenté un peu plus haut).

Note : le terme « Origine » fait référence à deux notions distinctes : un attribut du fichier Release évoqué précédemment, mais aussi le nom de l’hôte d’un dépôt APT. Ce qui est un peu perturbant si l’on y prête pas attention.

Fermez la fenêtre de définition des filtres en cliquant sur « OK ». Une nouvelle liste « Paquet externe » est maintenant disponible dans l’onglet « Filtres personnalisés ». Vous pouvez maintenant voir quels paquets sont installés et à jour, et décider si vous souhaitez les garder ou pas. Si le paquet est également fourni par Debian/Ubuntu et que vous désirez changer pour ce dernier, utilisez « Paquet > Forcer version ».

Ceci est une traduction de mon article Debian Cleanup Tip #3: get rid of third-party packages contribuée par Weierstrass01. Ne manquez pas une occasion de parfaire vos connaissances de Debian ou Ubuntu, abonnez-vous à ma newsletter en cliquant ici.

Garder un système Debian propre, astuce n°2 : se débarrasser des paquets obsolètes

Dans le billet précédent, nous avons appris comment supprimer les fichiers de configuration inutiles. Dans cet article, nous allons maintenant voir comment s’occuper des paquets obsolètes.

Un paquet est considéré comme obsolète du moment que plus aucun des dépôts APT présents dans le fichier /etc/apt/source.lists (et /etc/apt/sources.list.d/) ne le fournit. De nombreuses raisons peuvent conduire à cet état :

  • L’auteur amont du paquet a arrêté tout support depuis un long moment, personne n’a pris la relève et le mainteneur Debian a préféré retirer le paquet de l’archive Debian. Des alternatives sont la plupart du temps disponibles en remplacement ;
  • Le paquet Debian était orphelin depuis longtemps, personne ne l’a repris en charge et il n’avait que peu d’utilisateurs. Il se peut également que l’équipe Debian QA (Quality Assurance – Assurance Qualité) ait demandé son retrait ;
  • La dernière version du paquet a été empaquetée sous un nom différent. Soit en raison d’un nombre de changements tellement important qu’il était préférable de ne pas mettre à jour automatiquement vers le dernier paquet (ce fut le cas pour request-tracker et nagios par exemple, qui embarquaient tous les deux un numéro de version dans leurs noms), soit simplement parce que le mainteneur du paquet souhaitait permettre à l’utilisateur d’avoir plusieurs versions du paquet installées en même temps (ce qui est le cas par exemple pour le noyau Linux, l’interpréteur Python et de nombreuses bibliothèques) ;
  • l’application a été renommée, et le mainteneur a donc renommé le paquet. Il a gardé un paquet de transition sous l’ancien nom pendant un cycle de publication puis ce dernier a été supprimé.

Ce n’est dans tous les cas jamais une bonne idée de conserver les paquets obsolètes : ils ne profitent d’aucune mise à jour de sécurité, et peuvent causer des problèmes lors des mises à jour, en dépendant de paquets devant être supprimés pour finir celles-ci.

Vous pouvez les supprimez d’un seul coup grâce à aptitude purge ~o (ou aptitude purge ?obsolete), mais vous souhaitez peut-être analyser un peu plus la situation avant : il se pourrait que certains paquets que vous avez installés manuellement (et absents des dépôts APT) fassent partie du lot, et ces derniers ne doivent pas subir le même traitement (me concernant, j’ai par exemple Skype et quelques paquets personnels). Vous pouvez obtenir la liste des paquets concernés via aptitude search ?obsolete.

Cette même liste est bien sûr accessible en passant par Synaptic, gestionnaire de paquets en mode graphique : cliquez sur le bouton « État », puis sur « Installés (locaux ou obsolètes) ». Vous pouvez maintenant parcourir la liste et décider, pour chaque paquet, s’il doit être conservé ou non.

Ceci est une traduction de mon article Debian Cleanup Tip #2: Get rid of obsolete packages contribuée par Weierstrass01. Abonnez-vous à ce blog par RSS ou par email pour recevoir tous les prochains articles et améliorer votre maîtrise de Debian/Ubuntu.

Garder un système Debian propre, astuce n°1 : se débarrasser des fichiers de configuration inutiles

Si vous êtes de ceux aimant garder un bureau bien rangé, il en va certainement de même avec votre ordinateur ! À cette fin, je vais détailler, au travers de 4 articles dont voici le premier, quelques astuces pour maintenir votre Debian/Ubuntu toute propre !

Au fil du temps et de l’utilisation de votre ordinateur, l’ensemble des paquets installés va évoluer. Soit parce que vous avez installé/supprimé des applications, soit parce que vous avez mis à jour votre distribution.

Ceci étant, le système de gestion des paquets Debian est construit de telle sorte qu’il conserve les fichiers de configuration d’un paquet lors de sa suppression. C’est une fonctionnalité intéressante, dans la mesure où vous n’aurez pas à refaire le paramétrage de ce paquet lorsque vous le réinstallerez. Oui, mais… et si vous ne réinstallez jamais ?

Dans ce dernier cas, ces fichiers de configuration « encombrent » inutilement votre système, voire le « parasitent » ! Un exemple (m’étant récemment arrivé) : des scripts init obsolètes empêchant le passage à une séquence de boot basée sur les dépendances, car ils n’embarquaient aucune dépendance nécessaire. Bref, vous préféreriez vous en débarrasser.

La solution à ce problème consiste à « purger » tous les paquets dont il ne reste plus que les fichiers de configuration présents sur le système. Avec aptitude c’est possible avec la commande aptitude purge ~c (ou aptitude purge ?config-files). Il suffit de remplacer purge par search pour visualiser uniquement la liste des paquets concernés.

Si vous souhaitez une mise en forme adaptée de cette liste, de sorte qu’elle puisse être repassée en argument à un autre programme, utilisez une des commandes suivantes (et passez le résultat à apt-get si aptitude n’est pas installé) :

$ grep-status -n -sPackage -FStatus config-files
[...]
$ dpkg-query -f '${Package} ${Status}\n' -W | grep config-files$ | cut -d" " -f1
[...]

Note : grep-status fait partie du paquet dctrl-tools .

La solution précédente faisait intervenir la ligne de commande, mais vous pouvez tout aussi bien utiliser un gestionnaire graphique de paquets, comme Synaptic. Cliquez sur le bouton « État » en bas à gauche, puis sur « Non installés (résidus de configuration) », et la liste des paquets pouvant être purgés s’affiche. Sélectionnez-les tous, puis clic-droit « Marquer pour suppression complète » (cf. la capture d’écran ci-dessous). Enfin, cliquez sur « Appliquer » pour lancer la purge des paquets.

Ceci est une traduction de mon article Debian Cleanup Tip #1: Get rid of useless configuration files 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.

Gérer des patchs spécifiques à chaque distribution avec un paquet source commun

Un patch peut-il n’être appliqué au paquet cible que pour certaines distributions ? Cette question m’a été posée en commentaire d’un précédent article présentant la gestion différentielle des dépendances entre Ubuntu et Debian, à partir d’un même paquet source. Et la réponse est … oui. C’est possible !

Le format de paquets source 3.0 (quilt) offre à cette fin une possibilité intéressante : plutôt que d’utiliser uniquement le fichier debian/patches/series pour rechercher des patches, dpkg-source essaye en premier lieu d’utiliser debian/patches/distrib.series, où « distrib » vaut « ubuntu », « debian », … Il est important de noter que dpkg-source n’applique pas les patches de tous les fichiers series trouvés : seuls les patches du premier fichier trouvé sont considérés.

Bien, mais comment tirer le meilleur parti de tout cela ? Debian est supposée toujours fournir le fichier debian/patches/series, ce dernier devant indiquer l’ensemble des patches « de base » à appliquer. N’importe quel tiers travaillant avec Debian peut maintenir son propre fichier series dans le dépôt CVS commun de maintenance des paquets. Il peut ainsi laisser de côté certains patches propres à Debian (les patches relatifs à la marque, par exemple), et intégrer les siens en plus des patches restants.

Il est intéressant de noter que c’est au mainteneur de s’assurer, en cas de besoin, de la cohérence des deux fichiers. dpkg-source n’offre ni la possibilité d’agréger plusieurs fichiers series, ni d’établir une quelconque dépendance entre eux.

Pour éditer un fichier series alternatif grâce à quilt, il suffit de positionner temporairement la variable d’environnement QUILT_SERIES à « distrib.series ». Faites simplement attention à bien partir d’un état vierge (i.e. aucun patch appliqué). Si tel n’est pas le cas, quilt sera confronté à une incohérence entre les données du fichier series et ses propres données (stockées dans le dossier .pc).

Ceci est une traduction de mon article Managing distribution-specific patches with a common source package contribuée par Weierstrass01. Si vous avez apprécié cet article, cliquez ici pour découvrir comment m’encourager à en rédiger d’autres.

Correctement renommer un fichier de configuration dans un paquet Debian

Après avoir traité de la suppression de conffiles obsolètes, je vais maintenant aborder la question du renommage des fichiers de configuration gérés par dpkg.

La problématique

Prenons pour hypothèse que la version 1.2 d’une quelconque application ne fournisse plus le fichier /etc/foo.conf. En lieu et place, elle fournit /etc/bar.conf, car le fichier de configuration a été renommé. Si vous ne faîtes rien de particulier, le nouveau conffile sera installé et contiendra la configuration par défaut, tandis que l’ancien restera. Toutes les modifications éventuellement réalisées par l’administrateur seront perdues (inutilisées, pour être exact : elles seront toujours consignées dans le fichier foo.conf, qui ne sera plus pris en compte).

Bien entendu, il vous est toujours possible de procéder à un mv /etc/foo.conf /etc/bar.conf dans le script de pré-installation. Mais ce n’est pas satisfaisant : une questions sera posée à l’utilisateur final lors de la mise à jour, dont il ne comprendra pas la raison.

La solution

Vous devez vérifier, dans le script de pré-installation, si l’ancien conffile a été modifié par l’administrateur. Si tel est le cas, vous souhaitez le garder de côté. Dans le cas contraire, vous pourrez le supprimer une fois la mise à jour réalisée, et, pour bien s’en rappeler, vous le renommez en /etc/foo.conf.dpkg-remove dans ce cas.

Vous supprimez ensuite /etc/foo.conf.dpkg-remove dans le script de post-installation. Si l’ancien conffile (/etc/foo.conf) existe toujours, c’est qu’il a été modifié par l’administrateur. Il ne reste plus alors qu’à faire une copie de sauvegarde du nouveau conffile vers /etc/bar.conf.dpkg-dist, et renommer l’ancien en /etc/bar.conf.

Dans le script postrm, dans le cas d’un appel pour annuler la mise à jour, le fichier /etc/foo.conf.dpkg-remove doit retrouver son nom originel.

En pratique, utilisez dpkg-maintscript-helper

dpkg-maintscript-helper permet d’automatiser toutes ces tâches. Vous n’avez qu’à ajouter l’extrait de code suivant dans chaque script (postinst, postrm, preinst) :

if dpkg-maintscript-helper supports mv_conffile 2>/dev/null; then
    dpkg-maintscript-helper mv_conffile /etc/foo.conf /etc/bar.conf 1.1-3 -- "$@"
fi

J’ai considéré dans cet exemple que la dernière version du paquet contenant /etc/foo.conf (i.e. la dernière version avant la parution de la 1.2-1) était la 1.1-3.

Vous pouvez faire l’économie des tests préliminaires en imposant une pré-dépendance à « dpkg (>= 1.15.7.2) », ou si suffisamment de temps s’est écoulé pour considérer comme probable que tout le monde dispose d’une version plus récente. Vous trouverez tous les détails sur ce point dans la page de manuel de dpkg-maintscript-helper.

Cet article est une traduction de Correctly renaming a conffile in Debian package maintainer scripts contribuée par Weierstrass01. Suivez moi sur Identi.ca, Twitter et Facebook. Ou abonnez-vous à ce blog par RSS ou par email.

Comment recompiler un paquet Debian

Savoir recompiler un paquet Debian existant est particulièrement utile. En effet, il s’agit là d’un prérequis indispensable à certaines tâches qu’un administrateur peut vouloir effectuer : activer une fonctionnalité désactivée dans le paquet Debian officiel, recompiler les sources pour un autre environnement (récupérer la version correspondant à Debian testing pour faire fonctionner le paquet sous Debian stable par exemple — ce qui, d’ailleurs, est le principe même des applications disponibles dans les backports), inclure une correction que les développeurs upstream ont mise à disposition, … Cet article vous propose de découvrir les 4 étapes nécessaires à cette recompilation :

1. Télécharger les sources

La « meilleure » manière de télécharger les sources reste l’utilisation d’APT. Il permet de les télécharger depuis les dépôts source paramétrés dans le fichier /etc/apt/sources.list, comme par exemple :

deb-src http://ftp.debian.org/debian unstable main contrib non-free
deb-src http://ftp.debian.org/debian testing main contrib non-free
deb-src http://ftp.debian.org/debian stable main contrib non-free

Comme on le voit, le premier mot-clé indique clairement à APT que l’on s’intéresse aux sources, et non pas aux binaires.

Si les dépôts source n’étaient pas présents dans le fichier auparavant, un petit apt-get update permettra de mettre à jour la base et vous pourrez récupérer par exemple la dernière version des sources du paquet publican, via la commande apt-get source publican. Il est également possible d’indiquer la distribution au sein de laquelle il faut récupérer les sources, avec la syntaxe « package/distribution« . Dans notre cas, apt-get source publican/testing récupérera les sources de publican à partir du dépôt testing et les extraira dans le répertoire courant (via la commande dpkg-source -x, avec comme prérequis le paquet dpkg-dev installé).

$ apt-get source publican/testing
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Note : la maintenance du paquet de « publican » est réalisée dans le système de suivi de versions « Git » à l'adresse :
git://git.debian.org/collab-maint/publican.git
Nécessité de prendre 888 ko dans les sources.
Réception de : 1 http://ftp.fr.debian.org/debian/ testing/main publican 2.5-2 (dsc) [2 292 B]
Réception de : 2 http://ftp.fr.debian.org/debian/ testing/main publican 2.5-2 (tar) [879 kB]
Réception de : 3 http://ftp.fr.debian.org/debian/ testing/main publican 2.5-2 (diff) [6907 B]
888 ko réceptionnés en 8s (104 ko/s)
dpkg-source: info: extraction de publican dans publican-2.5
dpkg-source: info: extraction de publican_2.5.orig.tar.gz
dpkg-source: info: extraction de publican_2.5-2.debian.tar.gz
dpkg-source: info: mise en place de perl-critic-fixes-svn1732
$ ls -dF publican*
publican-2.5/
publican_2.5-2.debian.tar.gz
publican_2.5-2.dsc
publican_2.5.orig.tar.gz

Si vous ne souhaitez pas utiliser APT, ou si le paquet source n’est pas hébergé par un dépôt APT, il est toujours possible de télécharger le paquet source complet via dget -u dsc-url, où dsc-url représente l’URL du fichier .dsc, image des sources du paquet. L’utilitaire dget est fourni par le paquet devscripts. L’option -u mérite d’être retenue : elle signifie que l’origine des sources ne sera pas vérifiée avant extraction.

2. Installer les dépendances de compilation

Là-aussi, APT peut faire le boulot ingrat à votre place. Tout ce que vous avez à faire est de lancer apt-get build-dep mon-paquet afin que les dépendances nécessaires à la compilation de mon-paquet soient installées. La syntaxe restant la même que pour apt-get source, il est possible de lancer apt-get build-dep publican/testing, ce qui aura pour effet d’installer les dépendances pour la compilation de la version testing de publican.

Si vous ne pouvez pas utiliser APT pour faire cela, placez-vous directement dans le répertoire contenant l’extraction du paquet source et lancez dpkg-checkbuilddeps. En sortie, vous aurez une liste de dépendances de compilation non satisfaites (dans le cas contraire, la commande restera muette, et vous pourrez continuer tranquillement). Dans ce cas, un enchaînement de copier/coller et d’apt-get install permettra de remédier au problème en quelques secondes.

3. Faites les modifications requises

Je ne détaillerai pas cette étape, dans la mesure où elle dépend totalement des objectifs particuliers qui vous poussent à recompiler. Vous serez peut-être amené à modifier le fichier debian/rules, ou à appliquer un patch.

Dans tous les cas, une chose est sûre : si vous avez changé quoi que ce soit, ou recompilé le paquet dans un environnement différent, vous devriez vraiment changer son numéro de version. dch --local perso (toujours du paquet devscripts) vous permet de le faire simplement : remplacer simplement perso par un nom court vous identifiant comme le pourvoyeur de cette version. debian/changelog sera modifié en conséquence et vous serez invité à documenter brièvement les changements opérés.

4. Compiler le paquet

La dernière étape est également la plus simple, maintenant que tout est en place. Vous devez vous placer à la racine du répertoire où sont extraites les sources, et lancer debuild -us -uc (procédure recommandée, nécessite le paquet devscripts), ou directement dpkg-buildpackage -us -uc. Les options « -us -uc » évitent l’étape de la signature qui provoquerait une erreur (bénigne) à la fin si vous ne disposez pas de clé GPG correspondant au nom entré au début du fichier des modifications Debian (debian/changelog).

$ cd publican-2.5
$ debuild -us -uc
dpkg-buildpackage: export de CFLAGS depuis dpkg-buildflags (origine : vendor): -g -O2
dpkg-buildpackage: export de CPPFLAGS depuis dpkg-buildflags (origine : vendor): 
dpkg-buildpackage: export de CXXFLAGS depuis dpkg-buildflags (origine : vendor): -g -O2
dpkg-buildpackage: export de FFLAGS depuis dpkg-buildflags (origine : vendor): -g -O2
dpkg-buildpackage: export de LDFLAGS depuis dpkg-buildflags (origine : vendor): 
dpkg-buildpackage: paquet source publican
dpkg-buildpackage: version source 2.5-2
dpkg-buildpackage: source changé par Raphaël Hertzog 
dpkg-buildpackage: architecture hôte amd64
[...]
dpkg-deb: compilation du paquet `publican' en `../publican_2.5-2rh1_all.deb'.
 dpkg-genchanges  >../publican_2.5-2rh1_amd64.changes
dpkg-genchanges: sources originales non incluses en version amont
 dpkg-source --after-build publican-2.5
dpkg-buildpackage: binary and diff upload (sources originales NON incluses)
Lancement de lintian...
lintian : terminé.

La compilation est terminée. Les sources mises à jour ainsi que les paquets binaires ont été générés dans le dossier parent.

$ cd ..
$ ls -dF publican*
publican-2.5/                    publican_2.5-2rh1.dsc
publican_2.5-2.debian.tar.gz     publican_2.5-2rh1_amd64.changes
publican_2.5-2.dsc               publican_2.5-2rh1_source.changes
publican_2.5-2rh1_all.deb        publican_2.5.orig.tar.gz
publican_2.5-2rh1.debian.tar.gz

Cet article est une traduction de Howto to rebuild Debian packages contribuée par Weierstrass01. Abonnez-vous à ce blog par RSS ou par email pour recevoir tous les prochains articles et améliorer votre maîtrise de Debian/Ubuntu.

La bonne manière de supprimer un fichier de configuration obsolète dans un paquet Debian

Un conffile est un fichier de configuration géré par dpkg, mais je suis certain que vous vous souvenez de cet article introductif à propos des conffiles. Lorsque votre paquet cesse de fournir un conffile, celui-ci reste simplement sur le disque et est considéré comme « obsolète » par le gestionnaire de paquets. Il n’est retiré que dans le cas de la purge (et non de la simple suppression) du paquet. Si vous souhaitez que ce fichier soit retiré avant ce terme, il ne vous reste plus qu’à coder vous-même en ce sens les scripts de configuration de vos paquets. Voyons donc comment.

Quand est-ce nécessaire ?

dpkg privilégie la sécurité en ne supprimant pas ce fichier sauf en cas de purge. Pourtant, il est généralement plus avisé de le faire plus tôt pour ne pas induire l’utilisateur en erreur. C’est même obligatoire dans certains cas, puisque garder le conffile pourrait provoquer des erreurs logicielles (par exemple dans le cas où il se trouve dans un dossier « .d », et qu’il contient des entrées plus supportées ou contradictoires avec celles de nouveaux conffiles).

Qu’est-ce que « rm » a donc de compliqué ?

Vous souhaitez donc supprimer le conffile. Ajouter une commande « rm » dans debian/postinst semble plutôt facile. Certes, mais ce n’est pas du tout la bonne manière de procéder ! Il se pourrait que le conffile contienne certaines adaptations faites par l’administrateur, que vous ne souhaitez pas perdre. Plutôt que de supprimer, vous souhaitez plutôt garder le fichier dans un coin, afin que l’administrateur puisse récupérer ce qu’il avait fait et s’en servir comme bon lui semble.

La bonne action à prendre est donc de demander le déplacement de ce fichier dans le script prerm, afin d’éviter toute interférence avec la nouvelle version. Simultanément, vous devez vérifier si le conffile a été modifié par l’utilisateur, et, si c’est le cas, le retenir pour plus tard. Puis, dans le script postinst, le supprimer s’il n’y aucun changement entre la nouvelle et l’ancienne version, ou le garder sous un autre nom, si différence il y a. Ajouter un suffixe type .dpkg-bak est généralement suffisant, dans la mesure où de nombreuses applications sont configurées pour ne prendre en compte que les fichiers d’une certaine extension (*.conf, au hasard). run-parts, par exemple, ignore tous les fichiers contenant un point dans leurs noms. Dans le script postrm enfin, il est nécessaire de supprimer les conffiles conservés jusque-là en raison de changements locaux et, au cas où l’installation rendant obsolète le conffile est annulée, restaurer l’ancienne version.

Automatisons tout cela grâce à dpkg-maintscript-helper

Fioouuuu… c’est une longue liste de tâches à réaliser pour une action apparemment simple ! Heureusement, tout cela peut être automatisé grâce à dpkg-maintscript-helper. Partons du principe que vous souhaitez supprimer /etc/foo/conf.d/bar, du fait qu’il est maintenant dépassé et que vous préparez une nouvelle version 1.2-1 qui le supprimera lors de la mise à jour. Il vous suffit de copier-coller l’extrait de code suivant dans les 3 scripts (preinst, postinst, postrm) :

if dpkg-maintscript-helper supports rm_conffile 2>/dev/null; then
    dpkg-maintscript-helper rm_conffile /etc/foo/conf.d/bar 1.2-1 -- "$@"
fi

Le if peut être évité en posant une dépendance à « dpkg (>= 1.15.7.2) », ou s’il s’est écoulé suffisamment de temps pour supposer que tout le monde dispose d’une version assez récente. La page de manuel de dpkg-maintscript-helper vous apportera tous les détails nécessaires.

Cet article est une traduction de The right way to remove an obsolete conffile in a Debian package contribuée par Weierstrass01. Abonnez-vous à ce blog par RSS ou par email pour recevoir tous les prochains articles et améliorer votre maîtrise de Debian/Ubuntu.

Économisez de l’espace disque en excluant les fichiers inutiles avec dpkg

La plupart des paquets contiennent des fichiers dont vous n’avez pas besoin, comme par exemple des traductions dans des langues qui vous sont inconnues, ou de la documentation que vous ne lirez pas. Ne serait-il pas intéressant de s’en dispenser et sauver ainsi quelques méga-octets ? Bonne nouvelle : à partir de dpkg 1.15.8, c’est possible !

dpkg met à disposition deux options dans ce but :

  • --path-include=motif-de-type-glob
  • --path-exclude=motif-de-type-glob

D’elles dépend l’installation ou non d’un fichier. Le motif de recherche « glob » fonctionne de la même façon que ce à quoi vous êtes habitués au travers du shell (cf. la page de manuel glob(7)).

Passer ces deux options via la ligne de commande étant tout sauf pratique, la meilleure manière de les utiliser reste de les mettre dans un fichier de configuration résidant dans /etc/dpkg/dpkg.cfg.d/. Attention toutefois : l’ordre dans lequel sont énumérées les options compte. Lorsqu’un fichier correspond à plusieurs motifs de recherche, la dernière entrée l’emporte !

Un de leurs usages habituels consiste à exclure un dossier entier, puis à réintégrer certaines de ses parties que vous voulez conserver. Par exemple exclure les traductions gettext et manuels dans toutes les langues sauf le français. Il faut alors que le fichier /etc/dpkg/dpkg.cfg.d/excludes contienne :

# Supprimer toutes les locales, sauf le français
path-exclude=/usr/share/locale/*
path-include=/usr/share/locale/fr/*
path-include=/usr/share/locale/locale.alias

# Supprimer les pages de manuels, sauf celles en français
path-exclude=/usr/share/man/*
path-include=/usr/share/man/man[1-9]/*
path-include=/usr/share/man/fr*/*

Notez bien qu’à partir du moment où vous aurez mis à jour /etc/dpkg/dpkg.cfg.d/excludes, les fichiers commenceront à disparaître au fur et à mesure des mises à jour des paquets. Si l’objectif consiste à sauver de l’espace disque immédiatement, alors il vous faudra réinstaller les paquets installés sur votre système. aptitude reinstall ou apt-get --reinstall install pourront alors vous être utiles. En théorie, il serait même possible d’utiliser aptitude reinstall ~i, mais cela a de grandes chances d’échouer, du fait d’un paquet non disponible (parce qu’il a été installé manuellement ou parce qu’une nouvelle version a pris la place sur le miroir de l’ancienne ayant été installée).

Cet article est une traduction de Save disk space by excluding useless files with dpkg contribuée par Weierstrass01. Abonnez-vous à ce blog par RSS ou par email pour recevoir tous les prochains articles et améliorer votre maîtrise de Debian/Ubuntu.