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 Libre

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

Posted on 06/06/2011 Written by Raphaël Hertzog

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.

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

Comment trouver le bon paquet Debian: interfaces de recherche de haut-niveau

Posted on 30/05/2011 Written by Raphaël Hertzog

L’archive Debian est connue comme l’une des plus larges collections de logiciels libres au monde. Avec plus de 16 000 paquets source et plus de 30 000 binaires, les utilisateurs ont parfois quelques difficultés à trouver les paquets qui leurs sont utiles. Le développeur Debian Enrico Zini a travaillé sur l’infrastructure pour résoudre ce problème. Durant la dernière mini-debconf à Paris, Enrico a présenté ce sur quoi il travaillait ces dernières années lors d’une conférence; travaux qui « n’avaient pas encore obtenu l’attention qu’ils méritaient ».

Enrico est connu dans la communauté Debian pour l’introduction des debtags, système de classification des paquets se basant sur des facettes. Chaque facette décrit une propriété spécifique : type d’interface utilisateur, langage de programmation utilisé, types de document manipulés, vocation du logiciel, … Ses derniers travaux s’appuient sur cette classification, et sont disponibles au travers du paquet apt-xapian-index, que ce soit sous Debian ou sous Ubuntu. L’objectif étant de permettre l’interrogation de la base des paquets disponibles au travers de requêtes complexes.

Utilisateurs de apt-xapian-index

Lors de cette présentation, Enrico a évoqué les premières utilisations de ses travaux. La plus connue étant celle proposée dans l’Ubuntu Software Center, à travers sa fonction de recherche renvoyant quasi-instantanément les résultats, et ce grâce à apt-xapian-index. Il ne s’agit là toutefois que d’une utilisation basique, n’exploitant que peu des fonctionnalités avancées fournies par apt-xapian-index.

GoPlay! est également un des premiers à l’avoir adopté, et à en utiliser certaines fonctionnalités avancées. Il s’agit d’une interface graphique permettant de rechercher des jeux. À cette fin, GoPlay! utilise les debtags pour classer les jeux en différentes catégories de sorte que vous puissiez, par exemple, naviguez parmi tous les jeux d’action/arcade 3D ayant un lien avec les voitures. Le concept de GoPlay! a même été étendu jusqu’à devenir un navigateur de paquets plus généraliste se basant sur les debtags. C’est ainsi que le paquet fournit maintenant également GoLearn!, GoAdmin!, GoNet!, GoOffice!, GoSafe!, et GoWeb!.

Autre exemple, Fuss-launcher est un lanceur d’application, et non pas un navigateur de paquets. Mais il utilise également apt-xapian-index, et il est du coup capable, en se basant sur les informations stockées au niveau des paquets, de retrouver plus facilement les applications installées. En effet, les descriptions de paquets sont généralement plus verbeuses que celles contenues dans les fichiers .desktop. Autre fonctionnalité sympathique qu’Enrico a montré à son audience : en faisant un glisser-déposer d’un document dans Fuss-launcher, ce dernier vous dresse la liste des applications pouvant l’ouvrir !

Enfin, apt-xapian-index met également à disposition un outil de recherche en ligne de commande qui est beaucoup plus efficace, et de loin, au traditionnel apt-cache search : il s’agit de axi-cache search (axi étant ici l’acronyme de apt-xapian-index). Enrico fit la comparaison de la sortie d’apt-cache avec celle d’axi-cache, avec comme entrée la recherche de la lettre « r » : tandis que apt-cache énumérait une liste infinie de paquets contenant cette lettre quelque part dans leurs descriptions, axi-cache ne lista que les paquets concernant GNU R. Il fit également une démonstration de la complétion contextuelle automatique : contextuelle car se basant sur les debtags pour raffiner la recherche. En effet, une fois un premier mot-clé tapé, la complétion via la touche Tab ne montre que certains mots-clé ou debtags : ceux permettant de restreindre encore plus la recherche. L’interrogation via des requêtes à base d’opérateurs logiques (AND, OR, NOT, XOR) est également supportée.

Sous le capot

Enrico présenta ensuite les rouages de cette mécanique. Le moteur de recherche Xapian est au cœur de l’infrastructure, et il l’apprécie car il ne s’agit que d’une simple librairie (et non un démon), pourvue de sympathiques bindings Python. Des plugins, également écrits en Python, peuvent venir étendre les capacités d’apt-xapian-index, qui, même si sa fonction principale reste l’indexation des descriptions de paquets, enregistre beaucoup plus d’informations que nécessaires à cette tâche.

