Envole

h1. Migration d'une application Envole vers la version EOLE 2.4 (ébauche)

{{>toc}}

Pour faciliter le travail de packaging, il est nécessaire de [[eole-skeletor:Doc-geting-started| "skeletoriser"]] le dépot 2.3 pour le [[eole:EoleDebianPackaging24| transformer en dépot 2.4]].

h2. Nouvelle organisation du dépot git

Une nouvelle organisation globale des dépots git pour Envole est mise en place et sera commune pour 2.3 et 2.4.

h3. Description des branches

|_.Sources originales |_.Sources modifiées pour Envole |_.Ajouts EOLE  |_.Packaging      |

|/2=.upstream         |/2=.=>  patch                   |/2=.=>  master |=>  packaging 2.3|

|                                                                       =>  packaging 2.4|

* la branche _*upstream*_ ne contient que les sources originales de l'application et sert de référence pour la branche patch

* la branche _*patch*_ contient les sources patchées pour envole (il y a ici possibilité de générer un paquet envole-<nom_appli>)

* la branche _*master*_ est commune en 2.3 et 2.4 (sous réserve de rester compatible) et comporte, en plus des sources, tous les ajouts EOLE (templates, dicos, scripts, sql, password...)

* les branches de *_packaging_*, une par version

Les flèches "=>" représentent le sens de merge des branches. (*uptream* est mergée dans *patch* qui est mergée dans *master* qui est mergée dans *packaging*)

Il est important de bien respecter ce sens de merge au risque de perdre des fichiers et rendre le dépot git inutilisable.

h3. Étapes de migration d'un dépot

# Créer la branche "patch" à partir de "master" :

<pre>

user:~/depot/monappli (master)$ git checkout -b patch

</pre>

# Supprimer tout le contenu autre que le dossier src :

<pre>

