Destination Debian

Infos à la source, maîtrisez votre distribution Debian/Ubuntu

  • Soutenir
  • Mes livres
    • Mémento Git à 100%
    • Debian 8 Jessie
  • Lettre d’informations
  • Mes activités chez Debian
    • Historique
    • Mes projets
  • Mes autres sites
    • My blog on free software
    • Freexian, ma société
    • Mon blog perso
  • Contact
Home Archives for Debian

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

Posted on 16/08/2011 Written by Raphaël Hertzog

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.

Filed Under: Documentation, Documentation pour les utilisateurs Tagged With: aptitude, conffile, Debian, dpkg-query, grep-status, HOWTO, Libre, nettoyage, Référence, synaptic, Ubuntu

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

Posted on 12/08/2011 Written by Raphaël Hertzog

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.

Filed Under: Documentation, Documentation pour les contributeurs Tagged With: 3.0 (quilt), Debian, Dérivés, HOWTO, Libre, Packaging, Patch, Ubuntu

Mes activités Debian en juillet 2011

Posted on 10/08/2011 Written by Raphaël Hertzog

Voici le récapitulatif mensuel de toutes mes activités gravitant autour de Debian. Si vous faites partie des personnes ayant fait un don pour soutenir mon travail (170 €, merci à tous !), c’est l’occasion de constater ce que je fais de votre argent. Sinon, c’est toujours quelques nouvelles intéressantes sur l’avancement de mes différents projets.

Le mois de juillet est passé à toute vitesse, en grande partie parce que j’ai participé à la fois aux RMLL – Rencontres Mondiales du Logiciel Libre et à la DebConf.

Les RMLL

Du fait de ma présence d’une semaine complète un peu plus tard dans le mois à la DebConf, je n’ai participé « que 3 jours » sur les 6 que duraient ces Rencontres.

Et, durant ces 3 jours, j’ai aidé à la tenue du stand Debian, déjà en de bonnes mains : celles de Frédéric Perrenot et Arnaud Gambonnet. Nous n’avions malheureusement aucun goodies à vendre, et c’est là un point sur lequel nous devrons nous améliorer d’ici la prochaine fois (par nous j’entends Debian France).

J’ai assisté, entre autres, à une conférence présentant EnVenteLibre. Ce site a été créé, au départ, comme boutique en ligne pour les associations Ubuntu-fr et Framasoft. Toute la logistique est sous-traitée, seules les commandes de goodies et leurs livraisons à l’entrepôt du sous-traitant sont de leur responsabilité. Ils peuvent également envoyer directement du matériel de l’entrepôt pour une conférence, par exemple. Nous avons discuté dans les grandes lignes d’une éventuelle adhésion de Debian France, voire même, pour Debian et toutes ses associations locales, de la possibilité d’opérer à l’échelle internationale.

Une fois de retour, et bien qu’ayant passé trois bonnes journées à Strasbourg, il m’a semblé que cet événement perdait, petit à petit, en importance : il est loin d’être de dimension internationale, et le nombre de conférences ne joue pas en faveur de la qualité.

En passant, est-ce que vous vous rappelez que Debconf 0 et Debconf 1 ont été associées à cet événement lorsqu’il s’est déroulé à Bordeaux ?

Améliorations de dpkg-source

J’ai apporté certaines modifications au format source 3.0 (quilt) durant mon séjour à Strasbourg (et plus particulièrement durant les trajets aller et retour !). dpkg-source refusera maintenant la compilation d’un paquet source si celui-ci comporte des changements upstream qui ne sont pas correctement enregistrés dans un patch quilt :

dpkg-source: info: local changes detected, the modified files are:
 2ping-1.1/README
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/2ping_1.1-1.diff.cki8YB

Comme le suggère le message d’erreur, une nouvelle option --commit supportée par dpkg-source permet de générer le patch quilt correspondant. Vous devrez, dans ce processus, soumettre un nom pour le patch généré et éditer son en-tête (pré-formaté avec des champs compatibles DEP3). Le retour à l’ancien comportement peut être forcé via l’option --auto-commit.

Changement des drapeaux de compilation

Depuis que dpkg-buildpackage définit lui-même les variables d’environnement relatives à la compilation (cf. n°465282, un changement proposé originellement par Ubuntu), de nombreuses voix au sein de Debian ont exprimé leurs insatisfaction quant à l’approche retenue. Ces commentaires mettaient en avant les problèmes créés sur certains paquets, et le fait que ces mêmes variables ne sont pas définies si l’on exécute debian/rules directement.

La modification fut toutefois conservée, et les paquets « cassés » par cette dernière ont été réparés. En dépit de tout ceci, décision fut prise plus tard de créer dpkg-buildflags comme l’interface appropriée pour injecter des drapeaux de compilation.

Avant de modifier dpkg-buildpackage de sorte qu’il ne définisse plus ces drapeaux, j’ai tenu à m’assurer que dpkg-buildflags soit suffisamment répandu (au sens d’utilisé) dans l’archive, afin d’éviter de casser de nouveau un trop grand nombre de paquets. J’ai retenu comme critère l’utilisation de dpkg-buildflags par CDBS et dh (de dhbhelper). La condition d’application fut satisfaite avec la modification récente de debhelper (cf. n°544844), j’ai donc modifié dpkg-buildpackage en conséquence.

