Destination Debian

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

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

Comment créer des paquets Debian avec une méthode de compression alternative

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

Alors que gzip vient immédiatement à l’esprit quand il s’agit de compression de fichiers, d’autres outils existent et permettent même d’atteindre un meilleur ratio de compression que celui-ci. Cet article explique comment tirer parti de ces alternatives dans votre travail d’empaquetage Debian.

Dans le paquet source

Un paquet source se compose de plusieurs fichiers. Le fichier .dsc n’est jamais compressé, ce qui ne pose aucun problème puisqu’il s’agit d’un petit fichier texte. Outre via gzip (orig.tar.gz), les archives TAR amont peuvent être compressés grâce à bzip2 (orig.tar.bz2), lzma (orig.tar.lzma) ou xz (orig.tar.xz). À vous de choisir si l’archive amont est proposée sous différents formats de compression. Placez-le au bon endroit et dpkg-source l’utilisera automatiquement. Il est à noter toutefois que dans le cas du format source 1.0 seul gzip est utilisable, tandis que l’archive principale Debian n’autorise actuellement que gzip et bzip2 (xz suivra éventuellement plus tard), même si le format source « 3.0 (quilt) » les supporte tous.

Les fichiers d’empaquetage Debian sont fournis soit sous forme de fichier .diff.gz pour le format source 1.0 (seul gzip est supporté ici aussi), soit sous forme de fichier .debian.tar pour le format source « 3.0 (quilt) ». Cette dernière archive pouvant être compressée via l’outil de votre choix, il suffit de le spécifier à dpkg-source (cf. ci-dessous. À noter que la valeur par défaut correspond à l’utilisation de gzip).

Dpkg-source doit générer l’archive principale dans le cas d’un paquet natif et il est possible de lui faire utiliser autre chose que gzip, grâce à l’option --compression. Cette option est usuellement placée dans le fichier debian/source/options:

# Utilisation de bzip2 au lieu de gzip
compression = "bzip2"
compression-level = 9

Cette option n’est généralement pas très utile dans le cas des paquets sources au format « 3.0 (quilt) », dans la mesure où l’archive Debian compressée n’est pas d’une taille importante. Ceci étant, certains mainteneurs préfèrent utiliser le même outil de compression pour l’archive amont et l’archive Debian. Vous êtes donc libre d’utiliser cette option dans un souci d’harmonisation.

C’est par contre bien plus intéressant dans le cas des paquets natifs : pour exemple la taille du paquet source dpkg a été réduite de 30% en passant à bzip2, sauvant ainsi 2Mo d’espace disque.

Dans les paquets binaires

Les fichiers .deb contiennent également des archives compressées au format tar, et utilisent également gzip par défaut :

$ ar t dpkg_1.15.8.9_i386.deb 
debian-binary
control.tar.gz
data.tar.gz

L’archive data.tar.gz contient tous les fichiers à installer, et c’est précisément celle que vous pouvez compresser via un outil alternatif à gzip. Rappelons que ce n’est vraiment intéressant que dans le cas des — très — gros paquets, dont la taille justifie l’écart par rapport au processus standard de compression. Essayez et regardez un peu combien de Mo vous parvenez à sauver ! Le fait que ces alternatives puissent nécessiter une quantité importante de mémoire (que ce soit pour la compression ou la décompression) ne doit pas être négligé : dans le cas de plate-formes embarquées ou de matériels d’entrée de gamme disposant de peu de mémoire, il peut être intéressant de conserver gzip.

Ceci étant dit, quelle est donc la manière de procéder ? Rien de plus facile, dpkg-deb met à disposition l’option -Z, à laquelle il suffit de passer « -Zbzip2 » par exemple. Il est également possible de passer « -z6 » pour changer le ratio de compression à 6 (ce qui peut être utile car un niveau de compression inférieur peut entraîner une empreinte mémoire plus faible, selon le programme utilisé). L’invocation de dpkg-deb étant habituellement masquée derrière l’appel à dh_builddeb dans le fichier /debian/rules, il faut modifier ce dernier avec « dh_builddeb -- -Zbzip2 ».

