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 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>