EOLE

{{toc}}

h1. Gestion des paquets EOLE

h2. Environnement de compilation personel

Il existe plusieurs outils afin de mettre en place des environnements de compilation personels.

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 temporarire 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 snapshots :

* [[eole:GitPackagingSbuildLVM|avec LVM]]

* [[eole:GitPackagingSbuildBtrfs|avec le système de fichier btrfs]]

Lorsque les schroots sont en place et sbuild configuré, la compilation d’un paquet peut se dérouler comme suit :

<pre>

buildd@build:~$ sudo apt-get install git-core git-buildpackage fakeroot build-essential debhelper cdbs

buildd@build:~$ git clone http://dev-eole.ac-dijon.fr/git/eole-debsums

buildd@build:~$ cd eole-debsums

buildd@build:~$ git checkout -b dist/ubuntu/lucid/build origin/dist/ubuntu/lucid/master

buildd@build:~$ git buildpackage --git-builder="sbuild -A -d eole-2.3-dev" --git-cleaner=/bin/true

</pre>

h2. TODO Proposition de workflow

h3. Partie développeur

# Création d’un tag signé contenant un nouveau numéro de version

# Envoi du tag sur le dépôt central dev-eole

h3. Partie packageur

# Fusion de la branche développeur dans la branche de packaging

# Création d’un tag signé contenant le nouveau numéro de version basé sur celui du développeur

# Envoi du tag sur le dépôt central dev-eole

Cette partie peut être automatisée si un mapping existe entre les branches de développement et les branches de packaging.

Dans ce cas, on pourra vérifier la signature du développeur.

h3. Partie builder : gestion du source Debian

Le but de cette partie est de créer l’ensemble des fichiers sources Debian :

* @<PAQUET>_<VERSION SOURCE>.orig.tar.gz@    : Les sources non packagées (dans le répertoire @debian/@)

* @<PAQUET>_<VERSION DEBIAN>.debian.tar.gz@  : Le packaging des sources (le répertoire @debian/@)

* @<PAQUET>_<VERSION DEBIAN>.dsc@            : Description du paquet source Debian (doit être signé)

* @<PAQUET>_<VERSION DEBIAN>_source.changes@ : Description des changements (mixe entre l’entrée de @debian/changelog@ de cette version et le fichier @.dsc@)

# Vérification de la signature: si nok => suppression du tag + report + quit

# Checkout du tag == récup de la conf gbp.conf

# Checkout de la branche de build depuis le dernier tag de version Debian

# Merge du tag dans la branche de build

# Mise à jour de @debian/changelog@ :

  <pre>git-dch -a -R/-S debian/</pre>

# Ajout de @debian/changelog@ à l’index pour le prochain commit :

  <pre>git add debian/changelog</pre>

# Commit en utilisant le numéro de version du nouveau paquet :

  <pre>git commit -m "Nouveau paquet debian version: $(dpkg-parsechangelog | awk '/^Version/ {print $2}')"</pre>

# Construction du source debian et envoi sur un dépôt debian, sans faire de nettoyage, ni de vérification de dépendance:

  <pre>git buildpackage \

  --git-builder="dpkg-buildpackage -nc -d -S" \

  --git-postbuild='dput eole "${GBP_CHANGES_FILE}"'

  --git-cleaner=/bin/true</pre>

Cette partie peut être automatisée.

h3. Partie dépôt : gestion du source Debian

Cette partie peut être prise en charge automatiquement par "différente méthode":http://git.debian.org/?p=mirrorer/reprepro.git;a=blob_plain;hb=HEAD;f=docs/manual.html (section "Processing an incoming queue") :

* "cron":http://fr.wikipedia.org/wiki/cron

* "inotify":http://fr.wikipedia.org/wiki/Inotify

* "dput/dupload":http://www.debian.org/doc/manuals/maint-guide/upload.en.html

L’utilisation de @dput@ ou @dupload@ requiert de mettre en place une configuration et des autorisation pour chaque « uploader ».

La solution @inotify@ est le meilleur compromis :

* Ne requiert une configuration qu’à un endroit ;

* Prise en compte rapide des uploads.

h3. Partie builder : gestion des paquets binaires

La construction des paquets binaires est dépendante de l’"architecture":http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture déclarée dans @debian/control@ :

* Une seule fois pour les paquets déclarés avec l’architecture *all*

* Pour chaque architecture supportée pour les paquets déclarés avec l’architecture *any* ou une liste d’architecture

# Téléchargement des sources depuis le dépôt :

  <pre>apt-get source <PAQUET></pre>

# Construction du paquet en utilisant l’[[GitPackaging#Environnement de compilation personel|environnement de build]] correspondant à la distribution du paquet :

  <pre>cd <PAQUET>-<VERSION>/ \

  && sbuild -A -d $(dpkg-parsechangelog | awk '/^Distribution/ {print $2}')"</pre>

# Si build OK :

## On tag la version du paquet :

    <pre>git buildpackage --git-tag-only</pre>

## On envoi le tag sur le dépôt central :

    <pre>git push</pre>

## On supprime la branche de build qui est inutile

## On envoi le paquet sur le dépôt des paquets debian

h2. Webographie

* "PackagingGuide/Python":https://wiki.ubuntu.com/PackagingGuide/Python

* "Rebuildd":http://julien.danjou.info/software/rebuildd

* "Rebuildd on Debian":http://packages.qa.debian.org/rebuildd

* "Rebuildd for building a Private PPA on Ubuntu":http://inodes.org/2009/09/14/building-a-private-ppa-on-ubuntu/