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

• Migration d'une application Envole vers la version EOLE 2.4 (ébauche)
  • Nouvelle organisation du dépot git
    • Description des branches
    • Étapes de migration d'un dépot
  • Modification des dicos
  • Modification des templates
  • Modification des scripts shell
    • CreoleGet
    • CreoleRun
  • Problèmes spécifiques
    • Problème de connexion aux bases MySQL #5633
  • État des lieux application par application
    • Ajaxplorer
    • phpMyAdmin
    • Piwik
    • Cdt
    • Dokuwiki
    • FluxBB
    • Gepi
    • GRR
    • Jappix
    • Moodle
    • Moodle BigBlueButton
    • Moodle Référentiel
    • Piwigo
    • Roundcube
    • SAP
    • SPIP Eva
    • Taskfreak
    • Webcalendar
    • WordPress
    • Zarafa
    • CDC
    • SquirrelMail
    • Gibii
  • Compilation en EOLE 2.4

Pour faciliter le travail de packaging, il est nécessaire de "skeletoriser" le dépot 2.3 pour le transformer en dépot 2.4.

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.

Description des branches¶

Sources originales	Sources modifiées pour Envole	Ajouts EOLE	Packaging
upstream	=> patch	=> 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.

Étapes de migration d'un dépot¶

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

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

2. Supprimer tout le contenu autre que le dossier src :
   

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

3. Commiter
   

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

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

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

5. Supprimer toutes les sources du dossier src :
   

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

6. Télécharger les sources de l'application depuis le site d'origine (fichier tar.gz)
7. Décompresser les sources dans le dossier src et renommer le dossier selon la nomenclature skeletor :
   

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

8. Commiter
   

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

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

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

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

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

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.

Modification des dicos¶

Normalement il n'y a rien à changer.

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)

Modification des scripts shell¶

CreoleGet¶

.ParseDico
echo $mavariable

est remplacé par :

echo $(CreoleGet mavariable)

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

echo $(CreoleGet lamaster.lesclave)

=> 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 :

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

CreoleRun¶

./usr/share/eole/FonctionsEoleNg
RunCmd "ma -commande" conteneur

est remplacé par :

CreoleRun "ma -commande" conteneur

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

Problèmes spécifiques¶

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

État des lieux application par application¶

Ajaxplorer¶

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

phpMyAdmin¶

OK => eole-phpmyadmin (2.4.0-6)

Piwik¶

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

Cdt¶

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

Dokuwiki¶

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

FluxBB¶

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

Gepi¶

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

GRR¶

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

Jappix¶

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

Moodle¶

KO : script posttemplate/12-moodle non compatible 2.4 (#5964)

Moodle BigBlueButton¶

Non testé

Moodle Référentiel¶

Non testé

Piwigo¶

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

Roundcube¶

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

SAP¶

Non testé

SPIP Eva¶

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

Taskfreak¶

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

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

Webcalendar¶

KO : utilise eole-envole-tools + #5879

WordPress¶

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

Zarafa¶

Non testé

CDC¶

Non testé

SquirrelMail¶

Ne sera pas supporté

Gibii¶

N'est déjà plus supporté en 2.3

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.