EOLE

{{toc}}

h1. Debian packaging pour EOLE 2.4

h2. Introduction

Nous ne décrirons pas ici comment créer un paquet debian, mais
quelques règles utiles lors de la création d’un paquet debian pour
EOLE.

La principale cible de cette documentation est le packaging pour Ubuntu Precise Pangolin.

Le nouveau système de build des paquets apporte plus de souplesse :

* Possibilité de builder des paquets pour des architectures autre que _i386_ et _all_
* Utilisation du système de build pour construire des paquets de correctif pour les versions stables (plus besoin de télécharger l’ancien paquet, appliquer un patch, incrémenter le numéro de version et compiler à la main)
* Choix de la politique de numérotation des paquets

h2. debian/changelog

La grande nouveauté du système de build pour EOLE 2.4 est l’absence de fichier @debian/changelog@ dans la branche de packaging.

Ce dernier n’est créé et mis à jour que par le système de build lui-même et n’est jamais directement accessible aux développeurs/packageurs.

h3. Numérotation des paquets

L’absence du @debian/changelog@ impose une chose pour le premier paquet construit :

# Le premier paquet généré ne peut pas connaître son numéro de version par @debian/changelog@, il faut donc utiliser les mécanismes de "git-buildpackage":http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.man.git.dch.html et se reposer sur l’utilisation de "tag":http://gitimmersion.fr/lab_13.html pour déclarer les versions @upstream@

Le moyen mnémotechnique pour s’en souvenir est de connaître la forme d’un "numéro de paquet Debian":http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version:

<pre>
<UPSTREAM VERSION>-<DEBIAN PACKAGE RELEASE>
</pre>

* Toute modification du code nécessite une modification de la partie *@<UPSTREAM VERSION>@* ;
* Toute modification sur la branche de packaging qui n’implique aucun @merge@ de la branche @upstream@ (@master@ chez EOLE), modifie la partie *@<DEBIAN PACKAGE RELEASE>@*.

En français on pourrait le décrire par: on publie la version *@<DEBIAN PACKAGE RELEASE>@* du paquet debian de la version *@<UPSTREAM VERSION>@* du logiciel.

h2. debian/source/format

La valeur de ce paramètre découle des réponses à ces trois questions :

# Qui a la responsabilité de l’incrémentation du numéro de version ;
# Est-il permis que la branche dite @upstream@ (chez EOLE, la branche @master@) soit vide ;
# Est-il possible qu’entre deux paquets debian, il y ait des modifications de fichiers en dehors du répertoire @debian/@ sans nouveau tag de version @upstream@.

h3. Il est interdit de modifier les sources dans le packaging

Cela s’applique, chez Debian, aux paquets de logiciels « externes ».

Le paquet Debian ne doit pas contenir de modification du code source (tout ce qui est en dehors du répertoire @debian/@), sans qu’il y ait eu un nouveau numéro de version par les développeurs @upstream@.
La seul possibilité pour adapter le code source à la distribution est de faire un patch et de le disposer dans le répertoire @debian/patches/@.

Cas d’utilisation typique:

<pre>
# Mise à jour upstream
user:~/src/paquet (master)$ $EDITOR source_file.txt
user:~/src/paquet (master)$ git add source_file.txt
user:~/src/paquet (master)$ git commit -m "New source file"
user:~/src/paquet (master)$ git tag -s -m "New release 1.6" release/1.6
user:~/src/paquet (master)$ git push origin master release/1.6

# Mise à jour du packaging
user:~/src/paquet (master)$ git checkout dist/ubuntu/precise/master
user:~/src/paquet (dist/ubuntu/precise/master)$ git merge -m "New upstream release" release/1.6
user:~/src/paquet (dist/ubuntu/precise/master)$ $EDITOR debian/control # Par exemple mise à jour des dépendences
user:~/src/paquet (dist/ubuntu/precise/master)$ git add debian/conrol
user:~/src/paquet (dist/ubuntu/precise/master)$ git commit -m "Update of dependencies"
user:~/src/paquet (dist/ubuntu/precise/master)$ git tag -s -m "New build request for experimental" build/eole/eole-2.4/experimental
user:~/src/paquet (dist/ubuntu/precise/master)$ git push origin build/eole/eole-2.4/experimental
# Produit un paquet numéroté 1.6-1~1.gbpXXXX

# TOUT EST OK, on sort un nouveau paquet.
user:~/src/paquet (dist/ubuntu/precise/master)$ git tag -s -m "New build request for unstable" build/eole/eole-2.4/unstable
user:~/src/paquet (dist/ubuntu/precise/master)$ git push origin build/eole/eole-2.4/unstable
# Produit un paquet numéroté 1.6-1
</pre>

Les builds successifs de paquet sans merge d’une nouvelle version @upstream@