Si vous utilisez les fichiers de règles de debhelper 7, il vous faudra neutraliser le comportement standard via par exemple l’ajout de :

%:
	dh $@

override_dh_builddeb:
	dh_builddeb -- -Zbzip2

Si vous utilisez CDBS, la variable d’environnement DEB_DH_BUILDDEB_ARGS doit être initialisée à :

include /usr/share/cdbs/1/rules/debhelper.mk
[...]
DEB_DH_BUILDDEB_ARGS = -- -Zbzip2

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

Filed Under: Documentation, Documentation pour les contributeurs Tagged With: CDBS, debhelper, Debian, dpkg-deb, dpkg-source, HOWTO, Libre, Packaging, Ubuntu

Comprendre les processus d’adhésion aux projets Debian et Ubuntu

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

Les contributeurs réguliers de Debian ou d’Ubuntu peuvent se voir charger d’un rôle officiel au sein de la communauté, parmi un ensemble bien défini. À ces rôles sont assortis des droits permettant aux contributeurs d’accomplir leurs tâches ainsi que de prendre part à la gouvernance du projet (élections, prise de décisions, …). Ces rôles sont également le moyen, pour les distributions, de reconnaître le travail accompli, de telle sorte que la plupart des contributeurs sont fiers du statut qu’ils atteignent.

Le processus d’adhésion joue un rôle important dans le développement d’une distribution : par la nature des contributeurs conviés au projet, ce qu’elle attend de ces derniers ainsi que leurs droits en son sein. Elle façonne en dernier ressort la capacité du projet à recruter de nouveaux contributeurs et à garder le projet en bonne santé. Cet article décrit les statuts Debian et Ubuntu existants, et le jargon — parfois déroutant — associé.

Le cas Debian

Debian n’a que deux rôles de membres officiels : les Développeurs Debian (DD) et les Mainteneurs Debian (DM – Debian Maintainers). Leurs prérogatives sont définies dans la Constitution Debian, tandis que celles des mainteneurs sont définies dans la résolution générale de 2007. Ceci étant, le statut de mainteneur est principalement documenté dans la page wiki correspondante. L’intégration de ce nouveau statut dans le circuit officiel Debian a été assez lente, en large partie du au manque de concertation – à l’époque – avec les différentes parties impliquées. L’obtention de ce statut avant toute candidature à un poste de développeur est actuellement encouragé.

Être Mainteneur Debian ne confère que peu de droits : ils ne peuvent qu’uploader des paquets leurs faisant déjà expressément référence (que ce soit dans les champs « Mainteneur » ou « Uploader« ), et pourvu de l’attribut spécifique DM-Upload-Allowed positionné à « oui ». Ce dernier n’étant modifiable que par les Développeurs Debian. Les mainteneurs n’ont aucun autre droit, et uniquement un accès limité aux ressources Debian.

Au-delà de ces deux rôles officiels existe aussi une classe de mainteneurs n’étant mentionnés officiellement qu’à travers le champ « Mainteneur » du paquet. Ils assurent la maintenance du paquet mais tous les uploads sont réalisés par les Développeurs Debian, après vérification du travail effectué (ce « parrainage » – sponsorship – étant le passage obligé pour gravir les échelons officiels du processus d’empaquetage). Une fois que le mainteneur a gagné la confiance du Développeur Debian, ce dernier va lui demander de faire acte de candidature au poste de Mainteneur Debian, afin d’être affranchi du « parrainage ».

Il existe au final pas moins de trois différents types de mainteneurs de paquets, ce qui entraîne une belle confusion quand il s’agit de discuter des questions structurelles… d’autant plus lorsque le Processus du nouveau Mainteneur décrit les règles à suivre pour devenir un Développeur Debian. Attention donc aux « facéties » lexicales lorsque vous parcourez la documentation Debian !

Le cas Ubuntu

Ubuntu a depuis le début défini le statut de Membre Ubuntu, incluant tous les types de contributeurs : les développeurs bien sûr, mais aussi les rédacteurs de la documentation, artistes, traducteurs, etc. Ce statut donne notamment la possibilité de voter lors des élections du Conseil de la Communauté, le droit de participer au Planet Ubuntu ainsi que l’alias email @ubuntu.com.

