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 Documentation Documentation pour les utilisateurs

5 raisons qui font qu’un paquet Debian est plus qu’une simple archive de fichiers

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

Folder with gearsLes paquets Debian font certainement partie de votre quotidien… mais savez-vous seulement ce qu’ils sont exactement ? De simples archives ? Sûrement plus que ça, sinon de « simples » archives TAR (vous savez, les fameux fichiers finissant par .tar.gz) feraient l’affaire. Cet article vous propose de plonger au cœur de leurs structures… suivez le guide !

1. Un paquet Debian ? Deux archives TAR dans une archive AR !

Un fichier .deb est, en premier lieu, une archive au format AR. Archive que vous pouvez manipuler à l’aide de la commande ar. Cette archive contient 3 fichiers, comme vous pouvez le constater par vous-même en téléchargeant n’importe quel .deb, et en lui passant la commande « ar t » :

$ ar t gwibber_2.31.91-1_all.deb
debian-binary
control.tar.gz
data.tar.gz

Le fichier debian-binary est un fichier texte indiquant la version du format du .deb, la version actuelle étant la 2.0.

$ ar p gwibber_2.31.91-1_all.deb debian-binary
2.0

Le fichier data.tar.gz contient quant à lui les fichiers « utiles » du paquets, i.e. tous les fichiers décompressés lorsque vous exécutez dpkg --unpack.

Jusque-là…rien d’extraordinaire. Ce qui fait qu’un .deb est plus qu’une archive est contenu dans le dernier fichier : control.tar.gz. Il contient des métainformations utilisées par le gestionnaire de paquets. Par exemple :

$ ar p gwibber_2.31.91-1_all.deb control.tar.gz | tar tzf -
./
./postinst
./prerm
./preinst
./postrm
./conffiles
./md5sums
./control

2. Des méta-informations concernant le paquet et ses relations…

Le fichier control contenu dans l’archive control.tar.gz est le plus important de tous : il contient des informations basiques sur le paquet telles que son nom, sa version, sa description, les architectures supportées, son mainteneur, etc. Il contient également tout le jeu de dépendances nécessaires au paquet, grâce auquel le gestionnaire de paquets peut s’assurer de la cohérence de l’écosystème avant l’installation du paquet. La page dédiée aux Binary control files vous en dira plus quant à l’utilisation de tous ces attributs.

Ces informations sont copiées dans le fichier /var/lib/dpkg/status après que le paquet a été installé.

3. …et des scripts pour que tout fonctionne dès l’installation

Aux différentes étapes de la vie d’un paquet — installation, mise à jour, suppression… — dpkg exécute les scripts du mainteneur, embarqués dans le paquet :

  • postinst : après l’installation
  • preinst : avant l’installation
  • postrm : après la suppression
  • prerm : avant la suppression

Il s’agit là d’une description largement simplifiée. Plus exactement, ces scripts sont exécutés en de nombreuses autres occasions, avec des paramètres d’appel différents. Un chapitre entier de la Charte Technique Debian est dédié à ce sujet. Cette page du wiki Debian pourrait vous paraître plus digeste pour une première approche.

Bien qu’effrayante de prime abord, il s’agit là d’une fonctionnalité très importante, indispensable à la bonne gestion des mises à jour non réversibles, à la création d’utilisateurs système, pour la configuration automatique, etc.

4. Les fichiers de configuration sont… spéciaux

Décompresser une archive entraîne la suppression des versions précédentes des fichiers, ce qui constitue le comportement désiré lorsqu’un paquet est mis à jour… sauf pour les fichiers de configuration : il vaut mieux ne pas écraser vos modifications, non ?

C’est dans cette optique que les paquets listent les fichiers de configuration dans le fichier conffiles fourni par control.tar.gz. De cette manière, dpkg les traitera différemment.

5. Vous pouvez toujours ajouter de nouvelles méta-informations

Et il existe déjà des outils qui exploitent la possibilité d’ajouter des fichiers supplémentaires dans control.tar.gz :

  • debsums utilise le fichier md5sums pour s’assurer qu’aucun fichier n’a été modifié par accident
  • dpkg-shlibdeps utilise les fichiers shlibs et symbols pour générer les dépendances à une bibliothèque
  • debconf utilise les scripts config pour obtenir des informations de configuration de la part de l’utilisateur

Une fois installés, ces fichiers sont conservés par dpkg dans /var/lib/dpkg/info/package.* à côté des scripts du mainteneur du paquet.

Cet article est une traduction de 5 reasons why a Debian package is more than a simple file archive 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 utilisateurs Tagged With: ar, conffile, control, deb, Debian, Libre, maintainer scripts, Référence, Ubuntu

Le processus de publication de Debian expliqué

Posted on 11/03/2011 Written by Raphaël Hertzog

À l’heure actuelle, le seul et unique but du projet Debian est la parution de sa version stable[1]. Celle-ci intervient généralement tous les 18 à 24 mois, par le biais d’un processus dont cet article va tenter de brosser une vue générale.

