Les paquets binaires de la distribution Debian sont créés à partir des paquets sources, lesquels sont dans un format spécial pour faciliter la construction automatique des binaires.
Une version précédente du format source Debian est devenue obsolète. Les instructions pour convertir les vieux paquets sont données dans la charte Debian.
De nombreux outils sont fournis pour manipuler les paquets sources. Ils emballent et déballent les sources, aident à la construction des paquets binaires et gèrent la distribution des nouvelles versions.
Ils sont présentés ici et leurs usages habituels décrits ; pour de plus amples
informations, voir dpkg-source(1)
.
Le paquet hello
est un exemple de construction de paquet source
Debian et de la mise en oeuvre des utilitaires qui y sont impliqués.
dpkg-source
- faire et défaire un paquet source Debian
Ce programme est fréquemment utilisé sur la ligne de commande ; il est aussi
appelé à partir des scripts de construction automatique de paquet, tel que
dpkg-buildpackage
.
Il est appelé ainsi pour dépaqueter un paquet :
dpkg-source -x .../path/to/filename.dsc
avec filename.tar.gz et filename.diff.gz (si c'est utile) dans le même répertoire. Il dépaquette dans package-version, et, si utile, package-version.orig, dans le répertoire actuel.
Pour créer un paquet, on utilise :
dpkg-source -b paquet-version
Les fichiers .dsc, .tar.gz et .diff.gz
seront créés (si c'est utile) dans le répertoire courant.
dpkg-source
n'efface pas l'arborescence des sources. Ceci doit
être fait séparément, si nécessaire.
Voir aussi Les paquets sources en tant qu'archive, Section C.3.
dpkg-buildpackage
- script de contrôle pour la construction de paquet
dpkg-buidpackage
est un script qui fait appel à
dpkg-source
, aux cibles de debian/rules :
clean, build et binary, à
dpkg-genchanges
et à pgp
pour construire un paquet
signé, source et binaire, installable sur le serveur.
Il est généralement utilisé sur la ligne de commande, à la racine du répertoire source à créer ou à détruire. Il peut être invoqué sans arguments. Les arguments utiles sont :
pgp
.
dpkg-buildpackage
ne
fera rien pour obtenir les privilèges de root ; ainsi, pour la plupart des
programmes, il devra être appelé par root pour démarrer.
dpkg-source(1)
.
dpkg-gencontrol
- créer des fichiers de contrôle pour les paquets binairesCe programme est habituellement appelé à partir du fichier debian/rules (voir L'arborescence debianisée, Section C.2) depuis la racine de l'arborescence source.
On l'appelle juste avant que ne soit établi le système des permissions pour les
fichiers et les répertoires du répertoire temporaire où le paquet est construit
et avant la construction du paquet par dpkg-deb/
[68].
dpkg-gencontrol
doit être appelé après que tous les fichiers du
paquet ont été mis en place dans le répertoire temporaire de construction, afin
que le calcul de la taille du paquet installé soit correct.
Il faut aussi que dpkg-gencontrol
soit exécuté après
dpkg-shlibdeps
afin que les variables de substitutions, créées par
dpkg-shlibdeps
dans le fichier debian/substvars,
soient disponibles.
Un paquet qui crée un seul paquet binaire et qui le construit dans le répertoire debian/tmp relatif à la racine du paquet source, appellera simplement : dpkg-gencontrol.
Les sources qui construisent plusieurs binaires utiliseront :
dpkg-gencontrol -Pdebian/tmp-pkg -ppaquet
L'argument P indique à dpkg-gencontrol
que le paquet
est en train de se construire dans un répertoire différent de celui par défaut
et l'argument -p indique le fichier de contrôle qui sera créé.
dpkg-gencontrol
ajoute aussi des informations à la liste des
fichiers dans debian/files ; cela peut servir à un prochain appel
à dpkg-genchanges
.
dpkg-shlibdeps
- les dépendances des bibliothèques partagées
Ce programme est habituellement appelé à partir du fichier
debian/rules, juste avant dpkg-gencontrol
(voir L'arborescence debianisée,
Section C.2), à la racine de l'arborescence source.
Les arguments sont des exécutables [69] pour lesquels les dépendances des bibliothèques partagées seront incluses dans le fichier de contrôle du paquet.
Si certaines bibliothèques partagées doivent seulement justifier d'un Recommends ou d'un Suggests, ou si certaines demandent un Pre-Depends, ceci peut être réalisé en utilisant l'option -ddependency-field avant ces exécutables (chaque option -d prend effet jusqu'au prochain -d).
dpkg-shlibdeps
ne modifie pas directement le fichier de contrôle.
Par défaut, il ajoute au fichier debian/substvars des variables
comme shlibs:Depends. Ces variables doivent être référencées dans
les champs de dépendance du fichier de contrôle source dans les sections
propres aux paquets binaires.
Par exemple, le paquet procps
/ crée deux types de binaires, des
binaires C simples comme ps
qui demandent une pré-dépendance, et
des binaires utilisant ncurses
comme top
qui ne
demandent qu'une recommandation. Cela peut être indiqué dans le
fichier debian/rules par :
dpkg-shlibdeps -dPre-Depends ps -dRecommends top
et ensuite dans le fichier principal de contrôle debian/control :
... Package: procps Pre-Depends: ${shlibs:Pre-Depends} Recommends: ${shlibs:Recommends} ...
Les sources qui produisent plusieurs paquets binaires avec des exigences
différentes pour les dépendances envers les bibliothèques partagées peuvent
utiliser l'option -pvarnameprefix pour annuler le
préfixe shlib: par défaut (un seul appel à
dpkg-shlibdeps
par réglage de cette option). Ils peuvent ainsi
produire plusieurs ensembles de variables de dépendance, chacune de la forme
varnameprefix:dependencyfield, auxquelles
peuvent se référer les parties appropriées des fichiers de contrôle des paquets
binaires.
dpkg-distaddfile
- ajouter un fichier à debian/filesCertaines installations de paquets sur le serveur nécessitent d'inclure d'autres fichiers que les fichiers des paquets sources et binaires.
dpkg-distaddfile
ajoute un fichier dans debian/files
afin qu'il soit inclus dans le fichier .changes lorsque
dpkg-genchanges
sera lancé.
Il est habituellement invoqué à partir de la cible binary
du
fichier debian/rules :
dpkg-distaddfile filename section priority
L'argument filename est relatif au répertoire où
dpkg-genchanges
s'attend à le trouver, généralement au-dessus de
la racine de l'arborescence source. La règle de debian/rules
devrait placer ce fichier juste avant ou juste après l'appel à
dpkg-distaddfile
.
Les arguments section et priority sont placés sans modification dans le fichier résultant .changes. Voir Section et Priority, Section D.2.9.
dpkg-genchanges
- créer un fichier de contrôle de l'installation sur le serveur .changes
Ce programme est généralement appelé par des scripts de construction
automatique de paquet tels que dpkg-buildpackage
mais peut être
aussi appelé sur la ligne de commande.
Il est habituellement exécuté à la racine de l'arborescence source construite, et quand il est invoqué sans arguments, il écrira un simple fichier .changes basé sur les informations des fichiers de contrôle et de changement des paquets sources, et des paquets sources et binaires qui ont dû être construits.
dpkg-parsechangelog
- produire une représentation du fichier changelog
Ce programme est utilisé en interne par dpkg-source
et al. Il
peut être aussi occasionnellement utilisé dans debian/rules et
ailleurs. Il analyse un fichier changelog, par défaut
debian/changelog, et affiche sur la sortie standard une
représentation des informations contenues faite selon le format d'un fichier de
contrôle.
dpkg-architecture
- informations sur les systèmes de construction et d'installationOn peut utiliser ce programme sur la ligne de commande ; mais il est aussi appelé par dpkg-buildpackage ou debian/rules pour déterminer les variables d'environnement qui indiquent les architectures utilisées pour la construction et pour l'installation pendant le processus de construction du paquet.
La structure de l'archive source, décrite ci-dessous, a été conçue pour permettre à une arborescence source debianisée et ses informations de contrôle associées d'être facilement dupliquée et transportée. L'arborescence source debianisée comprend une version du programme original, certains fichiers ajoutés pour le processus de débianisation, ainsi que tous les changements nécessaires réalisés sur les codes sources et scripts d'installation.
Les fichiers supplémentaires créés pour Debian sont dans le répertoire debian à la racine de l'arborescence source debianisée. Ils sont décrits ci-dessous.
Ce fichier est un makefile exécutable, qui contient les règles spécifiques au paquet pour compiler et construire les binaires à partir des paquets sources.
Il doit commencer par #!/usr/bin/make -f de manière à pouvoir être
appelé par son nom plutôt que par un make
explicite.
Puisqu'un script debian/rules interactif ne peut pas compiler un
paquet automatiquement et empêche une reproduction de ce paquet binaire par
d'autres personnes, toutes les cibles exigées doivent être non
interactives. Au minimum, les cibles exigées sont celles qu'appelle
dpkg-buildpackage
, à savoir, clean, binary,
binary-arch, binary-indep, et build. Il s'ensuit
qu'une cible dont dépendent ces cibles, doit être aussi non interactive.
Les cibles nécessaires sont :
Un paquet peut aussi proposer les deux cibles build-arch et build-indep. Si la cible build-arch existe, elle fera toute la configuration non interactive et la compilation nécessaire pour créer les paquets binaires pour chaque architecture (ce sont les paquets dont le champ Architecture dans le fichier debian/control est différent de all). De même, si la cible build-indep existe, elle fera toute la configuration non interactive et la compilation nécessaire pour créer les paquets binaires indépendant d'une architecture (ce sont les paquets dont le champ Architecture dans le fichier debian/control vaut all). La cible build dépendra des cibles build-arch et build-indep qui sont données par le fichier rules.
Quand manque l'une des cibles build-arch et
build-indep (ou les deux), un appel à debian/rules
avec l'une des cibles manquantes provoquera un code d'erreur égal à 2. Quand
une cible manque, make
produit automatiquement ce code.
Pour certains paquets, notamment ceux où le même arbre source est compilé de différentes façons pour obtenir deux paquets binaires, la cible build n'a aucun sens. Pour ces paquets, il est bon de prévoir deux cibles ou plus (build-a et build-b, p.ex.) pour chaque manière de construire le paquet et une cible build qui ne produit rien. La cible binary s'occupera de construire le paquet pour chaque cas possible et de créer le paquet binaire de chacun d'eux.
Les cibles build, build-arch et build-indep ne doivent pas effectuer d'actions qui exigent les privilèges de root.
La cible build peut avoir besoin d'exécuter d'abord la cible clean. Voir ci-dessous.
Quand un paquet possède une routine de configuration qui prend du temps, ou
quand le makefile est pauvrement conçu, ou quand build a
d'abord besoin d'exécuter clean, il est alors intéressant
d'exécuter touch build
quand le processus de construction est
terminé. Cela assurera que si debian/rules build est exécuté à
nouveau, il ne reconstruira pas le programme complet.
binary peut être (et c'est communément le cas) une cible sans commande, qui dépend simplement de binary-arch et de binary-indep.
Les deux cibles binary-* dépendront de la cible build
ci-dessus, afin que le paquet soit construit s'il ne l'a pas déjà été. Elle
créera ensuite les paquets binaires pertinents en utilisant
dpkg-gencontrol
pour créer leurs fichiers de contrôle et
dpkg-deb
pour construire les binaires et les placer dans le
répertoire parent du répertoire racine.
Si l'une des deux cibles binary-*
n'a rien à faire (ce sera
toujours le cas si le source crée un seul paquet binaire, qu'il soit dépendant
de l'architecture ou pas), elle doit tout de même exister, et doit toujours se
dérouler correctement.
Les paquets binaires (annexe tirée de l'ancien Packaging Manual), Appendix B décrit la construction de paquets binaires.
La cible binary doit être invoquée avec les privilèges de root.
Si un fichier build est créé par touch
à la fin de la
cible build, comme suggéré ci-dessus, c'est la première chose qui
sera effacée par la cible clean ; ainsi build,
exécutée de nouveau après un nettoyage (clean) interrompu, ne
pensera pas que tout est déjà fait.
La cible clean doit être invoquée par root, si binary a été invoquée depuis le dernier clean, ou si build a été invoquée par root (étant donné que build peut créer des répertoires par exemple).
Cette cible peut être invoquée dans n'importe quel répertoire et s'occupera de supprimer tous ses fichiers temporaires.
Elle est facultative mais la proposer, quand c'est possible, est une bonne idée.
Les cibles build, binary et clean doivent être invoquées avec comme répertoire actuel, le répertoire de plus haut niveau du paquet.
Des cibles supplémentaires peuvent exister dans debian/rules, soit comme des interfaces publiées ou non documentées soit pour l'utilisation interne du paquet.
Ce sont les variables de make
à travers
dpkg-architecture
qui déterminent l'architecture sur
laquelle et celle pour laquelle on construit. On peut obtenir, aussi
bien pour la machine sur laquelle on construit que pour la machine pour
laquelle on construit, la chaîne indiquant l'architecture Debian et la chaîne
indiquant l'architecture à la façon GNU. Voici une liste de variables
acceptées par make
:
où * représente BUILD pour une indication de la machine sur laquelle on construit, ou bien HOST pour une indication de la machine pour laquelle on construit.
On peut assurer une compatibilité ascendante dans le fichier rules en
fixant par défaut les bonnes variables à des valeurs adéquates ; veuillez
consulter la documentation de dpkg-architecture
pour des
précisions.
Il est important de comprendre que la chaîne DEB_*_ARCH détermine seulement l'architecture Debian sur ou pour laquelle on construit. On ne l'utilisera pas pour avoir des renseignements sur le CPU ou le système ; les variables GNU sont là pour ça.
Ce fichier contient des informations indépendantes des versions sur le paquet sources et sur les paquets binaires qu'il crée.
C'est une série d'ensembles de champs de contrôle, chacun syntaxiquement similaire à un fichier de contrôle de paquet binaire. Les ensembles sont séparés par une ou plusieurs lignes vides. Le premier ensemble contient en général les informations sur le paquet source ; chaque ensemble suivant décrit un paquet binaire que l'arbre source construit.
La syntaxe et la sémantique des champs sont décrites ci-dessous dans Les fichiers de contrôle et leurs champs (annexe tirée de l'ancien Packaging Manual), Appendix D.
Les champs généraux (indépendant des paquets binaires) sont :
Les champs pour les paquets binaires sont :
Ces champs sont utilisés par dpkg-gencontrol
pour créer les
fichiers de contrôle pour les paquets binaires (voir ci-dessus), par
dpkg-genchanges
pour créer le fichier .changes qui
accompagne l'installation sur le serveur et par dpkg-source
quand
il crée le fichier de contrôle source .dsc comme une partie de
l'archive source.
Les champs peuvent contenir des références à des variables, leurs valeurs
seront substituées par dpkg-gencontrol
,
dpkg-genchanges
ou dpkg-source
quand ils créeront les
fichiers de sortie. Voir debian/substvars
et les variables de substitution, Section C.2.4 pour des précisions.
Des champs utilisateurs supplémentaires peuvent être ajoutés au fichier de contrôle du paquet source. Ces champs seront ignorés, ne seront pas copiés dans les fichiers de contrôle des paquets sources ou binaires (par exemple) ou dans les fichiers de contrôle de l'installation sur le serveur.
Quand on souhaite ajouter des champs supplémentaires non supportés à ces fichiers de sortie, on utilisera le mécanisme décrit ci-dessous.
Les champs du fichier principal de contrôle de source avec des noms commençant par X, suivis par une ou plusieurs lettres BCS et un trait d'union -, seront copiés vers les fichiers de sortie. Seule la partie du nom du champ qui se trouve après le trait d'union sera utilisée dans le fichier de sortie. Si la lettre B est utilisée, le champ apparaîtra dans les fichiers de contrôle des paquets binaires, si c'est la lettre S, dans les fichiers de contrôle de paquet source, et si c'est la lettre C, dans les fichiers de contrôle de l'installation sur le serveur (.changes).
Par exemple, le fichier principal de contrôle de source contient le champ suivant :
XBS-Comment: I stand between the candle and the star.
alors les fichiers de contrôle des paquets sources et binaires contiendront le champ :
Comment: I stand between the candle and the star.
Ce fichier enregistre les changements faits sur les parties spécifiques Debian d'un paquet [70].
Il possède un format spécial qui permet aux outils de construction de paquets de découvrir quelle version du paquet est en train de se construire et de trouver d'autres informations spécifiques à la version.
Le format est une série d'entrées comme celles-ci :
package (version) distribution(s); urgency=\urgency * change details more change details * even more change details
package et version sont le nom du paquet source et le numéro de version.
distribution(s) listent les distributions où cette version sera placée quand elle est installée sur le serveur. Le champ Distributions est copié dans le fichier .changes.
urgency est la valeur pour le champ Urgency dans le fichier .changes pour l' installation sur le serveur. Voir Urgency, Section D.2.15. Il n'est pas possible de spécifier une urgency contenant des virgules ; les virgules sont utilisées pour séparer les couples (mot clé=valeur) dans le format du fichier d'enregistrement de dpkg (bien qu'il n'y ait pour l'instant qu'un seul mot clé utile : urgency).
L'énoncé des modifications peut tenir sur des séries de ligne commençant au moins par deux espaces, mais par convention, chaque modification commence par une étoile * et un espace, les lignes de continuation sont décalées pour les amener en face du texte de la ligne précédente. Les lignes vides peuvent être utilisées pour séparer des groupes de modifications.
Le nom du responsable et son adresse ne sont pas nécessairement les mêmes que ceux du responsable habituel du paquet. Ils doivent correspondre à la personne qui s'est occupée de cette version. Les informations seront copiées dans le fichiers .changes, et utilisées plus tard pour envoyer un accusé de réception quand l'installation sur le serveur sera terminée.
La date doit être dans le format défini par la RFC 822 [71] ; elle doit inclure le nom du fuseau horaire (timezone) spécifié numériquement, et en option le nom du fuseau ou son abréviation.
La première ligne de « titre » avec le nom du paquet doit commencer sur la marge de gauche, la ligne de « fin » avec les informations sur le responsable et la date doit être précédée par un seul espace. Les informations sur le responsable et la date doivent être séparées exactement par deux espaces.
Un mode Emacs pour modifier ce format est disponible : debian-changelog-mode. On peut sélectionner ce mode automatiquement quand on édite un fichier changelog Debian en ajoutant une clause de variables locales à la fin du fichier changelog.
Il est possible d'utiliser un format différent de celui proposé, en fournissant un analyseur pour le format qu'on veut utiliser.
Pour que dpkg-parsechangelog exécute l'analyseur, on inclura une ligne à l'intérieur des quarante dernières lignes du fichier correspondant à l'expression rationnelle Perl suivante : \schangelog-format:\s+([0-9a-z]+)\W. La partie entre parenthèses sera le nom du format. Par exemple, on pourrait dire :
@@@ changelog-format: joebloggs @@@
Les noms des formats pour changelog sont des chaînes non vides d'alphanumériques.
Quand une telle ligne existe, dpkg-parsechangelog cherche l'analyseur dans /usr/lib/dpkg/parsechangelog/format-name ou dans /usr/local/lib/dpkg/parsechangelog/format-name ; c'est une erreur de ne pas le trouver, ou qu'il ne soit pas exécutable. Le format changelog par défaut est dpkg et un analyseur est fourni avec le paquet dpkg.
L'analyseur sera invoqué, au début du fichier, avec le changelog ouvert sur l'entrée standard. Il lira le fichier (ou le parcourra avec seek) pour trouver l'information et la retourner analysée sur la sortie standard sous la forme d'une série de champ de contrôle dans le format standard. Par défaut, il retournera seulement les informations les plus récentes du fichier changelog ; il acceptera l'option -vversion pour retourner les informations de changement de toutes les versions présentes strictement supérieures version et rendre une erreur pour une version non présente dans le fichier changelog.
Les champs sont :
Si plusieurs versions sont retournées (à cause de l'utilisation de l'option -v), la valeur urgency sera la plus grande listée par toutes les versions requises et sera suivie par les commentaires concaténés (séparés par un espace) de toutes les versions requises ; les champs : maintainer, version, distribution et date proviennent toujours de la version la plus récente.
Pour le format du champ Changes voir Changes, Section D.2.18.
Si le format du fichier changelog analysé laisse toujours ou presque toujours une ligne vide entre les notes de modifications individuelles, ces lignes vides seront supprimées, pour rendre la sortie résultante plus compacte.
Si le format de changelog ne contient pas de date ou d'information sur le nom du paquet, ces informations seront omises en sortie. L'analyseur ne doit pas essayer de les synthétiser ou de les trouver à partir d'autres sources.
Si le fichier changelog n'a pas le format attendu, l'analyseur se terminera avec un statut différent de zéro, plutôt que d'essayer de se débrouiller tant bien que mal et créer des sorties incorrectes.
Un analyseur de changelog ne doit pas être interactif.
Quand dpkg-gencontrol
, dpkg-genchanges
et
dpkg-source
créent des fichiers de contrôle, ils procèdent au
remplacement des variables qu'ils doivent écrire dans ces fichiers. Les
substitutions de variable sont de la forme
${variable-nom}. Le fichier facultatif
debian/substvars contient les remplacements de variable à
utiliser. On peut aussi fixer directement les variables dans le fichier
debian/rules en utilisant l'option -V des commandes
d'empaquetage des sources ; certaines variables prédéfinies sont disponibles.
Le fichier debian/substvars est habituellement créé et modifié dynamiquement par les cibles de debian/rules, et dans ce cas, il doit être supprimé par la cible clean.
Voyez dpkg-source(1)
pour plus de détails sur les remplacements de
variables source, et sur le format de debian/substvars.
Ce fichier n'est pas un fichier permanent de l'arborescence source ; il est
utilisé pendant la construction des paquets pour enregistrer quels fichiers
sont en train d'être créés. dpkg-genchanges
l'utilise quand il
crée un fichier .changes.
Ce fichier ne doit pas exister dans le paquet source qu'on propose, et il doit être supprimé par la règle clean (ainsi que n'importe quel fichier temporaire ou de sauvegarde tel que files.new [72]). Il peut aussi être sage, pour garantir un nouveau départ, de l'enlever ou de le vider au début de la cible binary.
Quand dpkg-gencontrol
est exécuté pour un paquet binaire, il
ajoute une entrée dans le fichier debian/files pour le fichier
.deb qui sera créé quand dpkg-deb --build sera
exécuté pour ce paquet binaire. Ainsi pour la plupart des paquets, il n'y a
rien d'autre à faire que de supprimer ce fichier dans la cible
clean.
Si un chargement de paquet inclut des fichiers autres que ceux du paquet source
ou des paquets binaires dont les fichiers de contrôle ont été créés par
dpkg-gencontrol
, ces fichiers seront placés dans le répertoire
parent du répertoire racine du paquet et dpkg-distaddfile
sera
appelé pour ajouter ces fichiers à la liste debian/files.
C'est l'emplacement temporaire, pour la construction des paquets binaires par
la cible binary. Le répertoire tmp sert de racine à
l'arbre du système de fichier qui est en train de se construire (par exemple en
utilisant la règle d'installation du Makefile
du paquet original
et en le redirigeant dans tmp), et il contient aussi le
sous-répertoire DEBIAN. Voir Comment créer les fichiers d'un
paquet ? -- dpkg-deb
, Section B.1.
Si plusieurs paquets binaires sont créés à partir du même arbre source, il est habituel d'utiliser plusieurs répertoires debian/tmp-truc, par exemple tmp-a ou tmp-doc.
Quelques soient les répertoires tmp créés et utilisés par binary, la cible clean doit bien sûr les effacer.
Sur les sites FTP, les paquets sources contiennent trois fichiers reliés entre eux. On doit avoir les trois bonnes versions pour pouvoir les utiliser.
Le fichier de contrôle du paquet source est créé par dpkg-source
quand il crée l'archive source, à partir des autres fichiers dans le paquet
source, décrit ci-dessus. Quand on le déballe, il est vérifié par rapport aux
autres fichiers et répertoires dans les autres parties du paquet source, comme
décrit ci-dessous.
tar
compressé (avec gzip -9
)
contenant le code source de l'auteur original du programme. Le fichier
tar
est déballé dans un répertoire paquet-version-
originale.orig. Il ne contient aucun fichier en dehors de
ses sous-répertoires.
Tous les répertoires dans le fichier diff doivent exister, sauf le
sous-répertoire debian à la racine de l'arbre source, qui sera
crée par dpkg-source
, si nécessaire, lors de l'extraction.
Le programme dpkg-source
rendra automatiquement exécutable le
fichier debian/rules (voir ci-dessous).
S'il n'y a pas de code source original, par exemple, si le paquet a été
spécialement préparé pour Debian ou si le responsable Debian est le même que le
responsable original, le format est alors légèrement différent : il n'y
pas de fichier diff et le fichier tar
est nommé
paquet-version.tar.gz et contient un répertoire
paquet-version.
dpkg-source
dpkg-source -x
est la manière recommandée pour dépaqueter un
paquet source Debian. Cependant, si le programme n'est pas disponible, il est
possible de faire comme suit :
Il n'est pas possible de créer une archive source Debian valide sans utiliser
dpkg-source
. En particulier, essayer d'utiliser diff
directement pour créer le fichier .diff.gz ne fonctionnera pas.
Un paquet source ne peut pas contenir des liens « en dur »[73][74], des fichiers spéciaux pour les device, des sockets ou des fichiers setuid ou setgid[75].
Les outils de paquetage source gèrent les modifications entre les fichiers
sources originaux et ceux débianisé en utilisant diff
et
patch
. Modifier l'arbre source original inclus dans
.orig.tar.gz en un source débianisé ne doit pas impliquer de
changements qui ne peuvent pas être maintenus par ces outils. Les changements
problématiques qui provoquent une erreur de la part de dpkg-source
pour construire le paquet source sont :
Les modifications qui provoqueront un avertissement de la part de
dpkg-source
sont :
Les changements qui ne sont pas représentés et qui ne sont pas détectés par
dpkg-source
sont :
Le répertoire Debian et debian/rules sont manipulés
spécialement par dpkg-source
. Avant d'appliquer les changements,
il créera le répertoire debian, après quoi il rendra exécutable
par tout le monde le fichier debian/rules.
La Charte Debian
version 3.5.6.1 cvs 1.68 03/2002ijackson@gnu.ai.mit.edu
schwarz@debian.org
bweaver@debian.org
debian-policy@lists.debian.org