La situation est plus compliquée pour les développeurs : la page wiki dédiée liste pas moins de cinq statuts différents. Les développeurs étaient initialement séparés entre Ubuntu Core Developers et MOTU (Masters of the Univers). Ces derniers étant responsables des sections d’archives universe/multiverse, tandis que les premiers avaient également les droits d’uploads pour les sections main/restricted. Mais, en but à de réels problèmes de gestion des archives, et inspirés par le concept de Mainteneur Debian, l’organisation changea pour permettre un contrôle plus précis des uploads de paquets.

Le droit d’upload peut maintenant être accordé au niveau du paquet, mais Ubuntu peut aussi déléguer la capacité d’autoriser l’upload, toujours paquet par paquet. Cela conduisit au nouveau statut d’Uploader propre au paquet (Per-Package Uploader), qui se résume à un Membre Ubuntu disposant de droits d’uploads sur un nombre restreint de paquets sur lesquels il possède une expertise. Le statut plus générique de Développeur Ubuntu inclut maintenant les membres de diverses équipes de développement (actuellement Ubuntu Desktop, Mythubuntu, Kubuntu et Edubuntu), auxquels ont été délégués, sur un vaste ensemble de paquets, la capacité à gérer les droits d’upload. Ces équipes peuvent définir leur propre politique d’ajout de nouveaux membres, du moment qu’elles suivent les règles basiques définies par le Conseil des Développeurs – Developer Membership Board. (voir à ce propos cette page wiki.)

Le statut de « Développeur Ubuntu impliqué » – Ubuntu Contributing Developer est un statut intermédiaire, dédié aux personnes qui ne sont pas encore prêtes pour les autres statuts de développeurs, mais qui ont fait preuve de suffisamment d’engagement pour devenir des Membres Ubuntu.

La procédure pour accéder à chacun de ces statuts est la même : préparer une page de wiki listant vos contributions, recueillir les témoignages de personnes déjà Membres avec lesquelles vous avez travaillé, vous ajouter à l’agenda de la prochaine session du comité qui accorde le statut recherché, et attendre ladite réunion. Les membres du comité décideront si vous êtes prêts (ou non) pour le statut d’après ce que vous aurez déclaré sur la page wiki, vos réponses lors du comité, sur une mailing-list dédiée aux développeurs, ainsi que quoi que ce soit que vous auriez à dire vous concernant.

Les comités les plus importants sont généralement élus par la communauté, tandis que les autres sont désignés par le Conseil de la Communauté. Ces instances gouvernantes comprennent des employés de Canonical, bien qu’en nombre inférieur à ce que l’on pourrait penser : 2 sur 8 dans le Comité d’adhésion des Développeurs, 2 sur 8 dans le Conseil de la Communauté, mais 6 sur 6 dans le Comité technique. Ce dernier chiffre, bien que non prémédité, n’est pas surprenant, étant donné la très grande implication attendue des membres potentiels du Comité technique. Mark, en tant que fondateur, est la seule personne à siéger de manière permanente à la fois au Conseil de la Communauté et au Comité technique.

Comparaison entre statuts Debian et Ubuntu

Le tableau suivant résume les autorisations accordées à chaque rôle existants parmi l’un ou l’autre projet (Passer la souris sur les acronymes pour en lire la signification).

Autorisations Debian Ubuntu
DM DD MU UPP/DU MOTU UCD
Maintenance du paquet via parrainageON/AOOON/A
Email officiel–OOOOO
Participation aux élections de membres–OOOOO
Participation aux élections de développeurs–O–OOO
Droits d’upload restreints sur liste de paquets déterminésO––O––
Droits d’upload restreints sur une section de l’archive––––O–
Droits d’upload non restreints–O–––O
Nombre de contributeurs (au 27/07/2010)117904462278563

