MigrationAppliEnvole4 » Historique » Version 76
Version 75 (Lionel Morin, 18/03/2014 11:46) → Version 76/95 (Lionel Morin, 18/03/2014 14:08)
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)*
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 => *eole-cdt 4.9.4.4-eole2-1*
h3. Dokuwiki
OK => *eole-dokuwiki (2012-01-25a-eole2-4)*
MAJ => *eole-dokuwiki_2012-01-25a-eole4-1*
h3. FluxBB
OK => *eole-fluxbb (1.5.3.eole1-1)*
MAJ => *eole-fluxbb 1.5.3.eole2-2*
h3. Gepi
OK => *eole-gepi (1.6.3-eole2-1)*
MAJ => *eole-gepi 1.6.3-eole4-1*
h3. GRR
OK => *eole-grr (1.9.7e-eole1-1)*
MAJ => *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 => *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 => *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)
h3. Webcalendar
OK => ?
h3. WordPress
OK => *eole-worpress (3.6.1-eole1-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@.
{{>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)*
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 => *eole-cdt 4.9.4.4-eole2-1*
h3. Dokuwiki
OK => *eole-dokuwiki (2012-01-25a-eole2-4)*
MAJ => *eole-dokuwiki_2012-01-25a-eole4-1*
h3. FluxBB
OK => *eole-fluxbb (1.5.3.eole1-1)*
MAJ => *eole-fluxbb 1.5.3.eole2-2*
h3. Gepi
OK => *eole-gepi (1.6.3-eole2-1)*
MAJ => *eole-gepi 1.6.3-eole4-1*
h3. GRR
OK => *eole-grr (1.9.7e-eole1-1)*
MAJ => *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 => *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 => *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)
h3. Webcalendar
OK => ?
h3. WordPress
OK => *eole-worpress (3.6.1-eole1-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@.