Parmi les informations stockées, on compte par exemple :

  • des mots apparaissant dans la description des paquets (ce qui inclut les traductions, dans le cas où l’utilisateur utilise une locale non anglaise);
  • l’origine des paquets;
  • leurs sections;
  • leurs tailles, ainsi que l’empreinte disque une fois installés;
  • leurs dates de première apparition;
  • les icônes, catégories ou descriptions des fichiers .desktop contenus (via app-install-data);
  • les alias d’applications populaires non disponibles sous Linux (par exemple « excel » renvoie au debtag office::spreadsheet).

Enrico a d’ores et déjà prévu d’enregistrer encore plus d’information : ajouter les données du popularity contest (cf. les rapports de bogue #602180 et #602182) lui permettrait ainsi de trier les résultats de manière efficace. En effet, les applications les plus utilisées sont généralement un bon choix en terme de support de la communauté, ainsi que du point de vue de la qualité, précisément du fait de cette large base d’utilisateurs. Stocker les dates de dernière installation/mise à jour/suppression rendrait plus facile la détermination d’une régression, due à une mise à jour d’un paquet particulier.

L’index étant accessible sans restriction, n’importe quelle application peut en tirer profit, sous réserve qu’elle puisse utiliser la librairie Xapian – écrite en C++ mais disposant de bindings Perl, Python, PHP, Java, Tcl, C# et Ruby.

Appel à l’expérimentation

De nombreuses applications utiles reposant sur apt-xapian-index restent encore à inventer, selon Enrico. Il lance ainsi un appel à « l’expérimentation », ainsi qu’à de nouvelles idées. La seule limite pratique à laquelle il s’est confronté est la taille de l’index : entre 50 (Debian unstable sans aucune traduction) et 70 Mo (Debian stable/testing/unstable avec les traductions dans une langue). Il préférerait ne pas le voir dépasser 100 Mo, dans la mesure, d’une part, où le paquet est installé par défaut (étant un paquet recommandé par aptitude), et d’autre part parce qu’il serait mal à l’aise à l’idée d’utiliser plus de 20% de l’empreinte disque d’une installation minimale juste pour ce service. C’est la raison pour laquelle l’index a été configuré pour ne pas stocker la position des mots-clé : il n’est donc pas possible de trouver les paquets dont la description contient le terme « calcul » immédiatement suivi de « statistique ». Par contre, il est possible de trouver ceux contenant les deux mots n’importe où dans leurs descriptions.

Apt-xapian-index offrirait-il trop de libertés ? C’est la question que s’est posé Enrico. Ce qui pourrait expliquer pourquoi si peu de personnes l’ont testé, malgré les nombreux billets sur son blog, dûment documentés avec exemples de code et tutoriaux. Mais il n’est pas difficile d’imaginer d’autres exemples d’utilisation : on pourrait ainsi étendre les fonctionnalités d’outils tels que rc-alert ou wnpp-alert par exemple, qui fournissent une longue liste de paquets Debian cherchant un peu d’aide, et qui sont installés sur la machine. Il serait ainsi possible d’utiliser apt-xapian-index pour restreindre les résultats aux seuls paquets écrits dans un certain langage, ou dédiés à un environnement de bureau particulier.

L’explication la plus probable étant certainement que trop peu de personnes ont entendu parler de cet outil. Il y a bien d’autres cas où les fonctionnalités d’apt-xapian-index pourrait être utile, et, à mon sens, le souhait d’Enrico pourrait bien devenir réalité.

Cet article est une traduction de How to find the right Debian packages: high-level search interface contribuée par Weierstrass01. Suivez moi sur Identi.ca, Twitter et Facebook. Ou abonnez-vous à ce blog par RSS ou par email.

Filed Under: Actualités, Actualités Debian, Actualités Ubuntu Tagged With: apt-xapian-index, Debian, debtags, Enrico Zini, Libre, Recherche, Ubuntu, Xapian

Solutions Linux cette semaine, DebConf cet été

Posted on 09/05/2011 Written by Raphaël Hertzog

Je n’ai jamais été un grand baroudeur, mais à une époque où les circonstances étaient plus favorables pour moi, je me rendais avec plaisir à 4-5 conférences Linux chaque année. L’année dernière avec mon fils de quelques mois, j’ai fait un break et je ne suis même pas allé à la conférence Debian à New York.

Cette année je reprends du service. De mardi à jeudi, je serai sur le stand Debian au salon Solutions Linux avec quelques autres représentants de l’association Debian France. Du côté organisateur, on sera apparemment en comité restreint par rapport aux années précédentes. Je ne me l’explique pas, si ce n’est que le noyau dur vieillit, est plus occupé, et que la relève tarde à montre le bout de son nez!

J’invite donc tous ceux qui souhaitent s’impliquer dans Debian à venir nous voir sur le stand Debian (dans le village associatif, stand C55). On se fera un plaisir de vous accueillir et de vous aider à faire vos premiers pas dans la communauté.

Bien entendu nous serons également là pour répondre aux questions des utilisateurs (que l’on attend nombreux comme à chaque fois) et pour présenter le projet à tous ceux qui veulent en savoir plus. À titre plus personnel, j’aurai une copie du Cahier de l’Admin Debian à montrer et c’est avec plaisir que je dédicacerai le livre à ceux qui penseront à l’emmener!

Plus tard dans l’année, cet été, je me rendrai à Banja Luka pour la DebConf 2011. J’ai acheté mes billets d’avion et je serai présent la semaine complète (24-31 juillet).

Participer à une DebConf n’a rien à voir avec tenir un stand sur un salon. C’est une conférence par les Debianeux et pour les Debianeux. Cela permet de rencontrer les personnes avec lesquelles on collabore toute l’année via email/IRC. On présente nos projets respectifs, on discute d’idées que l’on a pour le futur, on expérimente, parfois on corrige des bogues. Mais surtout on apprend à mieux se connaître… la plupart des tensions qui apparaissent dans les échanges par email s’évanouissent lors d’une DebConf.

Si vous êtes contributeur à Debian, je vous invite vraiment à nous rejoindre, c’est une expérience très enrichissante. Les inscriptions c’est par ici (avant le 19 mai si vous avez besoin d’une aide financière pour vous permettre le voyage). Évidemment l’anglais est de rigueur… mais nous avons tous un accent médiocre, donc pas de soucis, on ne se moquera pas de vous. 🙂

Filed Under: Actualités Tagged With: Conférence, DebConf, Libre, Solutions Linux

Le plan secret derrière le format de paquet source Debian « 3.0 (quilt) »

Posted on 20/04/2011 Written by Raphaël Hertzog

New source package formats do wondersBien qu’ayant passé un nombre incalculable d’heures au développement du nouveau format source connu sous le nom de « 3.0 (quilt) », je n’ai réalisé que récemment que je n’avais encore rien écrit quant aux motivations qui m’ont conduit à le faire. Oubli auquel cet article va remédier.

Le bon vieux format « 1.0 »

Jusqu’en 2008, dpkg-source n’était capable de gérer qu’un seul format source, maintenant connu comme le « 1.0 ». Il s’agissait du format utilisé depuis le commencement du projet et, bien que fonctionnant sans problème dans la majorité des cas, il souffrait d’un certain nombre de limitations. Ceci principalement parce qu’il gérait l’empaquetage Debian comme un patch devant être appliqué par dessus le tarball source originel.

Ce patch pouvait avoir deux fonctions : créer les fichiers requis dans le sous-répertoire Debian et appliquer les modifications aux sources upstream. Mais au fil du temps, si le mainteneur du paquet procédait à plusieurs modifications du code source d’origine, ces dernières atterrissaient pêle-mêle — et sans documentation — dans ce seul patch. Des systèmes de gestion des patchs (dpatch, quilt, simple-patchsys, dbs, …) furent créés pour remédier à ce problème, et de nombreux mainteneurs commencèrent à les utiliser. L’implémentation diffère légèrement d’un système à l’autre, mais le principe de base reste le même : conserver les modifications des sources originales comme autant de patchs dans le dossier debian/patches/ et les appliquer à la compilation (et les enlever dans la règle clean en charge du nettoyage de l’arborescence).

Objectifs des nouveaux formats

Lorsque j’ai commencé à travailler sur le nouveau format source, j’avais comme objectif de m’affranchir des limitations connues et d’intégrer un système de gestion des patchs à dpkg-source. Je tenais à clarifier la situation de telle sorte que le fait d’apprendre à empaqueter ne nécessitait la connaissance que d’un seul système de patchs, et ne passait plus par la modification des debian/rules pour utiliser ce dernier. Je choisis quilt dans la mesure où il était populaire, disposait d’un large panel de fonctionnalités, et ne souffrait pas du syndrome du NIH. Tout cela conduisit au format source « 3.0 (quilt) ».

Dans le même temps naquit « 3.0 (native) » en tant que format distinct. Le format « 1.0 » était capable de générer deux types de paquet sources (natif et non-natif), mais je ne tenais pas à faire perdurer ce mélange des genres au sein d’un même format. Le principe du KISS édicte que l’utilisateur doit sélectionner le format de son choix, le mettre dans debian/source/format et c’est tout. Point final. Maintenant la compilation peut légitimement échouer lorsque les pré-requis ne sont pas satisfaits, plutôt que de basculer vers un « plan B » consistant en comportements inattendus.

Fonctionnalités du format « 3.0 (quilt) »

Il s’agit du format remplaçant le format 1.0 (non-natif). Les fonctionnalités ci-dessous sont spécifiques au nouveau format et le différencient de son ancêtre :

  • Support des formats de compression autres que gzip: bzip2, lzma, xz;
  • Utilisation de plusieurs tarball amont possible;
  • Inclusion de fichiers binaires dans l’empaquetage Debian possible;
  • Remplacement automatique du dossier « debian » dans le tarball amont (aucun ré-empaquetage nécessaire);
  • Création d’un patch (au standard quilt) dans debian/patches/ lorsque des changements par rapport aux fichiers upstream sont rencontrés.

Fonctionnalités du format « 3.0 (native) »

Ce format est très similaire à la variante « native » du format « 1.0 », excepté sur deux points :

  • Support des formats de compression autres que gzip: bzip2, lzma, xz;
  • Exclusion automatique des fichiers ne devant normalement pas faire partie du paquet (fichiers spécifiques aux VCS, fichiers de sauvegarde vim, …).

Chronologie

Un petit retour sur l’histoire de ce projet est intéressant. Celui-ci a déjà quelques années d’activité et ne pourra être considéré comme terminé uniquement lorsqu’une majorité de paquets auront migré vers les nouveaux formats.

  • Janvier 2008 : la discussion Comment gérer les patchs convenablement enflamme la liste de diffusion debian-devel@lists.debian.org. Le résultat de cette discussion constitue mes orientations initiales;
  • Mars 2008 : Je finis de concevoir les nouveaux formats et je lance un appel à retours d’utilisation. dpkg 1.14.17 (uploadé dans experimental) est la toute première version les supportant;
  • Avril 2008 : Demande aux ftpmasters via le ticket n°457345 de supporter les nouveaux formats de paquet source;
  • Juin 2008 : gel de Lenny. dpkg n’est plus supposé connaître de changements. Plusieurs changements concernant les nouveaux formats source sont cependant acceptés dans les mois qui suivent dans la mesure où ce code n’est, d’une part, pas encore utilisé en production, et d’autre part, car sa présence n’est requise que dans la mesure où elle doit permettre à Lenny de gérer les nouveaux formats lorsque Squeeze aura commencé à les utiliser;
  • Février 2009 : publlication de Lenny.
  • Mars 2009 : le travail sur Squeeze a débuté, mais les ftpmasters n’ont toujours rien fait concernant le support des nouveaux formats. Je soumets un patch à la suite du ticket n°457345 pour accélérer les choses. Je mets en place une page wiki pour suivre l’avancement du projet et répondre aux questions usuelles des mainteneurs de paquets;
  • Novembre 2009 : Après un sprint des ftpmasters, il est alors possible d’uploader des paquets aux nouveaux formats sources dans unstable. Cela focalise l’attention sur les nouveaux formats et certaines personnes commencent à se plaindre de certaines décisions de conception. L’implémentation du format « 3.0 (quilt) » change considérablement durant ce mois. La version de dpkg dans Lenny est même mise à jour pour la garder synchronisée avec ces changements;
  • Mars 2010 : je prévoyais jusque-là de laisser dpkg-source compiler lui-même les nouveaux paquets source dans le futur. Après plusieurs échanges, je conçois que cela ne constitue pas la meilleure manière de procéder et rend à la place obligatoire le fichier debian/source/format. Le mainteneur doit explicitement désigner le format source qu’il souhaite utiliser;
  • Octobre 2010 : Les nouveaux formats source sont relativement populaires : un tiers des paquets source ont déjà changé de format, cf. ce graphique. Le gel de Squeeze en août a clairement stoppé la dynamique;
  • Février 2011: Publication de Squeeze, les mainteneurs peuvent à nouveau faire évoluer leur paquets et le taux de conversion des paquets repart à nouveau.
  • Juin 2013 : fin du projet ?

Comme vous pouvez le constater, le projet n’est pas encore terminé, bien que la partie la plus difficile soit passée. En ce qui me concerne, le plus grand enseignement que j’en retire est que vous n’aurez jamais suffisamment de retour tant que votre travail n’est pas dans unstable. Aussi, si vous menez un projet Debian impactant un grand nombre de personnes, assurez-vous d’organiser un processus de revue officiel dès le début. Une des meilleures manières de le faire consiste probablement à décrire votre projet à travers une Proposition d’amélioration de Debian.

Si vous appréciez les efforts que j’ai consacrés à ce projet, n’hésitez pas à ouvrir un compte Flattr et à soutenir dpkg de temps en temps. Ou à visiter ma page « Soutenir mon travail« .

Cet article est une traduction de The secret plan behind the « 3.0 (quilt) » Debian source package format contribuée par Weierstrass01.

Filed Under: Actualités, Actualités Debian Tagged With: 3.0 (native), 3.0 (quilt), dpkg, dpkg-source, Libre, Moi, Packaging

  • « Previous Page
  • 1
  • …
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 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