Il est à noter que le nombre de contributeurs Ubuntu est approximatif, étant donné qu’un contributeur peut avoir plusieurs statuts (adhésion directe à un groupe launchpad) obtenus avec le temps (en engrangeant de l’expérience). L’imprécision a été grandement réduite en tenant compte des différences de membres entre les différents groupes mais cela reste forcément imparfait : certains MOTU sont également UPP de paquets présents dans l’archive principale, ce qui est tout à fait permis (dans ce cas ils n’ont été compté que comme MOTU). Une autre limitation du calcul vient du fait que certains membres d’équipes administratives sont indirectement inclus dans d’autres équipes, et apparaissent donc à tort dans le total.

Quoi qu’il en soit, ce tableau montre clairement qu’Ubuntu offre un panel de statuts bien plus large, reconnaissant le travail de chaque contributeur depuis le commencement tout en n’accordant les autorisations sensibles qu’à ceux qui ont clairement montré qu’ils les méritaient. Malgré cette différence, l’avantage reste de loin à Debian en ce qui concerne le nombre de développeurs, bien que ce chiffre ne fasse pas tout : beaucoup des contributeurs Ubuntu sont employés par Canonical (36 des 63 Core Developers ont enregistré une adresse @canonical.com sur leur compte launchpad, par exemple). En conséquence, ils consacreront vraisemblablement plus de temps à leur distribution que la moyenne des membres Debian. Il faudrait ramener la comparaison au nombre d’heures-hommes et, même s’il s’agit d’un défi théorique intéressant, il n’est pas d’une grande utilité dans la mesure où les projets continuent de coopérer.

Debian est conscient des imperfections de sa structure, et les possibles changements visant à intégrer les contributeurs non mainteneurs de paquets ont été abordés maintes fois. Les derniers efforts en date dans cette direction furent malheureusement perçus plus comme une solution imposée que comme une plate-forme de discussion, et furent rapidement enterrés par une résolution générale (RG). Et même si la résolution invitait à de nouvelles discussions et propositions, il n’en reste pas moins que lorsqu’une initiative particulière est corrigée de cette sorte, toute motivation d’aller plus loin s’évanouit.

Une évolution possible ?

Côté Ubuntu, les changements structurels effectués récemment écartent tout changement dans un avenir proche. Cependant, Ubuntu prévoit d’étendre encore l’usage de ces nouvelles fonctions, de sorte que d’avantage d’équipes bénéficient de la possibilité de contrôler les droits d’upload des paquets les concernant, et que plus de développeurs candidatent à un poste d’Uploader propre au paquet pour les paquets qu’ils connaissent très bien.

En ce qui concerne Debian, une récente discussion sur la liste de diffusion du projet a remis sur la table la problématique de la terminologie et il a été convenu que le Processus nouveau Mainteneur devait être renommé (« Processus du nouveau Développeur » a été suggéré). Mais Christoph Berg – Chargé de compte Debian et donc grandement impliqué dans l’équipe « Nouveau Mainteneur » a suggéré qu’il serait préférable d’implémenter au préalable les modifications longtemps attendues relatives à l’adhésion avant toute mise à jour de la documentation. Ce qui entraînera sans doutes une mise à jour du vocabulaire. Plus avant dans la discussion, il a confirmé que la réforme de l’adhésion fait partie des priorités de l’équipe (juste après la refonte du site nm.debian.org).

Que doit-on attendre de cette réforme ? Quelques éléments de réponse qui n’engagent que moi, basés sur mon expérience du projet; Debian n’ayant encore rien décidé.

  • En premier lieu : un nouveau statut pour les contributeurs non empaqueteurs. La difficulté résidant dans le parcours imposé et les droits accordés

  • Changements dans l’implémentation technique du statut de DM. Il est aujourd’hui impossible de donner les droits d’upload d’un paquet à un DM uniquement lorsque deux noms sont mentionnés dans le champ idoine (malgré le fait que l’un d’eux peut avoir une plus grande connaissance du paquet que l’autre). Au-delà de ce problème, on peut citer d’autres restrictions ennuyeuses telles que l’impossibilité d’uploader de nouveaux paquets binaires.

  • Un changement de la Constitution Debian en vue d’intégrer ces nouveaux statuts est quasi-inévitable.

  • D’autres changement invasifs ont été proposés, tels que le remplacement du processus de nouveau mainteneur par une simple désignation par les DD. Un tel changement est improbable. Le processus peut dès aujourd’hui être grandement simplifié par le responsable des candidatures si le candidat atteste de bonnes références des autres développeurs, et qu’il fait montre de contributions tangibles (par exemple telles que rapportées par des entrées dans l’historique des modifications de paquets Debian).