Extraits (snippets) de makefile fournis par dpkg

En parallèle de ces travaux, j’ai souhaité mettre à disposition des mainteneurs une manière simple (qui n’utilise ni dh ni CDBS) de réparer les paquets impactés d’une part, et également d’injecter les drapeaux de compilation à partir des fichiers debian/rules. Ce sera possible à compter de la prochaine version de dpkg, via un bout de code ressemblant à ceci :

DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/default.mk

Sans DPKG_EXPORT_BUILDFLAGS à 1, les variables ne sont pas exportées dans l’environnement et sont sans effet, à moins bien sûr que vous ne les utilisiez autre part.

En plus de ces drapeaux de compilation, bien d’autres variables — pouvant être utiles dans les fichiers debian/rules — seront mises à disposition par ce biais : celles fournies par dpkg-architecture, les variables/macro liées à l’outil dpkg-vendor et quelques informations de base du paquet (principalement liées à la version).

Améliorations de dpkg-buildflags

Étant donné l’importance croissante que dpkg-buildflags va prendre maintenant que dpkg-buildpackage n’initialise plus les variables d’environnement correspondantes, j’ai pris le parti de corriger tous les bogues ouverts et d’implémenter quelques suggestions qui me sont parvenues.

J’ai également discuté avec quelques membres du comité technique de la manière dont les drapeaux de compilation renforcée (hardening build flags) pourraient être activés dans Debian. Discussion qui amena également certaines idées d’amélioration.

En résumé, voici les principales modifications réalisées :

  • Nouvelle directive « prepend » permettant d’injecter les drapeaux au début de la chaîne retournée (cf. ce commit);
  • Nouvelle directive « strip » permettant d’enlever des drapeaux de la sortie retournée par dpkg-buildflags (cf. ce commit);
  • Nouvelles variables d’environnement DEB_flag_MAINT_directive pouvant être initialisées par le mainteneur afin de paramétrer la sortie de dpkg-buildflags (cf. ce commit);
  • Nouvelle option --export=configure permettant d’injecter les drapeaux via la commande ./configure (cf. ce commit);
  • Nouvelle option --dump par défaut (cf. n°603435).

Tous ces changements rendent dpkg-buildflags capable de retourner l’ensemble des drapeaux de compilation possibles (il ne retournait auparavant que les drapeaux par défaut, et l’empaquetage Debian était supposé y ajouter tout élément supplémentaire nécessaire après coup). Le travail du mainteneur se réduit maintenant, pour cette partie, à utiliser les nouvelles variables d’environnement, afin de s’assurer que les valeurs retournées correspondent bien aux besoins des paquets.

DebConf: rolling et drapeaux de compilation renforcée

J’ai participé une semaine entière à la DebConf (du dimanche 24 au dimanche 31) et, comme à l’accoutumée, ce fut un plaisir de revoir mes amis de Debian. C’est toujours difficile de trouver le bon équilibre entre assister aux conférences, travailler au hacklab et développer les relations humaines, mais je suis plutôt content du résultat obtenu.

Je n’avais aucun but précis lorsque je suis arrivé, excepté animer une session de discussion (« BoF ») autour de Debian rolling (diapos et vidéos de la discussion) . Ceci étant, toutes les discussions lors des débats allongent la TODO list, et cette année ne fit pas exception à la règle. Le BoF du comité technique aborda certaines questions en suspens, dont une m’intéresse particulièrement : comment activer les drapeaux de compilation renforcée dans Debian (cf. n°552688).

Une autre discussion sur le sujet fut prévue le mardi et il en ressort que dpkg-buildflags constitue l’interface appropriée pour injecter ces drapeaux. À condition toutefois que ce dernier offre un moyen de laisser tomber les drapeaux indésirables et dispose d’une interface pratique pour les injecter via la commande ./configure.

Compte tenu de tous ces éléments, je me mis au travail pour implémenter ces nouvelles fonctionnalités, et préparai avec Kees Cook un patch d’activation de ces drapeaux par défaut. Il n’est pas encore prêt à être intégré dans la branche officielle, mais est déjà fonctionnel. (cf. mon dernier commentaire du bogue).

Quelques mots à propos du BoF sur rolling également. Les auditeurs venus en nombre témoignent, comme à l’habitude, de l’intérêt que suscite ce sujet. Le but que je souhaitais atteindre était assez limité : mesurer le poids et l’importance respective des différentes opinions exprimées lors de la dernière discussion fleuve sur debian-devel.

Il s’est avéré qu’une majorité significative des participants estiment testing utilisable dès à présent. Mais l’opportunité de lui faire une plus grande publicité recueille des avis plus partagés. Quant à la question de savoir si nous pouvons supporter un grand nombre d’utilisateurs de testing/rolling, peu s’estiment qualifiés pour répondre, mais ceux qui le croient répondent oui.

Encore du travail sur dpkg…