user:~/depot/monappli (patch)$ git rm -r dicos/* sso/* tmpl/* sql/* Makefile eole.mk apps.mk # etc...

</pre>

# Commiter

<pre>

user:~/depot/monappli (patch)$ git commit -m "Suppression de la partie EOLE"

</pre>

# Créer la branche "upstream" à partir de "patch" :

<pre>

user:~/depot/monappli (patch)$ git checkout -b upstream

</pre>

# Supprimer toutes les sources du dossier src :

<pre>

user:~/depot/monappli (upstream)$ git rm -r src/monappli-1.0.0/* src/plugins-1.0.0/* # etc...

</pre>

# Télécharger les sources de l'application depuis le site d'origine (fichier tar.gz)

# Décompresser les sources dans le dossier src et renommer le dossier selon la nomenclature skeletor :

<pre>

user:~/depot/monappli (upstream)/src$ tar -xvzf ~/monappli-1.0.0.tar.gz 

user:~/depot/monappli (upstream)$ mv monappli monappli-1.0.0

</pre>

# Commiter

<pre>

user:~/depot/monappli (upstream)$ git commit -m "Mise en place des sources 1.0.0"

</pre>

# Merge de la branche "upstream" dans "patch" (avec une option pour conserver les fichiers de "patch") :

<pre>

user:~/depot/monappli (upstream)$ git checkout patch

user:~/depot/monappli (patch)$ git merge -s ours upstream

</pre>

# Merge de la branche "patch" dans "master" (avec une option pour conserver les fichiers de "master") :

<pre>

user:~/depot/monappli (patch)$ git checkout master

user:~/depot/monappli (master)$ git merge -s ours patch

</pre>

Les options de merge étant conservées, les prochains merge pourront se faire avec un simple "@git merge ...@".

Il est important de bien respecter le flux de merge des branches (représenté par "=>" dans le tableau au-dessus).

Pour simplifier ce travail, on pourra reporter la création de la branche "upstream" et l'effectuer à l'occasion d'une montée de version de l'application.

h2. Modification des dicos

Normalement il n'y a rien à changer.

h2. Modification des templates

Certaines variables souvent utilisées dans Envole ont changé de nom.

|_.Nom en 2.3                  |_.Nouveau nom en 2.4          |

|adresse_ip_annuaire           |container_ip_annuaire         |

|adresse_ip_fichier            |container_ip_fichier          |

|adresse_ip_mail               |container_ip_mail             |

|adresse_ip_mysql              |container_ip_mysql            |

|adresse_ip_web                |container_ip_web              |

*=> Ces variables peuvent être rajoutées en 2.4 pour une rétro-compatibilité (#5701)*

h2. Modification des scripts shell

h3. CreoleGet

<pre>

.ParseDico

echo $mavariable

</pre>

est remplacé par :

<pre>

echo $(CreoleGet mavariable)

</pre>

ATTENTION : à ce jour, pour accéder à une variable esclave, il faut connaître la variable maître :

<pre>

echo $(CreoleGet lamaster.lesclave)

</pre>

*=> Il est possible de tester la présence de ParseDico avant de le lancer et ainsi faire en sorte d'avoir des scripts communs en 2.3 et en 2.4*

Code à confirmer :

<pre>

if type -p ParseDico &> /dev/null; then

    .ParseDico

else

    # initialisation des variables utilisées

    adresse_ip_br0=$(CreoleGet adresse_ip_br0)

fi

echo $adresse_ip_br0

</pre>

h3. CreoleRun

<pre>

./usr/share/eole/FonctionsEoleNg

RunCmd "ma -commande" conteneur

</pre>

est remplacé par :

<pre>

CreoleRun "ma -commande" conteneur

</pre>

*=> Il est possible d'émuler la commande RunCmd en 2.4 ou bien émuler CreoleRun en 2.3.*

h2. Problèmes spécifiques

h3. Problème de connexion aux bases MySQL #5633

Pour y remédier temporairement, on peut mettre "localhost" à la place de "127.0.0.1" (penser à la fois aux fichiers sql et aux fichiers de config php).

h2. État des lieux application par application

h3. Ajaxplorer

OK => *eole-ajaxplorer (4.2.3-eole3-1)*

MAJ Envole 3.3.7 => *eole-ajaxplorer 4.2.3-eole4-1*

h3. phpMyAdmin

OK => *eole-phpmyadmin (2.4.0-6)*

h3. Piwik

paquet *eole-piwik (1.12-eole1-1)* à déboguer ...

h3. Cdt

OK => *eole-cdt (4.9.3.7-eole1-2)*

MAJ Envole 3.3.7 => *eole-cdt 4.9.4.4-eole2-1*

h3. Dokuwiki

OK => *eole-dokuwiki (2012-01-25a-eole2-4)*

MAJ Envole 3.3.7 => *eole-dokuwiki_2012-01-25a-eole4-1*

h3. FluxBB

OK => *eole-fluxbb (1.5.3.eole1-1)*

MAJ Envole 3.3.7 => *eole-fluxbb 1.5.3.eole2-2*

h3. Gepi

OK => *eole-gepi (1.6.3-eole2-1)*

MAJ Envole 3.3.7 => *eole-gepi 1.6.3-eole4-1*

h3. GRR

OK => *eole-grr (1.9.7e-eole1-1)*

MAJ Envole 3.3.7 => *eole-grr 1.9.7e-eole2-1*

h3. Jappix

OK => *eole-jappix (0.9.0-eole1-1)*

h3. Moodle

KO : script _posttemplate/12-moodle_ non compatible 2.4 (#5964)

h3. Moodle BigBlueButton

_Non testé_

h3. Moodle Référentiel

_Non testé_

h3. Piwigo

OK => *eole-piwigo (2.3.5-eole2-1)*

MAJ Envole 3.3.7 => *eole-piwigo 2.3.5-eole3-1*

_Problème au moment du test car piwik n'était pas installé (dans /var/www/html/piwigo/include/page_header.php +76 : require_once sur une lib piwik)_

h3. Roundcube

OK => *eole-roundcube (0.9.1-eole2-1)*

h3. SAP

_Non testé_

h3. SPIP Eva

OK => *eole-spipeva (3.0.10-eole1-1)*

MAJ Envole 3.3.7 => *eole-spipeva 3.0.10-eole4-1*

h3. Taskfreak

OK => *eole-taskfreak (0.6.4-eole1-1)*

mais problème d'encodage sur 2.4 (#6723)

MAJ Envole 3.3.7 => *eole-taskfreak 0.6.4-eole2-1*

h3. Webcalendar

OK => ?

h3. WordPress

OK => *eole-worpress (3.6.1-eole1-1)*

MAJ Envole 3.3.7 => *eole-wordpress 3.6.1-eole3-1*

h3. Zarafa

_Non testé_

h3. CDC

_Non testé_

h3. -SquirrelMail-

_Ne sera pas supporté_

h3. -Gibii-

_N'est déjà plus supporté en 2.3_

h2. Compilation en EOLE 2.4

Voir : http://dev-eole.ac-dijon.fr/projects/eole/wiki/PrepareEOLE24

*La nouvelle procédure de compilation de paquet se base sur les noms de tag de la branche master.*

Donc à chaque modification du paquet il faudra taguer cette version avec un numéro supérieur à la précédente.

Pour différencier les versions upstream et les versions modifiées par EOLE, on pourra taguer la branche upstream avec "upstream/x.y.z" (où x.y.z est son numéro de version) et les releases EOLE (branche master) avec "release/x.y.z-eoleX" (où X est le numéro de la version EOLE).

Pour connaitre le dernier tag utilisé afin de l'incrémenter, tapez la commande @git describe@.