EOLE

{{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 longe, 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 disponible 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

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>

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