Documentation

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

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

Dans la/les catégorie(s): Documentation, Documentation pour les contributeurs Etiqueté avec: 3.0 (quilt), Debian, Dérivés, HOWTO, Libre, Packaging, Patch, Ubuntu

Correctement renommer un fichier de configuration dans un paquet Debian

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

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

5 raisons pour lesquelles Debian unstable ne mérite pas son nom

19/07/2011 Par Raphaël Hertzog

Debian unstable (également connue sous le nom de sid) est l’une des 3 distributions proposées par Debian (les deux autres étant stable et testing).

Elle n’est pas conçue comme un produit pour les utilisateurs finaux, son rôle essentiel est de servir de dépôt pour les toutes dernières versions de paquets envoyés par les contributeurs, et ce quotidiennement. unstable est donc perpétuellement en évolution rapide, et par conséquent pas nécessairement appropriée pour tout public. Ceci étant, il est possible de l’utiliser sans que votre ordinateur n’explose !

1. unstable contient principalement des versions stables de logiciels

Oui oui, vous avez bien lu. unstable ne contient pas tout plein de versions de développement bien que, ponctuellement pour certains logiciels, ce soit le cas. Il s’agit la plupart du temps d’une décision réfléchie de la part du mainteneur de paquets, considérant qu’en l’état cette version particulière est déjà supérieure à l’ancienne.

Ceci s’explique par le fait que sid est l’antichambre de testing, dépôt où la prochaine version stable est préparée. Les mainteneurs ne doivent donc y envoyer que des paquets d’une qualité suffisante en vue de la publication, le reste devant prendre le chemin de experimental.

2. Elle ne crashe pas tous les jours

Des dysfonctionnements surviennent, mais ne sont en règle générale ni sérieux, ni difficiles à corriger. Voilà un bout de temps maintenant qu’il ne m’est pas arrivé, après une mise à jour, de ne plus pouvoir redémarrer mon ordinateur, ou que l’interface graphique soit non fonctionnelle. La plupart du temps, les dysfonctionnements rencontrés prennent la forme d’un logiciel cessant de fonctionner ou souffrant d’un bogue nouveau, ou bien que certains paquets ne puissent plus être installés.

Vous pouvez vous en sortir, dans la grande majorité des cas, en installant la version du paquet incriminé présente dans testing, ou en trouvant dans le suivi des bogues un moyen de contourner le problème. Il est également possible de prévenir plutôt que de guérir : apt-listbugs, en vous prévenant du problème, peut vous dissuader de mettre à jour.

3. Elle est à la base d’autres distributions

Si Debian unstable était de si piètre qualité, elle ne servirait pas de base de départ pour des distributions dérivées. Logique, non ? Deux exemples basées sur sid parmi d’autres : Ubuntu et ~~Sidux~~ Aptosid.

4. Sa conception ne la rend pas moins sécurisée que stable ou testing

Les vulnérabilités importantes sont généralement rapidement corrigées dans stable et unstable. L’équipe chargée de la sécurité s’occupe de stable, tandis que la correction d’unstable revient aux mainteneurs des paquets concernés. testing récupère généralement la correction à travers la mise à jour des paquets provenant d’unstable, entraînant ainsi une latence à l’obtention des corrections.

Les problèmes de sécurités d’importance moindre peuvent n’entraîner aucune correction dans stable. Dans ce cas, les utilisateurs de testing/unstable sont mieux servis, dans la mesure où ils récupèreront la correction avec la nouvelle version du paquet, quoi qu’il arrive.

Bien évidemment, il peut arriver que les mainteneurs soient particulièrement occupés ou que certaines failles arrivent quand même à se faufiler. Si le mainteneur ne réagit pas, d’autres personnes examinant les bogues RC (Release Critical) proposeront les corrections nécessaires.

5. Je l’utilise sur mon ordinateur principal

Et je ne suis pas le seul ! Vous pouvez le faire également si vous remplissez les conditions suivantes :