Réalisation de plein de petites choses :

  • J’ai encore fait du triage de bogues sur Launchpad. Brian Murray a abattu un travail monstre et le résultat est impressionnant : nous sommes descendus à environ 150 bogues (à comparer aux 300 et plus du mois précédent !);
  • J’ai mis à jour ma branche multiarch de nombreuses fois. J’espérais rencontrer Guillem pendant la DebConf, afin de faire quelques progrès dans ce domaine, mais il n’y participa malheureusement pas. À plusieurs reprises au cours de la semaine des personnes m’ont interpellé pour avoir des nouvelles sur son intégration;
  • J’ai corrigé une régression affectant update-alternatives (bogue n°633627), l’échec d’une suite de tests lorsque lancée en tant que root (#634961), et une erreur de segmentation dans findbreakcycle(). Un bon paquet d’améliorations mineures furent également de la partie (n°634510, 633539, 608260, 632937).

Système de suivi des paquets (PTS) et DEHS

Un remplaçant de DEHS a été écrit par Christoph Berg, car celui-ci n’était pas vraiment fiable, et pas sous contrôle de l’équipe en charge de la qualité. Pour ceux qui ne connaissent pas cet outil, il s’agit d’un système centralisé utilisant les fichiers debian/watch pour détecter les dernières versions amont des logiciels disponibles dans Debian.

J’ai mis à jour le Système de suivi des paquets (PTS – Package Tracking System), afin qu’il utilise ce nouvel outil en lieu et place de DEHS. Cela fonctionne bien, mais il manque encore les notifications par mail que DEHS envoyait. Si d’aventure quelqu’un voulait contribuer cette fonctionnalité, ce serait chouette !

Empaquetages divers

J’ai accompli quelques tâches préalables à la mise à jour du paquet WordPress vers la toute dernière version upstream (3.2). Il me reste à tester le paquet qui en résulte : remplacer les copies des bibiliothèques javascript/PHP fournies par les développeurs amont présente toujours des risques, et manque de chance, elles ont toutes subies des modifications dans le processus d’intégration.

J’ai également mis à jour nautilus-dropbox vers la version 0.6.8. J’ai également uploadé la version précédente (présente dans testing jusqu’alors) dans squeeze-backports. Un paquet Debian officiel est maintenant présent pour cette application dans toutes les distributions Debian (squeeze, wheezy, sid et experimental).

Merci

Au mois prochain pour un nouveau résumé de mes activités !

Ceci est une traduction de mon article My Debian activities in July 2011 contribuée par Weierstrass01. Ne manquez pas une occasion de parfaire vos connaissances de Debian ou Ubuntu, abonnez-vous à ma newsletter en cliquant ici.

Filed Under: Actualités, Actualités Debian, Meta Tagged With: Debian, dpkg, dpkg-buildflags, dpkg-source, Hardening, Libre, Moi, tech-ctte

Correctement renommer un fichier de configuration dans un paquet Debian

Posted on 26/07/2011 Written by Raphaël Hertzog

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.

Filed Under: Documentation, Documentation pour les contributeurs Tagged With: conffile, Debian, dpkg-maintscript-helper, HOWTO, Packaging, Ubuntu

  • « Previous Page
  • 1
  • …
  • 20
  • 21
  • 22
  • 23
  • 24
  • …
  • 46
  • Next Page »

Découvrez mes ouvrages

Apprenez en plus en cliquant sur leur couverture :

Lettre d’informations

Abonnez-vous à ma lettre d'informations, saisissez votre adresse électronique et cliquez sur « S'abonner » :

Suivez moi

  • Adresse mail
  • Facebook
  • GitHub
  • RSS
  • Twitter

Archives

Planètes

  • Planète April
  • Planète Debian-Fr
  • Planète des utilisateurs Debian
  • Planète Libre

Flux Mon blog anglophone sur le libre

  • Freexian is looking to expand its team with more Debian contributors 29/03/2024
  • Freexian’s report about Debian Long Term Support, July 2022 31/08/2022
  • Freexian’s report about Debian Long Term Support, June 2022 26/07/2022
  • Freexian’s report about Debian Long Term Support, May 2022 23/06/2022
  • Freexian’s report about Debian Long Term Support, April 2022 03/06/2022
  • Debian 9 soon out of (free) security support 11/05/2022

Mots-clés

3.0 (quilt) Annonce aptitude Cahier Admin conffile Contribuer DebConf Debian Debian France Debian Live Distro Tracker dpkg dpkg-source Eyrolles Freexian GNOME GSOC HOWTO Informatique Kali Linux Libre Livres LTS Moi multiarch nautilus-dropbox nettoyage Packaging Politique Presse Pro Programmation PTS publican python-django Release Rolling Référence Résumé d'activité synaptic Testing Tryton Ubuntu unstable wordpress

Articles récents

  • Le logiciel libre a t’il une couleur politique ?
  • Mes activités libres en janvier 2017
  • Élections présidentielles, logiciel libre et Charlotte Marchandise
  • Mes activités libres en décembre 2016
  • Mes activités libres en novembre 2016

Copyright © 2025 · Focus Pro Theme sur Genesis Framework · WordPress · Log in