* @1.6-2@ pour le second build qui ne doit corriger que des erreurs de packaging ou avoir un patch pour @upstream@ dans @debian/patches@ ;
* @1.6-3@ pour le troisième build qui ne doit corriger que des erreurs de packaging ou avoir un patch pour @upstream@ dans @debian/patches@ ;

Ce comportement est celui part défaut avec la valeur de @debian/source/format@ :

<pre>
3.0 (quilt)
</pre>

h3. Il est possible de modifier les sources dans le packaging ou il n’y a pas de sources upstream

Les modifications de code source sont autorisées sur la branche de packaging sans nouveau tag upstream.
La branche upstream peut être complètement vide (cas des métapaquets de dépendances @*-pkg@)

Cas d’utilisation typique:

<pre>
# Premier tag upstream pour créer le fichier debian/changelog automatiquement
user:~/src/paquet (master)$ git tag -s -m "First release 1.0" release/1.0

# Premier paquet
user:~/src/paquet (master)$ git checkout -b dist/ubuntu/precise/master
user:~/src/paquet (dist/ubuntu/precise/master)$ $EDITOR debian/* # Création du packaging
user:~/src/paquet (dist/ubuntu/precise/master)$ git add debian/conrol
user:~/src/paquet (dist/ubuntu/precise/master)$ git commit -m "First package"
user:~/src/paquet (dist/ubuntu/precise/master)$ git tag -s -m "New build request for experimental" build/eole/eole-2.4/experimental
user:~/src/paquet (dist/ubuntu/precise/master)$ git push origin build/eole/eole-2.4/experimental
# Produit un paquet numéroté 1.6-1~1.gbpXXXX

# TOUT EST OK, on sort un nouveau paquet.
user:~/src/paquet (dist/ubuntu/precise/master)$ git tag -s -m "New build request for unstable" build/eole/eole-2.4/unstable
user:~/src/paquet (dist/ubuntu/precise/master)$ git push origin build/eole/eole-2.4/unstable
# Produit un paquet numéroté 1.6-1

# Mise à jour upstream
user:~/src/paquet (master)$ $EDITOR source_file.txt
user:~/src/paquet (master)$ git add source_file.txt
user:~/src/paquet (master)$ git commit -m "New source file"
user:~/src/paquet (master)$ git push origin master

# Mise à jour du packaging
user:~/src/paquet (master)$ git checkout dist/ubuntu/precise/master
user:~/src/paquet (dist/ubuntu/precise/master)$ git merge -m "New upstream release" master
user:~/src/paquet (dist/ubuntu/precise/master)$ $EDITOR debian/control # Par exemple mise à jour des dépendences
user:~/src/paquet (dist/ubuntu/precise/master)$ git add debian/conrol
user:~/src/paquet (dist/ubuntu/precise/master)$ git commit -m "Update of dependencies"
user:~/src/paquet (dist/ubuntu/precise/master)$ git tag -s -m "New build request for experimental" build/eole/eole-2.4/experimental
user:~/src/paquet (dist/ubuntu/precise/master)$ git push origin build/eole/eole-2.4/experimental
# Produit un paquet numéroté 1.6-2~1.gbpXXXX

# TOUT EST OK, on sort un nouveau paquet.
user:~/src/paquet (dist/ubuntu/precise/master)$ git tag -s -m "New build request for unstable" build/eole/eole-2.4/unstable
user:~/src/paquet (dist/ubuntu/precise/master)$ git push origin build/eole/eole-2.4/unstable
# Produit un paquet numéroté 1.6-2
</pre>

Ce comportement est possible avec la valeur de @debian/source/format@ :

<pre>
3.0 (native)
</pre>



h2. debian/gbp.conf

Si ce n’est pas déjà fait, il faut créer le fichier Fichier de configuration de "git-buildpackage":http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html afin de déterminer le format des tags de version debian:

<pre>
[DEFAULT]
debian-tag = debian/eole/2.4/%(version)s
</pre>

Cela évite qu’une même version upstream compilée pour plusieurs distributions se marche sur les pieds.



h2. debian/control

<pre>
Source: <package>
Section: <(admin|web|metapackages|...)>
Priority: optional
Maintainer: Équipe Eole <eole@ac-dijon.fr>
Build-Depends: debhelper (>= 9)
Standards-Version: 3.9.3
Homepage: http://eole.orion.education.fr/diff/
Vcs-Git: http://dev-eole.ac-dijon.fr/git/<package>
Vcs-Browser: http://dev-eole.ac-dijon.fr/projects/<package>/repository

Package: <package>
Architecture: all
Depends: ${misc:Depends}
Description: <MAX 72 CHARS>
<DESCRIPTION>
.
<PARAGRAPHE SEPARATED BY DOT>

Package: <package>-pkg
Section: metapackages
Architecture: all
Depends: <A PACKAGE>,
<ANOTHER PACKAGE>,
${misc:Depends}
Description: <MAX 72 CHARS>
<DESCRIPTION>
.
<PARAGRAPHE SEPARATED BY DOT>

Package: <package>-doc
Architecture: all
Description: <MAX 72 CHARS>
<DESCRIPTION>
.
<PARAGRAPHE SEPARATED BY DOT>

Package: <package>-tests
Architecture: all
Depends: <package>
Description: <MAX 72 CHARS>
<DESCRIPTION>
.
<PARAGRAPHE SEPARATED BY DOT>
</pre>

L’attribut _Section_ défini pour le paquet source est utilisé pour tous les paquets binaires ne définissant pas cet attribut.

Il est ainsi possible de spécifier qu’un paquet binaire est un méta-paquet (utilisé uniquement pour ces dépendances) en définissant @Section: metapackages@ comme pour @<package>-pkg@ dans l’exemple ci-dessus.

h3. Paquets sources et binaires python

Il faut ajouter :

* @Build-Depends@ du paquet source:
** @python-all@ pour les modules pure python
** @python-all-dev@ pour les modules nécessitant une compilation C.
* @Depends@ du/des paquet(s) binaire(s): @${python:Depends}@

h2. debian/rules

h3. Pour tous

<pre>
#!/usr/bin/make -f
# -*- makefile -*-
# Sample debian/rules that uses debhelper.
# This file was originally written by Joey Hess and Craig Small.
# As a special exception, when this file is copied by dh-make into a
# dh-make output file, you may use that output file without restriction.
# This special exception was added by Craig Small in version 0.37 of dh-make.

# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1

%:
dh $@
</pre>

h3. Pour paquet python

<pre>
#!/usr/bin/make -f
# -*- makefile -*-
# Sample debian/rules that uses debhelper.
# This file was originally written by Joey Hess and Craig Small.
# As a special exception, when this file is copied by dh-make into a
# dh-make output file, you may use that output file without restriction.
# This special exception was added by Craig Small in version 0.37 of dh-make.

# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1

%:
dh $@ --with python2
</pre>

h3. Outrepasser le comportement par défaut des debhelpers

L’utilisation de la cible implicite @%@ dans le fichier makefile @debian/rules@ ne permet pas de prendre en compte certains cas spécifiques comme passer des options aux commandes @dh_*@.

Pour outrepasser le comportement par défaut, il faut définir en plus des cibles d’écrasement :

<pre>
override_dh_<COMMAND>:
dh_<COMMAND> --opt1 --opt2

.PHONY: dh_<COMMAND>
</pre>

Cela permet, par exemple, de nommer un script d’init installé automatiquement différemment du paquet qui le fourni, comme pour project:zephir-client (voir zephir-client:source:debian/rules?rev=dist/ubuntu/lucid/master#L19)

Plus d’informations sont disponibles dans la "page de manuel de dh":http://manpages.ubuntu.com/manpages/precise/man1/dh.1.html.

h2. debian/compat

<pre>
9
</pre>

h2. debian/copyright

<pre>
Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: <package
Source: <UPSTREAM URL>

Files: *
Copyright: <YEAR1>,<YEAR2>,<YEAR3> <UPSTREAM AUTHOR NAME> <UPSTREAM AUTHOR EMAIL>
Copyright: <YEAR1>,<YEAR2>,<YEAR3> <UPSTREAM AUTHOR NAME> <UPSTREAM AUTHOR EMAIL>
License: GPL-3+

Files: debian/*
Copyright: <YEAR1>,<YEAR2>,<YEAR3> Équipe EOLE <eole@ac-dijon.fr>
License: CeCILL-2

License: CeCILL-2
This software is governed by the CeCILL-2 license under French law and
abiding by the rules of distribution of free software. You can use,
modify and or redistribute the software under the terms of the CeCILL-2
license as circulated by CEA, CNRS and INRIA at the following URL
"http://www.cecill.info";.
.
As a counterpart to the access to the source code and rights to copy,
modify and redistribute granted by the license, users are provided only
with a limited warranty and the software's author, the holder of the
economic rights, and the successive licensors have only limited
liability.
.
In this respect, the user's attention is drawn to the risks associated
with loading, using, modifying and/or developing or reproducing the
software by the user in light of its specific status of free software,
that may mean that it is complicated to manipulate, and that also
therefore means that it is reserved for developers and experienced
professionals having in-depth computer knowledge. Users are therefore
encouraged to load and test the software's suitability as regards their
requirements in conditions enabling the security of their systems and/or
data to be ensured and, more generally, to use and operate it in the
same conditions as regards security.
.
The fact that you are presently reading this means that you have had
knowledge of the CeCILL-2 license and that you accept its terms.
.
On EOLE systems, the complete text of the CeCILL-2 License can be found
in '/usr/share/common-licenses/CeCILL-2-en'.
</pre>