vous savez utiliser la ligne de commande (du moins suffisamment pour rétrograder de version un paquet, éditer des fichiers de configuration, …) ;
vous connaissez le fonctionnement d’APT et l’utilisation simultanée de plusieurs dépôts dans /etc/apt/sources.list ;
l’anglais lu/écrit n’est pas un problème, de telle sorte que vous pouvez lire/écrire les rapports de bogue, le cas échéant ;
vous disposez d’un autre ordinateur relié à Internet, d’où vous pouvez rechercher de la documentation (ou le système de suivi des bogues, ou les listes de diffusion dédiées au support) lorsque votre ordinateur principal est hors service pour une raison qui vous échappe.

Si vous ne vous sentez pas prêt à faire le grand saut, vous pouvez vous abonner à ce blog (ou vous abonner au flux RSS), dans la mesure où je posterai certainement d’autres articles permettant d’acquérir les compétences nécessaires pour y arriver.

PS: Sans renier ce qui précède, si vous avez une installation fonctionnelle de sid, n’allez pas jusqu’à la mettre à jour juste avant une importante présentation, ou un voyage : le crash a toujours lieu au pire moment. À moins que vous ne vous sentiez l’âme d’un aventurier, bien sûr !

Cet article est une traduction de 5 reasons why Debian Unstable does not deserve its name contribuée par Weierstrass01. Suivez moi sur Identi.ca, Twitter et Facebook.

Dans la/les catégorie(s): Documentation, Documentation pour les utilisateurs Etiqueté avec: Debian, Libre, Release, sid, stable, Testing, Ubuntu, unstable

Comment recompiler un paquet Debian

12/07/2011 Par Raphaël Hertzog

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

1. Télécharger les sources

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

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

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

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

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

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

2. Installer les dépendances de compilation

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

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

3. Faites les modifications requises

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

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

4. Compiler le paquet

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

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

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

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

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

Dans la/les catégorie(s): Documentation, Documentation pour les utilisateurs Etiqueté avec: APT, apt-get, dch, Debian, devscripts, dget, dpkg-checkbuilddeps, dpkg-source, HOWTO, Libre, Packaging, Recompilation, Ubuntu

Comment Ubuntu s’appuie sur Debian pour son développement

22/06/2011 Par Raphaël Hertzog

Dans quelle mesure Ubuntu est-elle liée à Debian ? De quelle façon les paquets « migrent »-ils de l’un vers l’autre ? Cet article est une ébauche de réponse à ces questions qui m’ont été posées.

D’où viennent les paquets ?

La plupart des paquets ont été créés par des contributeurs Debian, et uploadés dans dans Debian unstable (ou experimental). Les nouveaux paquets sont passés en revue par les ftpmasters Debian pour acceptation dans l’archive officielle. Le temps de l’audit, ces paquets sont conservés dans une file d’attente dédiée, pour une durée allant de quelques heures à quelques mois (une à deux semaines généralement).

Ubuntu importe tous les paquets Debian officiels, auxquels s’ajoutent leurs propres paquets. Environ 7% de la base de paquets Ubuntu correspondent à des applications tierces empaquetées pour Ubuntu et non pour Debian.

Quelles sont les modifications faites par Ubuntu ?

De tous les paquets en provenance de Debian, 17% incluent des modifications supplémentaires faites par Ubuntu. La plupart des paquets concernés appartiennent au dépôt main, qui est activement maintenu par Canonical et les core developers d’Ubuntu. Le dépôt universe est quant à lui beaucoup plus fidèle aux paquets Debian d’origine.

La plupart des modifications faites par Ubuntu sont motivées par les décisions prises lors du Ubuntu Developer Summit. Celles-ci tendent vers des objectifs bien précis : meilleure interface utilisateur, temps de démarrage plus rapide, meilleure accessibilité en tant que plateforme pour les applications tierces, intégration avec leurs propres services en ligne (Launchpad, Ubuntu One), etc. Les autres modifications sont le fruit des corrections de bogues soumis par les utilisateurs d’Ubuntu.