Presque deux ans se sont écoulés depuis les précédents efforts déployés en ce sens. L’équipe des nouveaux mainteneurs a recruté de nouveaux membres et est de manière générale en meilleure forme. Espérons que le prochain épisode connaîtra un meilleur dénouement.

Cet article est une traduction de Understanding Membership Structures in Debian and Ubuntu contribuée par Weierstrass01. Ne manquez pas une occasion de parfaire vos connaissances de Debian ou Ubuntu, abonnez-vous à ma newsletter en cliquant ici.

PS: Depuis que l’article a été rédigé, la situation a un peu évolué du côté Debian. Les contributeurs non-empaqueteurs ont officiellement accès au statut de « Développeur Debian » (voir l’annonce).

Filed Under: Actualités, Actualités Debian, Actualités Ubuntu Tagged With: Adhésion, Debian, Membre, Référence, Ubuntu

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

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

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

Comment utiliser plusieurs archives amont dans les paquets source Debian

Posted on 16/12/2010 Written by Raphaël Hertzog

Depuis l’introduction du format source « 3.0 (quilt) », il est maintenant possible d’intégrer plusieurs archives amont dans les paquets source Debian. Cet article a pour but de vous montrer comment faire avec votre propre paquet, étant donné qu’il est assez utile d’intégrer facilement des plugins, traductions ou documentations que les développeurs amont mettent à disposition sous forme d’archives séparées.

Explications pas-à-pas

Les sources de Spamassassin serviront d’exemple. La version en développement est la 3.3.1. L’archive principale est nommée de manière conventionnelle (spamassassin_3.3.1.orig.tar.gz) et contient le dossier racine des sources. Nous avons déjà un répertoire Debian dans la mesure où le paquet n’est pas nouveau.

Les développeurs mettent à disposition les règles spamassassin sous la forme d’une archive séparée nommée Mail-SpamAssassin-rules-3.3.1.r901671.tgz. On la récupère, la renomme spamassassin_3.3.1.orig-pkgrules.tar.gz et la copie dans le même répertoire que l’archive principale. Le suffixe « pkgrules » est non seulement la « clé » identifiant clairement l’archive amont, mais aussi le nom du dossier dans lequel il sera extrait à l’intérieur du paquet source. Un tel répertoire n’existant pas encore, nous devons le créer.

$ mv Mail-SpamAssassin-rules-3.3.1.r901671.tgz spamassassin_3.3.1.orig-pkgrules.tar.gz
$ cd spamassassin-3.3.1
$ mkdir pkgrules
$ tar -C pkgrules -zxf ../spamassassin_3.3.1.orig-pkgrules.tar.gz

Et cela suffit ! La prochaine fois que le paquet source sera généré, l’archive supplémentaire sera automatiquement intégrée dans le paquet.

$ dpkg-buildpackage -S
[...]
 dpkg-source -b spamassassin-3.3.1
dpkg-source: info: utilisation du format source « 3.0 (quilt) »
dpkg-source: info: construction de spamassassin à partir de ./spamassassin_3.3.1.orig-pkgrules.tar.gz ./spamassassin_3.3.1.orig.tar.gz
dpkg-source: info: construction de spamassassin dans spamassassin_3.3.1-1.debian.tar.gz
dpkg-source: info: construction de spamassassin dans spamassassin_3.3.1-1.dsc

L’archive supplémentaire est maintenant partie intégrante des sources mais, en l’état, ne sert à rien… il faut modifier le fichier debian/rules (ou debian/spamassin.install) pour installer les nouveaux fichiers dans le paquet binaire.

Un cas particulier : l’empaquetage d’un ensemble de logiciels connexes

Dans de très rares cas, vous pouvez être amenés à empaqueter ensemble plusieurs programmes (de petits modules Perl par exemple) et vous n’avez aucune archive principale, seulement plusieurs petites. Renommez-les selon la logique précédente, puis demandez à dpkg-source, lors de la génération du paquet, de créer une archive principale « factice » avec l’option --create-empty-orig :

