GitPackaging » Historique » Version 41
Version 40 (Lionel Morin, 12/04/2012 11:31) → Version 41/45 (Benjamin Bohard, 16/05/2012 10:07)
{{toc}}
h1. Séparation du code et du packaging
Cela facilite le travail de tout le monde, aussi bien des développeurs que des packageurs.
De plus, il est ainsi plus facile de fournir le même code pour plusieurs distributions différentes, cela sera utile notamment lors du portage des applications sur "Precise Pangolin":http://fr.wikipedia.org/wiki/Liste_des_versions_d%27Ubuntu#Ubuntu_12.04_LTS_.28Precise_Pangolin.29
Le principe de base est le suivant :
* Tout ce qui est du ressort du packaging, c’est à dire tous les fichiers présents dans le répertoire @debian/@ pour les "paquets deb":http://fr.wikipedia.org/wiki/Deb, sont et doivent être modifiés dans la branche @dist/<VENDOR>/<DISTRIBUTION>/master@
* Tout le reste, c’est à dire le code, par exemple les dictionnaires, templates, scripts, agents zéphir, sont dans la branche publique adéquat, c’est a dire @master@ pour le code en développement, @2.2@ pour le code spécifique à la version @2.2@ d’EOLE.
Le workflow de base est le suivant:
# Je code dans une branche personnelle, par exemple @dad/mise-au-propre-du-makefile@
# Je teste, cela va de soi ;-)
# Je [[GitBonnesPratiques#Publication-du-développement|publie dans la branche publique]]
# J’intègre ces modifications à la branche de packaging afin de compiler un nouveau paquet
h2. Le développement dans @master@
Les développeurs gèrent cette branche [[GitBonnesPratiques|comme bon leur semble]], ils ne seront pas gênés par le packaging, en particulier les changements sur @debian/changelog@ à chaque compilation de paquet.
Les règles habituellement admises dans le monde du logiciel libre sur l’installation sont conseillées, par exemple :
* Écrire un "Makefile":http://fr.wikipedia.org/wiki/Makefile utilisant la variable @$(DEST)@ pour désigner la racine d’installation
* Utiliser les "autotools":http://fr.wikipedia.org/wiki/Autotools pour permettre la configuration des différents répertoires d’installation
L’idéal, en tant que développeur, peut être de pouvoir cloner la branche master sur une machine de test et de lancer les commandes :
# @make@ : pour compiler ce qui est compilable
# @make install@ : pour installer les fichiers et faire les tests
# @make uninstall@ : pour nettoyer ce qui a été installé
La branche @master@ étant la branche publique des derniers développements, il est utile d’[[GitTagging|étiqueter]] des états techniques utilisables et/ou à tester.
h2. Le packaging dans @dist/<VENDOR>/<DISTRIBUTION>/master@
Le packaging se compose de deux parties :
# Le code dit « upstream »
# Le code permettant de « faire le paquet », c’est à dire le contenu du répertoire @debian/@ pour les "paquets deb":http://fr.wikipedia.org/wiki/Deb.
h3. La première fois, c’est toujours la plus difficile
Un outil est disponible pour préparer le packaging d’un logiciel: "dh-make":http://packages.qa.debian.org/d/dh-make.html, son utilisation est plutôt simple.
# On récupère un projet :
<pre>
buildd@build:~/src/$ git clone http://dev-eole.ac-dijon.fr/git/eole-debsums && cd eole-debsums
</pre>
# On créé une branche de packaging :
<pre>
buildd@build:~/src/eole-debsums(master)$ git checkout -b dist/ubuntu/lucid/master
</pre>
# On créer un packaging de base :
<pre>
buildd@build:~/src/eole-debsums(dist/ubuntu/lucid/master)$ dh_make -c <LICENCE> -p eole-debsums_<VERSION> --createorig
[...] # Répondre aux questions
</pre>
# On ajoute ce packaging au "stagging area":http://progit.org/book/fr/ch2-2.html
<pre>
buildd@build:~/src/eole-debsums(dist/ubuntu/lucid/master)$ git add debian
</pre>
# On commit ce premier packaging, cela fait un point de départ même s’il n’est pas utilisable
<pre>
buildd@build:~/src/eole-debsums(dist/ubuntu/lucid/master)$ git commit -m "Debianisation du projet par dh_make" # Ne pas utiliser -m et faire un vrai message de log
</pre>
À partir de là il faut éditer les fichiers présents dans le répertoire @debian/@, principalement :
* @debian/control@ :
** Faire attention au mainteneur ;
** Faire attention à l’architecture cible : "any" pour des binaires (i386/amd64), "all" pour les paquets indépendant de l’architecture matérielle (documentation, scripts perl, …)
** Faire attention à la version de la "Debian policy":http://www.debian.org/doc/debian-policy utilisée, 3.8.2 sur Lucid ;
** Faire attention à la version de debhelper, @>= 7.4@ sur Lucid ;
** Mettre une description, courte et longue, les métas paquets "doivent":http://lintian.debian.org/tags/empty-binary-package.html utiliser une des expressions "metapackage," "dummy," "dependency package," "empty package," ou "virtual package" dans la description longue
* @debian/compat@ : utiliser 7 pour Lucid
* @debian/copyright@.
Supprimer l’extention @.ex@ ou @.EX@ des fichiers qui seront utiles et les modifier.
Des informations sur le packaging sont disponibles dans la "documentation Debian":http://www.debian.org/doc/devel-manuals
# On commence par une "introduction au packaging":http://www.debian.org/doc/devel-manuals#packaging-tutorial
# La "politique Debian":http://www.debian.org/doc/devel-manuals#policy est la référence sur les obligations que doivent suivre les paquets Debian
# Un chapitre sur les "meilleurs pratiques de packaging":http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.fr.html est disponible dans la "Référence du développeur Debian":http://www.debian.org/doc/manuals/developers-reference/index.fr.html
Nous fournissons aussi un petit [[EoleDebianPackaging|recueil de packaging EOLE]]
h3. Mise à jour du packaging
La mise à jour du packaging ne requiert pas grand chose par rapport à la création d’un nouveau paquet:
# On se place dans la branche de packaging voulu
# On modifie les fichiers dans le répertoire @debian/@ en fonction des besoins
# On publie ces modifications
# On compile un paquet, ou pas
h3. Nouveau paquet, sans modification du packaging
Afin de faire un paquet, il faut intégrer la branche de développement souhaitée, par exemple:
# On passe sur la branche de packaging :
<pre>buildd@build:~/src/eole-debsums(master)$ git checkout dist/ubuntu/lucid/master</pre>
# On intègre les modifications faites par les autres (et eolepack) :
<pre>buildd@build:~/src/eole-debsums(dist/ubuntu/lucid/master)$ git pull</pre>
# On intègre nos modifications :
<pre>buildd@build:~/src/eole-debsums(dist/ubuntu/lucid/master)$ git merge master</pre>
# On envoi sur le dépôt central pour eolepack :
<pre>buildd@build:~/src/eole-debsums(dist/ubuntu/lucid/master)$ git push</pre>
# On se replace sur la branche de développement pour nos futures modifications
<pre>buildd@build:~/src/eole-debsums(dist/ubuntu/lucid/master)$ git checkout master</pre>
# On compile un nouveau paquet, ou pas
NB: La branche par défaut dans eolepack est modifiée pour être @dist/ubuntu/lucid/master@.
h4. Aide à la console (aka helper bash)
Un petit script @bash@ (attachment:git-package) peut-être utilisé afin d’automatiser la procédure, il suffit de le mettre dans un répertoire du @PATH@, comme @/usr/local/bin@ et il sera pris automatiquement en compte par git:
<pre>
buildd@build:~/src/eole-debsums(master)$ git package lucid
Do you want to merge 'master' into 'dist/ubuntu/lucid/master'?: y
Checkout 'lucid' master distribution branch 'dist/ubuntu/lucid/master': Switched to branch 'dist/ubuntu/lucid/master'
Pull from default remote: Already up-to-date.
Merge developpement from 'master': Already up-to-date.
Switch back to your developpement branch 'master'... Switched to branch 'master'
Push is not automatically done to avoid publishing possible errors.
buildd@build:~/src/eole-debsums(master)$
</pre>
Et comme c’est connu que les informaticiens sont fainéants (enfin seulement les bons ;-)), il est possible de saisir encore moins de caractères en se faisant un alias dans git (pas nécessaire de le faire dans le shell):
<pre>
buildd@build:~/src/eole-debsums(master)$ git config --global alias.lucid 'package lucid'
</pre>
Ensuite, il n’y a plus qu’a l’utiliser:
<pre>
buildd@build:~/src/eole-debsums(master)$ git lucid
Do you want to merge 'master' into 'dist/ubuntu/lucid/master'?: y
Checkout 'lucid' master distribution branch 'dist/ubuntu/lucid/master': Switched to branch 'dist/ubuntu/lucid/master'
Pull from default remote: Already up-to-date.
Merge developpement from 'master': Already up-to-date.
Switch back to your developpement branch 'master'... Switched to branch 'master'
Push is not automatically done to avoid publishing possible errors.
buildd@build:~/src/eole-debsums(master)$
</pre>
Si plus d’une branche contiennent le nom @lucid@, alors vous devez spécifier un nom plus long, par exemple:
<pre>
buildd@build:~/src/eole-debsums(master)$ git lucid
Error: More than one branch match 'lucid':
dist/ubuntu/lucid/master
dist/ubuntu/lucid/test
You should try adding a discriminent part.
For example: git package lucid/master
</pre>
Vous devez spécifier le discriminant que vous souhaitez:
<pre>
buildd@build:~/src/eole-debsums(master)$ git lucid/test
Do you want to merge 'master' into 'dist/ubuntu/lucid/test'?: y
Checkout 'lucid/test' master distribution branch 'dist/ubuntu/lucid/test': Switched to branch 'dist/ubuntu/lucid/test'
Pull from default remote: Already up-to-date.
Merge developpement from 'master': Already up-to-date.
Switch back to your developpement branch 'master'... Switched to branch 'master'
Push is not automatically done to avoid publishing possible errors.
</pre>
Vous pouvez spécifier à @git@ que vous souhaitez avoir des couleurs à l’affichage lorsque cela est possible en le configurant de la sorte:
<pre>
buildd@build:~/$ git config --global color.interactive auto
</pre>
h1. Environnement de compilation personnel
Il existe plusieurs outils afin de mettre en place des environnements de compilation personnels.
L’outil utilisé dans le projet "Debian":http://www.debian.org se nomme "sbuild":http://wiki.debian.org/sbuild.
Ce système peut se reposer sur un système de snapshot : on installe un système de base, propre, et la compilation se fait dans un snapshot temporaire de ce système.
Cela permet de lancer des compilations en parallèles au besoin.
Deux méthodes sont utilisables pour la mise en place des schroots avec snapshots :
* [[eole:GitPackagingSbuildLVM|avec LVM]]
* [[eole:GitPackagingSbuildBtrfs|avec le système de fichier btrfs]]
Lorsque les schroots sont en place et sbuild configuré par l’une des méthodes ci-dessus, la compilation d’un paquet peut se dérouler comme suit :
<pre>
buildd@build:~/src$ sudo apt-get install git-core git-buildpackage fakeroot build-essential debhelper cdbs
buildd@build:~/src$ git clone http://dev-eole.ac-dijon.fr/git/eole-debsums
buildd@build:~/src$ cd eole-debsums
buildd@build:~/src/eole-debsums$ git checkout -b dist/ubuntu/lucid/build origin/dist/ubuntu/lucid/master
buildd@build:~/src/eole-debsums$ git buildpackage --git-builder="sbuild -A -d eole-2.3-dev" --git-cleaner=/bin/true
</pre>
Ou si on souhaite minimiser les paquets à installer:
<pre>
buildd@build:~/src$ sudo apt-get install git-core git-buildpackage dpkg-dev
buildd@build:~/src$ git clone http://dev-eole.ac-dijon.fr/git/eole-debsums
buildd@build:~/src$ cd eole-debsums
buildd@build:~/src/eole-debsums$ git checkout -b dist/ubuntu/lucid/build origin/dist/ubuntu/lucid/master
buildd@build:~/src/eole-debsums$ git buildpackage --git-builder="dpkg-buildpackage -nc -d -S" --git-cleaner=/bin/true
buildd@build:~/src/eole-debsums$ sbuild -A -d eole-2.3-dev ../eole-debsums_20111207-eole1.dsc
</pre>
La génération d'un paquet source peut nécessiter [[GitBuildpackageConfig|un peu de configuration git-buildpackage]]
h1. Webographie
* La "politique Debian":http://www.debian.org/doc/devel-manuals#policy
* Une "introduction au packaging":http://www.debian.org/doc/devel-manuals#packaging-tutorial
* Les "meilleurs pratiques de packaging":http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.fr.html
* La "Référence du développeur Debian":http://www.debian.org/doc/manuals/developers-reference/index.fr.html
* La "documentation développeur Debian":http://www.debian.org/doc/devel-manuals
* "PackagingGuide/Python":https://wiki.ubuntu.com/PackagingGuide/Python
h1. Séparation du code et du packaging
Cela facilite le travail de tout le monde, aussi bien des développeurs que des packageurs.
De plus, il est ainsi plus facile de fournir le même code pour plusieurs distributions différentes, cela sera utile notamment lors du portage des applications sur "Precise Pangolin":http://fr.wikipedia.org/wiki/Liste_des_versions_d%27Ubuntu#Ubuntu_12.04_LTS_.28Precise_Pangolin.29
Le principe de base est le suivant :
* Tout ce qui est du ressort du packaging, c’est à dire tous les fichiers présents dans le répertoire @debian/@ pour les "paquets deb":http://fr.wikipedia.org/wiki/Deb, sont et doivent être modifiés dans la branche @dist/<VENDOR>/<DISTRIBUTION>/master@
* Tout le reste, c’est à dire le code, par exemple les dictionnaires, templates, scripts, agents zéphir, sont dans la branche publique adéquat, c’est a dire @master@ pour le code en développement, @2.2@ pour le code spécifique à la version @2.2@ d’EOLE.
Le workflow de base est le suivant:
# Je code dans une branche personnelle, par exemple @dad/mise-au-propre-du-makefile@
# Je teste, cela va de soi ;-)
# Je [[GitBonnesPratiques#Publication-du-développement|publie dans la branche publique]]
# J’intègre ces modifications à la branche de packaging afin de compiler un nouveau paquet
h2. Le développement dans @master@
Les développeurs gèrent cette branche [[GitBonnesPratiques|comme bon leur semble]], ils ne seront pas gênés par le packaging, en particulier les changements sur @debian/changelog@ à chaque compilation de paquet.
Les règles habituellement admises dans le monde du logiciel libre sur l’installation sont conseillées, par exemple :
* Écrire un "Makefile":http://fr.wikipedia.org/wiki/Makefile utilisant la variable @$(DEST)@ pour désigner la racine d’installation
* Utiliser les "autotools":http://fr.wikipedia.org/wiki/Autotools pour permettre la configuration des différents répertoires d’installation
L’idéal, en tant que développeur, peut être de pouvoir cloner la branche master sur une machine de test et de lancer les commandes :
# @make@ : pour compiler ce qui est compilable
# @make install@ : pour installer les fichiers et faire les tests
# @make uninstall@ : pour nettoyer ce qui a été installé
La branche @master@ étant la branche publique des derniers développements, il est utile d’[[GitTagging|étiqueter]] des états techniques utilisables et/ou à tester.
h2. Le packaging dans @dist/<VENDOR>/<DISTRIBUTION>/master@
Le packaging se compose de deux parties :
# Le code dit « upstream »
# Le code permettant de « faire le paquet », c’est à dire le contenu du répertoire @debian/@ pour les "paquets deb":http://fr.wikipedia.org/wiki/Deb.
h3. La première fois, c’est toujours la plus difficile
Un outil est disponible pour préparer le packaging d’un logiciel: "dh-make":http://packages.qa.debian.org/d/dh-make.html, son utilisation est plutôt simple.
# On récupère un projet :
<pre>
buildd@build:~/src/$ git clone http://dev-eole.ac-dijon.fr/git/eole-debsums && cd eole-debsums
</pre>
# On créé une branche de packaging :
<pre>
buildd@build:~/src/eole-debsums(master)$ git checkout -b dist/ubuntu/lucid/master
</pre>
# On créer un packaging de base :
<pre>
buildd@build:~/src/eole-debsums(dist/ubuntu/lucid/master)$ dh_make -c <LICENCE> -p eole-debsums_<VERSION> --createorig
[...] # Répondre aux questions
</pre>
# On ajoute ce packaging au "stagging area":http://progit.org/book/fr/ch2-2.html
<pre>
buildd@build:~/src/eole-debsums(dist/ubuntu/lucid/master)$ git add debian
</pre>
# On commit ce premier packaging, cela fait un point de départ même s’il n’est pas utilisable
<pre>
buildd@build:~/src/eole-debsums(dist/ubuntu/lucid/master)$ git commit -m "Debianisation du projet par dh_make" # Ne pas utiliser -m et faire un vrai message de log
</pre>
À partir de là il faut éditer les fichiers présents dans le répertoire @debian/@, principalement :
* @debian/control@ :
** Faire attention au mainteneur ;
** Faire attention à l’architecture cible : "any" pour des binaires (i386/amd64), "all" pour les paquets indépendant de l’architecture matérielle (documentation, scripts perl, …)
** Faire attention à la version de la "Debian policy":http://www.debian.org/doc/debian-policy utilisée, 3.8.2 sur Lucid ;
** Faire attention à la version de debhelper, @>= 7.4@ sur Lucid ;
** Mettre une description, courte et longue, les métas paquets "doivent":http://lintian.debian.org/tags/empty-binary-package.html utiliser une des expressions "metapackage," "dummy," "dependency package," "empty package," ou "virtual package" dans la description longue
* @debian/compat@ : utiliser 7 pour Lucid
* @debian/copyright@.
Supprimer l’extention @.ex@ ou @.EX@ des fichiers qui seront utiles et les modifier.
Des informations sur le packaging sont disponibles dans la "documentation Debian":http://www.debian.org/doc/devel-manuals
# On commence par une "introduction au packaging":http://www.debian.org/doc/devel-manuals#packaging-tutorial
# La "politique Debian":http://www.debian.org/doc/devel-manuals#policy est la référence sur les obligations que doivent suivre les paquets Debian
# Un chapitre sur les "meilleurs pratiques de packaging":http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.fr.html est disponible dans la "Référence du développeur Debian":http://www.debian.org/doc/manuals/developers-reference/index.fr.html
Nous fournissons aussi un petit [[EoleDebianPackaging|recueil de packaging EOLE]]
h3. Mise à jour du packaging
La mise à jour du packaging ne requiert pas grand chose par rapport à la création d’un nouveau paquet:
# On se place dans la branche de packaging voulu
# On modifie les fichiers dans le répertoire @debian/@ en fonction des besoins
# On publie ces modifications
# On compile un paquet, ou pas
h3. Nouveau paquet, sans modification du packaging
Afin de faire un paquet, il faut intégrer la branche de développement souhaitée, par exemple:
# On passe sur la branche de packaging :
<pre>buildd@build:~/src/eole-debsums(master)$ git checkout dist/ubuntu/lucid/master</pre>
# On intègre les modifications faites par les autres (et eolepack) :
<pre>buildd@build:~/src/eole-debsums(dist/ubuntu/lucid/master)$ git pull</pre>
# On intègre nos modifications :
<pre>buildd@build:~/src/eole-debsums(dist/ubuntu/lucid/master)$ git merge master</pre>
# On envoi sur le dépôt central pour eolepack :
<pre>buildd@build:~/src/eole-debsums(dist/ubuntu/lucid/master)$ git push</pre>
# On se replace sur la branche de développement pour nos futures modifications
<pre>buildd@build:~/src/eole-debsums(dist/ubuntu/lucid/master)$ git checkout master</pre>
# On compile un nouveau paquet, ou pas
NB: La branche par défaut dans eolepack est modifiée pour être @dist/ubuntu/lucid/master@.
h4. Aide à la console (aka helper bash)
Un petit script @bash@ (attachment:git-package) peut-être utilisé afin d’automatiser la procédure, il suffit de le mettre dans un répertoire du @PATH@, comme @/usr/local/bin@ et il sera pris automatiquement en compte par git:
<pre>
buildd@build:~/src/eole-debsums(master)$ git package lucid
Do you want to merge 'master' into 'dist/ubuntu/lucid/master'?: y
Checkout 'lucid' master distribution branch 'dist/ubuntu/lucid/master': Switched to branch 'dist/ubuntu/lucid/master'
Pull from default remote: Already up-to-date.
Merge developpement from 'master': Already up-to-date.
Switch back to your developpement branch 'master'... Switched to branch 'master'
Push is not automatically done to avoid publishing possible errors.
buildd@build:~/src/eole-debsums(master)$
</pre>
Et comme c’est connu que les informaticiens sont fainéants (enfin seulement les bons ;-)), il est possible de saisir encore moins de caractères en se faisant un alias dans git (pas nécessaire de le faire dans le shell):
<pre>
buildd@build:~/src/eole-debsums(master)$ git config --global alias.lucid 'package lucid'
</pre>
Ensuite, il n’y a plus qu’a l’utiliser:
<pre>
buildd@build:~/src/eole-debsums(master)$ git lucid
Do you want to merge 'master' into 'dist/ubuntu/lucid/master'?: y
Checkout 'lucid' master distribution branch 'dist/ubuntu/lucid/master': Switched to branch 'dist/ubuntu/lucid/master'
Pull from default remote: Already up-to-date.
Merge developpement from 'master': Already up-to-date.
Switch back to your developpement branch 'master'... Switched to branch 'master'
Push is not automatically done to avoid publishing possible errors.
buildd@build:~/src/eole-debsums(master)$
</pre>
Si plus d’une branche contiennent le nom @lucid@, alors vous devez spécifier un nom plus long, par exemple:
<pre>
buildd@build:~/src/eole-debsums(master)$ git lucid
Error: More than one branch match 'lucid':
dist/ubuntu/lucid/master
dist/ubuntu/lucid/test
You should try adding a discriminent part.
For example: git package lucid/master
</pre>
Vous devez spécifier le discriminant que vous souhaitez:
<pre>
buildd@build:~/src/eole-debsums(master)$ git lucid/test
Do you want to merge 'master' into 'dist/ubuntu/lucid/test'?: y
Checkout 'lucid/test' master distribution branch 'dist/ubuntu/lucid/test': Switched to branch 'dist/ubuntu/lucid/test'
Pull from default remote: Already up-to-date.
Merge developpement from 'master': Already up-to-date.
Switch back to your developpement branch 'master'... Switched to branch 'master'
Push is not automatically done to avoid publishing possible errors.
</pre>
Vous pouvez spécifier à @git@ que vous souhaitez avoir des couleurs à l’affichage lorsque cela est possible en le configurant de la sorte:
<pre>
buildd@build:~/$ git config --global color.interactive auto
</pre>
h1. Environnement de compilation personnel
Il existe plusieurs outils afin de mettre en place des environnements de compilation personnels.
L’outil utilisé dans le projet "Debian":http://www.debian.org se nomme "sbuild":http://wiki.debian.org/sbuild.
Ce système peut se reposer sur un système de snapshot : on installe un système de base, propre, et la compilation se fait dans un snapshot temporaire de ce système.
Cela permet de lancer des compilations en parallèles au besoin.
Deux méthodes sont utilisables pour la mise en place des schroots avec snapshots :
* [[eole:GitPackagingSbuildLVM|avec LVM]]
* [[eole:GitPackagingSbuildBtrfs|avec le système de fichier btrfs]]
Lorsque les schroots sont en place et sbuild configuré par l’une des méthodes ci-dessus, la compilation d’un paquet peut se dérouler comme suit :
<pre>
buildd@build:~/src$ sudo apt-get install git-core git-buildpackage fakeroot build-essential debhelper cdbs
buildd@build:~/src$ git clone http://dev-eole.ac-dijon.fr/git/eole-debsums
buildd@build:~/src$ cd eole-debsums
buildd@build:~/src/eole-debsums$ git checkout -b dist/ubuntu/lucid/build origin/dist/ubuntu/lucid/master
buildd@build:~/src/eole-debsums$ git buildpackage --git-builder="sbuild -A -d eole-2.3-dev" --git-cleaner=/bin/true
</pre>
Ou si on souhaite minimiser les paquets à installer:
<pre>
buildd@build:~/src$ sudo apt-get install git-core git-buildpackage dpkg-dev
buildd@build:~/src$ git clone http://dev-eole.ac-dijon.fr/git/eole-debsums
buildd@build:~/src$ cd eole-debsums
buildd@build:~/src/eole-debsums$ git checkout -b dist/ubuntu/lucid/build origin/dist/ubuntu/lucid/master
buildd@build:~/src/eole-debsums$ git buildpackage --git-builder="dpkg-buildpackage -nc -d -S" --git-cleaner=/bin/true
buildd@build:~/src/eole-debsums$ sbuild -A -d eole-2.3-dev ../eole-debsums_20111207-eole1.dsc
</pre>
La génération d'un paquet source peut nécessiter [[GitBuildpackageConfig|un peu de configuration git-buildpackage]]
h1. Webographie
* La "politique Debian":http://www.debian.org/doc/devel-manuals#policy
* Une "introduction au packaging":http://www.debian.org/doc/devel-manuals#packaging-tutorial
* Les "meilleurs pratiques de packaging":http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.fr.html
* La "Référence du développeur Debian":http://www.debian.org/doc/manuals/developers-reference/index.fr.html
* La "documentation développeur Debian":http://www.debian.org/doc/devel-manuals
* "PackagingGuide/Python":https://wiki.ubuntu.com/PackagingGuide/Python