Il est à noter que même les paquets binaires Ubuntu n’ayant pas subi de modifications au niveau de leurs sources diffèrent de la version binaire Debian. Il s’agit là d’une conséquence du changement d’environnement de compilation réalisé par Ubuntu : ils ne supportent que les processeurs type x86 de classe supérieure ou égale à 686, activent des options de compilation que Debian n’activent pas, … Tous les paquets binaires sont de plus modifiés par un programme appelé pkgbinarymangler.

Cycle de publication d’Ubuntu et lien avec Debian

Ubuntu publie une nouvelle version tous les 6 mois (sur le concept des publications à date fixe). Le rapport au temps étant radicalement différent chez Debian, comment Ubuntu parvient-elle à réutiliser le travail de Debian ?

Réponse : en important les paquets de Debian unstable (parfois même d’experimental), ce qui assure la « fraîcheur » des paquets. Si la version Ubuntu du paquet contient déjà des modifications spécifiques à la distribution, elles sont simplement fusionnées dans le paquet Debian nouvellement copié. Dans le cas contraire, le paquet Debian est juste importé, puis recompilé pour Ubuntu… ce qui fonctionne plutôt bien, Debian unstable l’étant beaucoup moins que son nom le laisse supposer.

Cet import automatique ne dure que les deux premiers mois du cycle, jusqu’au gel de l’import Debian. Il reste donc pas mal de temps après coup pour corriger le plus gros des problèmes.

Durant les troisième et quatrième mois, l’import de paquets est toujours possible, mais non automatique : il doit être explicitement demandé par un développeur. A la fin du quatrième mois, le gel des fonctionnalités est décrété, mettant définitivement fin à la période d’import.

Les deux mois restants sont dédiés aux corrections de bogues, ainsi qu’aux finitions de détail. De nombreux gels mineurs interviennent durant cette période, le planning de publication de Natty en donne un exemple. L’import de paquets Debian est maintenant exceptionnel, et autorisé uniquement s’il s’agit de mises à jour correctives côté Debian.

Crédits : certains chiffres sont repris d’une conférence de Lucas Nussbaum, basés sur les paquets disponibles pour la version Lucid Lynx d’Ubuntu.

Cet article est une traduction de How Ubuntu builds up on Debian 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: Debian, experimental, gel, Introduction, Libre, Release, Ubuntu, unstable

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

É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

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

06/04/2011 Par Raphaël Hertzog

Folder with gears Les 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.

Dans la/les catégorie(s): Documentation, Documentation pour les utilisateurs Etiqueté avec: ar, conffile, control, deb, Debian, Libre, maintainer scripts, Référence, Ubuntu

Comment générer des dépendances différentes pour Debian et Ubuntu avec un paquet source commun

16/03/2011 Par Raphaël Hertzog

Il arrive que les dépendances requises par certains paquets diffèrent entre Debian et Ubuntu. Il reste néanmoins possible de garder un seul paquet source, capable de générer plusieurs variantes distinctes. Cet article décrit comment faire, pas-à-pas.

1. Quand est-ce nécessaire ?

Bien qu’il soit possible d’avoir des dépendances différentes en fonction de la distribution pour laquelle le paquet est construit, cela doit autant que possible être évité, et ne constituer que la dernière option possible, comme par exemple lorsque :

Ubuntu dispose de paquets que Debian ne propose pas (et réciproquement), alors que le paquet qui nous occupe profiterait de leurs installations.
Le nom du paquet diffère entre les deux distributions (et ce de manière volontaire, non en raison d’un défaut de synchronisation entre Ubuntu et Debian)
Les paquets sont construits différemment dans les deux distributions, ce qui entraîne une différence de dépendances d’exécution. Certains patches ne peuvent être appliqués qu’à Ubuntu.

2. Variables de substitution dans debian/control

