dpkg

Mes activités Debian en juin 2011

06/07/2011 Par 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 (195 €, 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.

Dropbox pour Debian

Dropbox n’est pas un logiciel libre, mais n’en est pas moins très populaire. Ils ne mettent à disposition qu’un paquet pour Ubuntu, qui ne fonctionne pas sous Debian. J’ai donc créé un paquet officiel.

En contact avec des développeurs Dropbox, ils m’ont été d’une aide précieuse. Ils vont très prochainement lancer un mécanisme de signatures (avec GPG), de telle sorte que nous pourrons bientôt améliorer le paquet en vérifiant l’origine des binaires téléchargés.

SAT Britney

J’ai continué — au début du mois — mon travail sur la ré-implémentation de britney (l’application créant testing à partir d’unstable). J’ai cependant rapidement mis en sommeil mon travail, dans la mesure où les release managers ont demandé l’avis de Stefano Zacchiroli et Ralf Treinen (qui ont une connaissance approfondie du sujet, de par leur travail de recherche sur Mancoosi). Je n’ai pas souhaité aller plus loin, au cas où ils identifient une faiblesse majeure. Leur retour n’est arrivé qu’en fin de ce mois, et, bien que quelque peu négatif, je continue à penser que le travail mérite d’être poursuivi plus en avant.

Conversion de ftplib à multiarch

Tandis que dpkg ne supporte toujours pas multiarch (aucune nouvelle de Guillem à ce sujet, et aucun signe de progression visible ), unstable a récupéré les derniers éléments nous permettant de convertir les bibliothèques au multi-architecture (cf. l’annonce correspondante). A l’instant où la version requise de libc6 a atterri dans unstable, j’ai cherché à convertir le seul paquet de bibliothèque que je maintiens. Je n’ai eu aucune difficulté majeure, seulement deux problèmes dans Lintian (référencés sous le n°630164 et rapidement corrigés par Niels Thykier).

Support build-arch / build-indep

L’idée d’utiliser des cibles build-arch/build-indep dans le fichier debian/rules a ressurgi pour la 42ème fois en 10 ans. J’avais déjà décidé, voilà quelques temps de cela, d’accepter un patch implémentant un champ Builld-Features: build-arch, afin de permettre à dpkg-buildpackage d’utiliser ces cibles. Bill Allombert a terminé ce patch, je l’ai donc intégré.

Le comité technique a également décidé qu’il prendrait une décision définitive sur ce sujet (cf. n°629385). Roger Leigh a apporté une contribution utile en recompilant l’archive complète avec toutes les solutions proposées. Étant donné qu’une majorité souhaite rendre la cible obligatoire dans le futur, j’ai contribué un patch dpkg pour ma solution préférée. L’auto-détection de la cible serait utilisée temporairement jusqu’à ce que tous les paquets soient modifiés afin d’embarquer de telles cibles.

Le comité technique n’a encore pris aucune décision, bien que la discussion soit au point mort depuis le 12 juin. Rien d’anormal ici, je suis sûr que le point sera soldé durant la DebConf.

Activités diverses sur dpkg

Modification de dpkg-source --after-build permettant de retirer automatiquement les patchs, s’ils ont été appliqués via dpkg-source --before-build
Pas mal de corrections de bogues (n° 628726, 629582, 630996, 631435, 631439, 631547, 632168), ce qui permet à peine d’équilibrer avec le nombre de nouveaux bogues rapportés !
Ajout de 2 modules Perl supplémentaires à l’API supporté, au profit de Lintian.
Une soirée passée à investiguer les causes possibles d’une vieille et ennuyeuse assertion failure liée aux triggers.
Mise à jour de ma branche avec les directives triggers améliorées, pour prendre en compte les remarques de Guillem, puis intégration de cette branche.
En traitant le point précédent, j’ai découvert une faiblesse conceptuelle dans l’usage de « prerm failed-upgrade », et intégré une correction.
Discussion de l’intégration de dpkg-buildflags dans debhelper dans le bogue 544844, ce qui a conduit à la décision d’implémenter de nouvelles améliorations pour dpkg-buildflags.

Mise à jour de l’applet Hamster

Hamster-applet est une application GNOME n’ayant pas de version 3.0, mais une en développement (2.91.x). J’ai regardé s’il n’était pas possible de l’empaqueter pour experimental, et ainsi avoir l’applet fonctionnelle dans le mode dégradé de GNOME 3. Apparemment pas. Le code n’a pas encore été mis à jour pour être compatible avec le nouveau panneau.

J’ai envoyé dans unstable la dernière version stable (2.32.1) à la place, qui a quelques améliorations intéressantes dans sa version standalone (et le nom de l’exécutable est différent). En attendant une meilleure intégration avec GNOME 3, j’ai créé un raccourci pour le démarrer rapidement (avec gconf-editor, entrer la valeur « <Mod4>t » pour le champ /apps/metacity/global_keybindings/run_command_1, et « hamster-time-tracker » pour /apps/metacity/keybinding_commands/command_1. Le panneau de contrôle de GNOME 3 ne semble en effet pas gérer les raccourcis claviers actuellement).

Traduction de mon site professionnel en anglais

Bien que particulièrement reconnaissant envers les personnes supportant activement mon travail, je suis encore loin d’avoir atteint mon objectif d’être financé pour un tiers de mon temps de travail par des donations et la vente de produits via ce site.

J’ai donc décidé de donner un peu plus de visibilité à mon site professionnel, et en particulier à son offre de services liée à Debian. Elle n’était disponible qu’en français, je l’ai traduite et étoffée quelque peu. Ma « page de soutien » sur ce blog pointe maintenant également vers le site web de mon entreprise.

Si votre entreprise a besoin d’aide pour créer des paquets Debian, ou requiert un support technique par mail, ne cherchez plus !

Je propose d’ailleurs des réductions pour les particuliers ou organisations à but non lucratifs désirant bénéficier de mon expertise pour créer des paquets Debian.

The Debian Administrator’s Handbook

Il s’agit là du titre de la traduction à venir de mon livre. Ce projet dispose maintenant d’un site dédié : debian-handbook.info.

Vous pouvez vous inscrire à son flux RSS pour obtenir les dernières nouvelles le concernant. La table des matières complète est en ligne, accompagnée d’une FAQ.

Je recherche activement des partenaires pour promouvoir la campagne de financement à venir. Si vous êtes en mesure de toucher un nombre conséquent de lecteurs intéressés par une bonne référence sur Debian, contactez-moi afin de rejoindre le programme affilié.

Merci

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

Ceci est une traduction de mon article My Debian activities in June 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.

Dans la/les catégorie(s): Actualités Etiqueté avec: build-arch, dpkg, Dropbox, Freexian, Hamster-applet, Libre, Moi, multiarch, Résumé d'activité, SAT-Britney

Mes activités Debian en mai 2011

07/06/2011 Par Raphaël Hertzog

Voici mon récapitulatif mensuel de toutes mes activités gravitant autour de Debian. Si vous faites partie des personnes m’ayant fait un don pour soutenir mon travail, 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.

Au cours du mois de mai, j’ai donc…

…un peu travaillé sur le concept de Debian Rolling

Les discussions au sujet de Debian Rolling étaient encore très actives en début de ce mois sur la liste debian-devel. L’idée de renommer testing en rolling (ce que je soutenais) n’a pas prévalu car certains jugeaient que des bugs Release Critical restaient ouverts trop longtemps dans cette distribution et me méritait donc pas ce label. La proposition la plus consensuelle a été celle de Josselin Mouette : elle consiste à bâtir la distribution rolling d’après testing, en y ajoutant quelques paquets choisis de unstable.

Je considère cette solution viable à la condition de la restreindre à un sous-ensemble précis d’architectures. Dans le cas contraire, les raisons pour lesquelles les paquets ne migrent pas vers testing impacteront rolling de la même manière. Et si ces raisons n’existent pas, alors autant effectuer les migrations correspondantes directement dans testing au lieu de rolling.

Étant donné ce qui précède, j’ai installé sur mon ordinateur portable britney — le logiciel qui contrôle testing — pour voir comment créer rolling avec cet outil. britney s’avère être un logiciel très spécialisé, avec très peu de possibilités de paramétrage.

Au même moment, Joachim Breitner fit une proposition qui attira immédiatement mon attention. Il suggère d’utiliser les solveurs SAT pour déterminer l’ensemble des paquets devant migrer de unstable vers testing. rolling peut être, à mon sens, un excellent banc d’essai pour cette nouvelle implémentation de britney (qu’il nomme ici SAT-britney). J’ai donc embarqué sans hésiter à bord de ce projet.

Les notions scientifiques sous-tendant le concept m’étant peu familières, j’ai compulsé de la documentation et appris que tous les solveurs SAT intégraient le problème sous une forme bien particulière, appelée Forme Normale Conjonctive. De plus, le format DIMACS est le format de fichiers retenu pour présenter ces contraintes booléennes. Plusieurs solveurs SAT sont disponibles pour Debian, et picosat semble être un des meilleurs.

J’ai donc commencé à coder pour voir comment appliquer le concept, le résultat est disponible dans ce dépôt git. Vous pouvez en récupérer une copie via git clone git://git.debian.org/~hertzog/sat-britney.git.

Il n’y a pas encore grand chose, excepté un peu de code (en Python) générant un problème SAT pouvant être passé à un solveur. Mais je suis impatient de voir les développements de ce projet.

…représenté Debian au salon Solutions Linux

J’ai passé 3 jours à Paris dans la deuxième semaine du mois de mai, pour prêter main forte à la tenue du stand Debian au salon Solutions Linux

Nous avons répondu à beaucoup de questions mais la majorité des visiteurs connaissaient déjà Debian, et beaucoup l’utilisent à la maison et/ou au travail. Nous avons essayé de recruter de nouveaux adhérents dans l’association Debian France, et vendu les goodies qui nous restaient.

Les représentants d’Ubuntu ont été interviewés par France 3, et nous avons profité de l’opportunité (avec leur accord !) pour exhiber nos t-shirts Debian à l’arrière-plan. La vidéo est disponible ici, et vous pouvez nous y voir (Carl Chenet et moi-même) à 1:21.

Nous avons été interviewés quant à nous par Intelli’n TV: une première vidéo et une seconde. J’avoue ne pas exceller dans cet exercice !

…amélioré les triggers dpkg

La troisième semaine de mai était une semaine de vacances, et j’aurai du me tenir loin de mon ordinateur. Mais je tenais vraiment à la mettre à profit pour améliorer l’état des triggers dpkg dans Debian.

J’ai déjà abordé mon travail dans un précédent article : Trying to make dpkg triggers more useful and less painful.

Dans l’attente d’une synthèse des réponses à la question que j’ai envoyée à tous les mainteneurs de paquets utilisant les triggers, je n’ai pas encore intégré le résultat de mon travail dans le dépôt officiel.

…aidé les utilisateurs suite à la migration d’Alioth

Lorsque je suis revenu de vacances, un certain nombre de services fournis par alioth.debian.org étaient non-fonctionnels après la migration vers un nouvel environnement, impliquant deux machines au lieu d’une auparavant. Étant donné que je fus longtemps un administrateur d’Alioth, je suis bien placé pour savoir qu’en de telles circonstances, vous vous retrouvez vite submergé par les demandes de support utilisateur. Je suis donc retourné sur le canal #alioth d’IRC afin d’aider au mieux.

J’ai investigué certains des problèmes soulevés et mis au point des corrections (scripts mis à jour, fichiers de configuration, etc.) pour quelques-uns d’entre eux. J’ai également créé une liste des problèmes restants. Elle n’aurait du exister que quelques jours mais, en raison de régressions encore non résolues, est toujours active.

Les fonctionnalités les plus importantes manquant encore sont :

un support propre pour la délégation des droits. Par le passé, nous utilisions les ACL mises en place par les administrateurs. Avec le nouveau FusionForge, chaque admin de projet devrait être capable de déléguer des droits à des « rôles » extérieurs. Un rôle « Développeur Debian » existe déjà, mais la délegation echoue… ;
l’accès à l’Ultimate Debian Database. De nombreux outils s’appuient sur cette base de données pour fonctionner ;
l’accès en FTP anonyme pour télécharger les fichiers des projets ;
des directives claires sur la manière dont nous sommes censés gérer les sites web mis à jour à travers des hooks VCS ;
des directives claires sur la manière dont nous sommes supposés gérer les dépôts git personnels.

…amélioré le format de paquet source « 3.0 (quilt) »

J’ai émis plusieurs propositions visant à modifier le comportement du nouveau format source. L’objectif visé est double : premièrement, le rendre moins pénible à l’utilisation pour les empaqueteurs utilisant un VCS, et, deuxièmement, éviter les changements non souhaités qui s’immisceraient via un nouveau patch généré par dpkg-source.

Ces propositions semblent être consensuelles, je pourrai donc les implémenter dans un avenir proche.

…un peu laissé de côté la version anglaise de mon blog

Beaucoup de travail a été abattu pour Debian entre les déplacements et les vacances et, dans le temps restant, je n’ai pas réussi à écrire beaucoup de nouveaux articles pour mon blog anglophone.

En fait, mis à part l’article sur les triggers mentionné précédemment, je n’ai publié qu’une interview : People behind Debian: Steve Langasek, release wizard.

Je vais essayer de faire mieux ce mois-ci !

Merci !

Un grand merci à ceux qui m’ont soutenu à hauteur de 151.61 € durant le mois de mai.

Rendez-vous le mois prochain pour un nouveau compte-rendu de mes activités Debian !

Cet article est une traduction de My Debian activities in May 2011 contribuée par Weierstrass01.

Dans la/les catégorie(s): Meta Etiqueté avec: 3.0 (quilt), Alioth, Blog, britney, Debian, Debian France, dpkg, Libre, Moi, Rolling, SAT, Solutions Linux, triggers

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

06/06/2011 Par 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.

Dans la/les catégorie(s): Documentation, Documentation pour les contributeurs Etiqueté avec: conffile, Debian, dpkg, dpkg-maintscript-helper, HOWTO, Libre, Packaging, Ubuntu

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

20/04/2011 Par Raphaël Hertzog

New source package formats do wonders Bien 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.

Dans la/les catégorie(s): Actualités, Actualités Debian Etiqueté avec: 3.0 (native), 3.0 (quilt), dpkg, dpkg-source, Libre, Moi, Packaging

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

14/04/2011 Par Raphaël Hertzog

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.

Dans la/les catégorie(s): Documentation, Documentation pour les utilisateurs Etiqueté avec: Debian, dpkg, Espace disque, HOWTO, Libre, Référence, Ubuntu

Comment ajuster le comportement de dpkg-source dans un paquet source Debian

20/12/2010 Par Raphaël Hertzog

Dpkg-source est le programme chargé de générer un nouveau paquet source Debian lors d’un changement de version. Bien qu’il offre de nombreuses options intéressantes en ligne de commande, celles-ci ne sont que rarement utilisées… faute de savoir comment faire pour que ces options soient systématiquement utilisées ! Nous allons voir comment y remédier.

Solution la plus évidente : passer des options à dpkg-source via la ligne de commande de dpkg-buildpackage. L’inconvénient étant bien sûr qu’il faut s’en rappeler à chaque fois ! On peut partiellement y remédier en créant des alias shell incluant ces options. Mais il faudra autant d’alias que de combinaisons d’options. Pas très pratique…

La solution adéquate a été implémentée l’année dernière, à partir de la version 1.15.5 de dpkg. Elle consiste à entrer ces options dans debian/source/options. N’importe quelle option commençant par « -- » peut y être incluse, à raison d’une option par ligne, « -- » étant omis. Exemple :

# Utilisation de la compression Bzip2 pour debian.tar
compression = "bzip2"
compression-level = 7
# Pas de diff pour les modifications de config.(sub|guess)
extend-diff-ignore = "(^|/)config.(sub|guess)$"

À noter : l’utilisation d’espaces autour du signe égal est ici possible, contrairement à la ligne de commande. L’encadrement de la valeur par des guillemets est possible mais non obligatoire.

Au final, debian/source/options faisant parti du paquet source, n’importe qui d’autre le récupérant générera le paquet avec les options que vous aurez entrées dans ce fichier.

Le même résultat peut être obtenu en utilisant le fichier debian/source/local-options. La seule différence étant que ce fichier ne sera pas inclus dans le paquet source, ce qui peut être intéressant si vous travaillez avec un logiciel de gestion de versions (VCS, Version Control Repository) tel que git, svn, bazaar etc… avec des options que les utilisateurs finaux ne doivent pas passer. Certaines options (telle que --unapply-patches) ne sont autorisées que dans ce fichier, pour ne pas surprendre l’utilisateur du paquet source généré avec un comportement inattendu.

Vous pourrez en apprendre bien plus sur les options de dpkg-source en consultant sa page de manuel. Je suis persuadé que vous y découvrirez des options qui vous sont inconnues ! Saviez-vous, par exemple, que vous pouviez demander à dpkg-source d’interrompre le processus s’il détectait que certaines modifications amont n’étaient pas gérées par un patch existant dans debian/patches ? Il s’agit de l’option --abort-on-upstream-changes, et elle ne peut être utilisée que dans le fichier debian/source/local-options.

Cet article est une traduction de How to customize dpkg-source’s behaviour in your Debian source 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.

Dans la/les catégorie(s): Documentation, Documentation pour les contributeurs Etiqueté avec: Debian, dpkg, dpkg-source, HOWTO, Packaging, Ubuntu

Tout ce qu’il faut savoir sur les conffiles: les fichiers de configuration gérés par dpkg

13/12/2010 Par Raphaël Hertzog

La charte Debian enjoint chaque mainteneur de paquet à conserver, lors des mises à jour, les modifications des fichiers de configuration effectuées par l’utilisateur. Cet article a pour but de présenter la manière dont la plupart des paquets accomplissent cette tâche. Il s’agit d’un sujet critique pour quiconque est amené à gérer des mises à jour, avec en ligne de mire une automatisation aisée du processus et une réduction des effets de bord !

Comment dpkg gère les fichiers de configuration

La plupart des paquets se basent sur dpkg pour installer correctement leurs fichiers de configuration. Dpkg garde une somme de contrôle de la version originale de chaque fichier de configuration, de sorte qu’à chaque mise-à-jour la comparaison entre la somme de contrôle originale et celle du fichier de configuration actuel suffit à savoir si l’utilisateur y a apporté des modifications, ou non. Si tel est le cas — les sommes de contrôle sont alors différentes — le remplacement du fichier de configuration est intercepté et le système demande à l’utilisateur quoi faire. Vous avez probablement déjà croisé ces quelques lignes :

Fichier de configuration "/etc/bash.bashrc"
 ==> Modifié (par vous ou par un script) depuis l'installation.
 ==> Le mainteneur du paquet a envoyé une version mise à jour.
   Que voulez-vous faire ? Les options sont les suivantes
    Y or I  : installer la version du responsable de paquet
    N or O  : garder votre version actuellement installée
      D     : afficher les différences entre les versions
      Z     : suspendre ce processus pour examiner la situation
 L'action par défaut garde votre version actuelle.
*** bash.bashrc (Y/I/N/O/D/Z) [défaut=N] ?

Dans l’exemple précédent, la réponse « Y » (« Yes ») ou « I » (« Install ») entraînera l’installation de la version mise à jour de /etc/bash.bashrc, ainsi que la sauvegarde de la version actuelle sous le nom de /etc/bash.bashrc.dpkg-old. Dans le cas inverse (option « N » (« No ») ou « O » (« Old »)), dpkg laissera au contraire la version actuelle de /etc/bash.bashrc intacte, tandis que la nouvelle version sera sauvegardée dans le fichier /etc/bash.bashrc.dpkg-dist. Les deux options restantes permettent de suspendre la mise à jour, le temps d’examiner la situation. Dans le cas où vous décidez de lancer un terminal (« Z »), la nouvelle version est alors disponible en tant que /etc/bash.bashrc.dpkg-new (les variables d’environnement — apparues avec Squeeze — $DPKG_CONFFILE_OLD et $DPKG_CONFFILE_NEW permettant de créer un script de comparaison « maison »).

Le nom de « conffiles » donné aux fichiers de configuration traités par dpkg leur vient du nom du champ dans lequel ils sont enregistrés dans la base de données dpkg. L’option --status permet d’afficher la liste des conffiles pour n’importe quel paquet :

$ dpkg --status bash
[...]
Conffiles:
 /etc/skel/.profile ecb6d3479ac3823f1da7f314d871989b
 /etc/skel/.bashrc 2afdd6c53990f2387a7ef9989af0bc07
 /etc/skel/.bash_logout 22bfb8c1dd94b5f3813a2b25da67463f
 /etc/bash.bashrc 5b3c3bc73d236e4e1b6f9b6c1ed5964e
[...]

La commande « dpkg-query --showformat='${Conffiles}\n' --show bash » vous permet de restreindre la sortie à cette information uniquement. Les 32 caractères à droite de chaque chemin d’accès correspondent à la somme de contrôle MD5 du fichier de configuration original correspondant.

Éviter l’indécision due aux fichiers de configuration

Chaque fois que dpkg se trouvera dans la situation de devoir installer un fichier de configuration dont vous aurez modifié la version précédente (ou supprimé, ce qui n’est qu’un cas particulier de la modification pour dpkg), il suspendra le processus dans l’attente d’une décision de votre part. Ce qui peut-être particulièrement ennuyeux lors de mises à jour conséquentes. Pour parer à de telles situations, le comportement de dpkg peut être prédéterminé à l’aide des options --force-conf* :

--force-confold: la version actuelle est systématiquement conservée, la nouvelle étant installée avec le suffixe .dpkg-dist. Cette option passée seule entraîne également le non-remplacement des anciens fichiers de configuration que vous n’avez pas modifiés. L’option --force-confdef doit être également passée pour que ces derniers soient remplacés.
--force-confnew: installer systématiquement la nouvelle version du fichier, l’ancienne étant conservée avec le suffixe .dpkg-old.
--force-confdef: comportement standard de dpkg, à savoir décider seul si possible et demander à l’utilisateur sinon. Utile principalement en combinaison avec l’option --force-confold.
--force-confmiss: avec cette option, dpkg installera le fichier de configuration s’il n’est pas présent sur le système (par exemple parce que vous l’avez supprimé par erreur).

Ces options peuvent être passées à dpkg lors de l’utilisation d’Apt, grâce à une syntaxe similaire à celle ci-dessous :

$ apt-get -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" dist-upgrade

Ce comportement peut être retenu de manière permanente via la création du fichier /etc/apt/apt.conf.d/local :

Dpkg::Options {
   "--force-confdef";
   "--force-confold";
}

Laisser le choix à l’utilisateur systématiquement

Dpkg ne demandera l’avis de l’utilisateur que dans le cas où le paquet contient une nouvelle version du fichier de configuration. Réinstaller la même version du paquet n’entraînera par conséquent aucune demande, à moins de passer l’option --force-confask. Cette option, apparue dans Squeeze, ne demandera le choix de l’utilisateur que dans le cas de fichiers modifiés localement.

Cet article est une traduction de Everything you need to know about conffiles: configuration files managed by dpkg contribuée par Weierstrass01. Ne manquez pas une occasion de parfaire vos connaissances de Debian ou Ubuntu, abonnez-vous à ma newsletter en cliquant ici.

Dans la/les catégorie(s): Documentation, Documentation pour les utilisateurs Etiqueté avec: administration, conffile, Debian, dpkg, Libre, Référence, Ubuntu

Changements sur dpkg

15/10/2007 Par Raphaël Hertzog

Malgré ma bonne volonté, je n’arrive pas à maintenir un rythme très régulier pour animer mon blog. Il faut dire que rédiger un bon article (c’est-à-dire avec du contenu intéressant, et avec une relecture pour éliminer la majorité des fautes d’orthographe et de grammaire) cela prend beaucoup de temps, et que le temps je n’en ai pas beaucoup à revendre.

En effet, depuis quelques temps je me suis mis à contribuer à dpkg. J’ai commencé avec un projet plutôt important, à savoir l’amélioration de dpkg-shlibdeps pour qu’il génère des dépendances minimales en fonction des symboles des bibliothèques utilisés par chaque programme. Tout au long, j’ai maintenu à jour une page du wiki avec les détails et l’avancement:
http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps.
Comme le développement était assez important, il a eu lieu sur une branche dédiée qui vient juste d’être intégrée dans la branche master (autrement dit, le résultat sera dans la prochaine version de dpkg, c’est-à-dire la version 1.14.8).

Ce projet représente à mon avis une avancée très importante car si les bibliothèques les plus importantes emploient ce mécanisme rapidement, la majorité des paquets auront des dépendances moins strictes et il sera beaucoup plus souvent possible d’installer un paquet de unstable dans stable sans avoir besoin de le recompiler. Autrement dit, il y aura moins de rétro-portages (« backports ») à compiler et il sera plus facile d’installer la dernière version d’une application donnée.

Ce premier projet étant terminé, je me suis attaqué à un plus petit problème mais qui est intéressant tout de même. Jusqu’à présent, dpkg-gencontrol se contentait de substituer les variables dans les dépendances et d’écrire le résultat bêtement dans le champ correspondant.
Parfois le jeu des substitutions introduit des dépendances en double (parfois plus ou moins stricte). Comme lintian se plaint de ces problèmes, cela a conduit de nombreux mainteneurs à supprimer les variables et à mettre en dur les dépendances souhaitées. Maintenant, cela n’est plus nécessaire. En outre, les dépendances sont optimisées de telle sorte que si une dépendance dans le champ Pre-Depends implique une dépendance du champ Depends, cette dernière est supprimée (il en va de même pour les dépendances plus faibles listées dans Recommends puis Suggests). Je viens de soumettre une série de patchs pour inclure toutes ces fonctionnalités.

Je ne sais pas encore quel sera mon prochain projet, mais les récentes discussions sur un nouveau format de paquet source m’interpellent et peut-être vais-je essayer d’implémenter quelque chose qui combine le support du format wig&pen et les avancées apportées par les VCS distribués.

Ces différents développements concernent le paquet dpkg-dev qui contient essentiellement du perl. Ceux qui ne maîtrisent pas le C et qui n’osaient pas s’approcher de dpkg à cause de cela peuvent retourner leur veste et nous rejoindre sur #debian-dpkg sur irc.debian.org et la liste de diffusion debian-dpkg.
Enfin, http://wiki.debian.org/Teams/Dpkg contient des informations intéressantes pour qui veut débuter sur ce projet.

Dans la/les catégorie(s): Général Etiqueté avec: Debian, dpkg