• Debian packaging pour EOLE 2.4
  • Introduction
  • debian/changelog
    • Numérotation des paquets
  • debian/source/format
    • Il est interdit de modifier les sources dans le packaging
    • Il est possible de modifier les sources dans le packaging ou il n’y a pas de sources upstream
  • debian/gbp.conf
  • debian/control
    • Paquets sources et binaires python
  • debian/rules
    • Pour tous
    • Pour paquet python
    • Outrepasser le comportement par défaut des debhelpers
  • debian/compat
  • debian/copyright

Debian packaging pour EOLE 2.4¶

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

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.

Numérotation des paquets¶

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

1. 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 et se reposer sur l’utilisation de tag 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:

<UPSTREAM VERSION>-<DEBIAN PACKAGE RELEASE>

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

debian/source/format¶

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

1. Qui a la responsabilité de l’incrémentation du numéro de version ;
2. Est-il permis que la branche dite upstream (chez EOLE, la branche master) soit vide ;
3. 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.

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:

# 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

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 :

3.0 (quilt)

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:

# 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

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

3.0 (native)

debian/gbp.conf¶

Si ce n’est pas déjà fait, il faut créer le fichier de configuration de git-buildpackage afin de déterminer le format des tags de version debian:

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

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

debian/control¶

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>

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.

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}

debian/rules¶

Pour tous¶

#!/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
# export DH_OPTIONS=-v

%:
    dh $@

Pour paquet python¶

#!/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
# export DH_OPTIONS=-v

%:
    dh $@ --with python2

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 :

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

.PHONY: dh_<COMMAND>

Cela permet, par exemple, de nommer un script d’init installé automatiquement différemment du paquet qui le fourni, comme pour 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.

debian/compat¶

9

debian/copyright¶

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