Les dépendances variant entre les distributions ne peuvent pas être écrites « en dur » dans debian/control. Il est par contre possible d’utiliser une variable de substitution (substvar) qui sera remplacée par dpkg-gencontrol au moment de la compilation. Elle peut par exemple être notée ${dist:Depends} :

[...]
Depends: bzip2, ${shlibs:Depends}, ${misc:Depends}, ${dist:Depends}
[...]

A noter qu’il est fort probable que vous ayez déjà d’autres variables de substitution telles que ${shlibs:Depends} pour dpkg-shlibdeps, ou ${misc:Depends} pour debhelper et ses scripts dh_*.

3. dpkg-gencontrol et option -V

Les valeurs de dépendance remplacées par cette nouvelle variable doivent être communiquées à dpkg-gencontrol, via l’option -V. Exemple :

dpkg-gencontrol [...] -Vdist:Depends="paquet-A (>= 2), paquet-B"

Si vous utilisez debhelper, l’option doit être passée à dh_gencontrol après deux tirets (--) :

dh_gencontrol -- -Vdist:Depends="paquet-A (>= 2), paquet-B"

Si vous utilisez CDBS, vous pouvez passer à la variable DEB_DH_GENCONTROL_ARGS_ALL la valeur souhaitée :

include /usr/share/cdbs/1/rules/debhelper.mk
DEB_DH_GENCONTROL_ARGS_ALL = -- -Vdist:Depends="paquet-A (>= 2), paquet-B"

Les valeurs passées à dpkg-gencontrol sont, dans tous les exemples précédents, statiques. Voyons maintenant comment les rendre dépendantes de la distribution visée.

4. Utiliser dpkg-vendor dans debian/rules

dpkg-vendor est un petit outil (fourni avec le paquet dpkg-dev) permettant d’interpréter le fichier /etc/dpkg/origins/default (fourni quant à lui par le paquet base-files) pour connaître la distribution actuelle ainsi que ses prédécesseurs. Il peut être utilisé dans debian/rules pour adapter le comportement en fonction de la distribution utilisée. La page de man explicite les nombreuses options supportées, nous allons quant à nous n’en utiliser qu’une ici : --derives-from <vendor>. Cette option entraîne le renvoi d’un code retour à la fin du script, égal à 0 si la distribution utilisée est — ou dérive de — celle indiquée, et vaut 1 sinon.

Si l’on assemble maintenant toutes les pièces du puzzle entre elles, on peut donc utiliser dpkg-vendor pour définir dynamiquement la valeur de la variable de substitution dans debian/rules. Supposons par exemple que votre paquet doit dépendre de « paquet-A (>= 2) » sur Ubuntu (et ses dérivés), de « paquet-B » sinon. En utilisant le fichier de règles de debhelper 7, cela donne :

ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
	SUBSTVARS = -Vdist:Depends="paquet-A (>= 2)"
else
	SUBSTVARS = -Vdist:Depends="paquet-B"
endif

%:
	dh $@

override_dh_gencontrol:
	dh_gencontrol -- $(SUBSTVARS)

Si vous utilisez CDBS, cela donnerait :

include /usr/share/cdbs/1/rules/debhelper.mk
ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
	DEB_DH_GENCONTROL_ARGS_ALL = -- -Vdist:Depends="paquet-A (>= 2)"
else
	DEB_DH_GENCONTROL_ARGS_ALL = -- -Vdist:Depends="paquet-B"
endif

Cet article est une traduction de How to generate different dependencies on Debian and Ubuntu with a common source package contribuée par Weierstrass01. Suivez moi sur Identi.ca, Twitter et Facebook. Ou abonnez-vous à ce blog par RSS ou par email.

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

Le processus de publication de Debian expliqué

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

Dans la/les catégorie(s): Documentation, Documentation pour les utilisateurs Etiqueté avec: Debian, experimental, Introduction, oldstable, Publication, Référence, Release, stable, Testing, unstable