$ dpkg-buildpackage -S --source-option=--create-empty-orig

Utilisez cette option avec précaution dans la mesure où le numéro de version que vous donnez au lot de programmes est très vraisemblablement décorrélé de celui de chaque programme.

Erreurs fréquentes

Oublier d’extraire les archives supplémentaires

Si vous oubliez d’extraire le contenu de l’archive supplémentaire dans le répertoire pkgrules, dpkg-source émettra de nombreux messages d’avertissement concernant la suppression des fichiers de cette archive. Il ne s’agit pas réellement d’une suppression, vous avez simplement oublié de les créer dans le répertoire précédent.

dpkg-source: avertissement: suppression du répertoire pkgrules ignorée
dpkg-source: avertissement: suppression du fichier pkgrules/20_fake_helo_tests.cf ignorée
dpkg-source: avertissement: suppression du fichier pkgrules/60_shortcircuit.cf ignorée
[...]

Mauvais numéro de version pour l’archive supplémentaire

Parfois l’archive supplémentaire se trouve dans une version ne correspondant pas à la version en développement. Vous devez nommez le fichier de façon cohérente avec la source amont, car dans le cas contraire il ne sera pas pris en compte par dpkg-source. Ce dernier générera un nouveau patch dans debian/patches contenant l’intégralité du nouveau dossier.

Rendre le nom du composant significatif en regard du numéro de version de l’archive supplémentaire est une solution possible (dans notre exemple ci-dessus, nous aurions pu ainsi adopter le suffixe « pkgrules-r901671 »). Le revers de la médaille consiste en un nom de dossier variable, changeant avec toute nouvelle version. Le corollaire étant bien sûr que vous devrez adapter vos règles d’empaquetage pour prendre en compte ce changement.

Ceci étant, cette astuce a le mérite de permettre la mise à jour du contenu additionnel sans pour autant impacter la version amont. L’envoi d’une nouvelle révision sera acceptée dans la mesure où l’archive principale sera ignorée — car inchangée — tandis que le contenu additionnel sera mis à jour (du fait du nom différent).

Assurez-vous cependant de retirer les anciennes versions des archives additionnelles, sans quoi vous auriez plusieurs copies différentes de la même archive dans votre paquet source !

Mauvaise extraction de l’archive supplémentaire

Vous devez faire preuve d’autant d’ingéniosité que dpkg-source lorsque vous extrayez manuellement l’archive supplémentaire !

Si l’archive contient uniquement un répertoire racine, celui-ci est extrait, renommé pour correspondre au nom du composant et déplacé dans le répertoire du paquet source.
Dans le cas contraire (plusieurs répertoires à la racine), alors le répertoire de destination est créé en premier et le contenu de l’archive directement extrait dans celui-ci.

Ci-dessous des commandes pour faire face dans tous les cas (le répertoire courant est supposé être celui du paquet source) :

$ mkdir pkgrules
# L'archive contient un unique répertoire de premier niveau
$ tar -C pkgrules --strip-components=1 -zxf ../spamassassin_3.3.1.orig-pkgrules.tar.gz
# L'archive contient plusieurs fichiers/répertoires au premier niveau
$ tar -C pkgrules -zxf ../spamassassin_3.3.1.orig-pkgrules.tar.gz

Cet article est une traduction de How to use multiple upstream tarballs in Debian source 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.

Filed Under: Documentation, Documentation pour les contributeurs Tagged With: 3.0 (quilt), Debian, dpkg-source, HOWTO, Libre, Packaging, Ubuntu

  • « Previous Page
  • 1
  • …
  • 24
  • 25
  • 26
  • 27
  • 28
  • …
  • 46
  • Next Page »

Découvrez mes ouvrages

Apprenez en plus en cliquant sur leur couverture :

Lettre d’informations

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

Suivez moi

  • Adresse mail
  • Facebook
  • GitHub
  • RSS
  • Twitter

Archives

Planètes

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

Flux Mon blog anglophone sur le libre

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

Mots-clés

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

Articles récents

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

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