Créer une nouvelle distribution

La publication de la nouvelle version stable est immédiatement suivie de la création d’une nouvelle distribution dans l’archive Debian, peuplée précisément par la version fraîchement publiée. Le choix de son nom de baptême revient aux Release Managers et il est de tradition qu’il soit choisi parmi l’un des noms de personnages du film d’animation Toy Story.

Dans le cas qui nous occupe actuellement, Wheezy vient d’être créée, maintenant que Squeeze (ou Debian 6.0) vient d’être publiée.

La distribution utilisée pour préparer la prochaine version stable est par contre toujours nommée testing, dans un souci de simplicité. Dans l’archive Debian, testing n’est qu’un lien symbolique pointant vers le répertoire approprié (wheezy, depuis peu).

Mises à jour des paquets, implémentation des objectifs

Les développeurs sont occupés, pendant la majeure partie du cycle de publication, par l’empaquetage des nouvelles versions amont, ainsi que par l’implémentation des « objectifs de publication » (release goals). L’envoi des paquets se fait d’abord dans l’archive unstable.

De là les paquets migrent vers testing une fois quelques tests de qualité passés : ils ne doivent pas être entachés de bogues critiques pour la publication, être disponibles pour toutes les architectures déjà supportées, ne briser aucune dépendance dans testing et enfin avoir au moins passé 10 jours dans unstable.

Cette période minimale permet d’assurer que le paquet a été testé et que ceux qui ont procédé aux tests ont eu suffisamment de temps pour rapporter les bogues éventuels. Si jamais l’un d’entre eux est critique pour la publication, le paquet est bloqué pour la migration vers testing.

La principale activité de la Release Team consiste pendant cette phase à s’assurer que les mises à jour des paquets migrent de unstable vers testing. Tâche pouvant se révéler ardue : les dépendances entre paquets « lient » souvent ces derniers ensemble, de sorte qu’ils ne puissent migrer vers testing qu’en même temps. Si un seul des paquets n’est pas prêt (par exemple parce que la nouvelle version de l’un d’entre eux n’a pas encore passé les 10 jours réglementaires dans unstable), c’est la migration de tous les paquets liés qui est bloquée.

Stabilisation, finition et correction des bogues critiques pour la publication

L’afflux constant de nouveaux paquets rend difficile la publication d’une version bien « léchée ». C’est la raison pour laquelle, atteint un certain point, les Release Managers gèlent testing : les mises à jour automatiques sont interrompues et chaque mise à jour de chaque paquet est soumise à validation. La sélection est impitoyable, seules sont autorisées les mises à jour corrigeant les bogues critiques pour la publication, ou ceux apportant à la fois une importante plus-value à l’expérience utilisateur (nouvelles traductions, documentation mise à jour, …) tout en présentant de faibles risques d’entraîner des régressions.

Certains paquets sont même retirés durant cette période de gel, si leurs versions actuelles ne seront pas supportées pour toute la durée de vie de la version stable de Debian.

La période de gel tend à ralentir considérablement les changements dans unstable. La plupart des mainteneurs de paquets optent en effet pour l’envoi des nouvelles versions dans experimental, de telle sorte qu’ils puissent toujours mettre à jour leurs paquets dans testing via unstable. Il s’agit là du processus recommandé par les Release Managers, dans la mesure où les mises à jour qu’ils autorisent ont été testées de la manière usuelle. Ce qui n’est pas le cas si elles sont directement envoyées dans testing (via testing-proposed-updates).

Cette caractéristique se révèle plutôt ennuyeuse pour les utilisateurs voulant rester à l’avant-garde en terme de versions de paquets, et qui utilisent testing ou unstable dans cette optique, celle d’une distribution en évolution perpétuelle (rolling release).

Publication

Dès que les Release Managers sont satisfaits de la qualité de la nouvelle distribution, les dernières opérations préalables à la publication sont lancées, telles que la génération des images CD. Dans l’archive Debian, la publication est officialisée par la redirection du lien symbolique de la version stable vers la nouvelle distribution – et celui de la version oldstable vers la désormais ancienne distribution.

Champagne ! Cette boucle est bouclée, une nouvelle peut commencer ! 🙂

[1] Le projet « Testing Constamment Utilisable » vise à faire de testing une distribution officiellement supportée, tout comme la version stable, mais avec une politique de mise à jour très différente.

Cet article est une traduction de Understanding Debian’s release process 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: Documentation, Documentation pour les utilisateurs Tagged With: Debian, experimental, Introduction, oldstable, Publication, Référence, Release, stable, Testing, unstable

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

Posted on 13/12/2010 Written by 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.

Filed Under: Documentation, Documentation pour les utilisateurs Tagged With: administration, conffile, Debian, dpkg, Libre, Référence, Ubuntu

  • « Previous Page
  • 1
  • 2
  • 3
  • 4

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