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

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 après correction de #5922 

h3. phpMyAdmin

*OK*

h3. Piwik

_Non testé_

h3. SquirrelMail

Ne sera pas supporté

h3. CDC

_Non testé_

h3. Cdt

KO : utilise eole-envole-tools

h3. Dokuwiki

OK

h3. FluxBB

OK

h3. Gepi

KO (problème avec les templates encodée en ISO-8859)

h3. -Gibii-

h3. GRR

KO : utilise eole-envole-tools

h3. Jappix

KO (_CAS Authentication failed!_)

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

h3. Roundcube

KO : #5871

h3. SAP

_Non testé_

h3. SPIP Eva

OK après résolution de #5876

h3. Taskfreak

OK mais problème d'encodage sur 2.4 !

h3. Webcalendar

KO : utilise eole-envole-tools + #5879

h3. WordPress

OK après correction de #5880

h3. Zarafa

_Non testé_

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