AlternC/install/upgrades/README

Fonctionnement des scripts de mise-<2D>-jour d'AlternC
===================================================

/!\ ATTENTION /!\
Votre script DOIT etre num<75>rot<6F> sur trois chiffres, pas plus, pas moins.
Donc : 
 1.0.1.sql -> OK
 1.0.2~1.sql -> OK
 1.0.2~a.sql -> OK
 1.0.2.5.sql -> PAS OK
 1.0.sql -> PAS OK

Sinon, ca sera dans n'importe quel ordre.


Il a <20>t<EFBFBD> d<>cid<69> que des mises-<2D>-jour pourront <20>tre "accroch<63>es" <20>
certaines versions en les mettant dans le dossier upgrades. Lors de
l'installation d'un paquet, un script (upggrade_check.sh) examine ce
dossier et applique les mises-<2D>-jour n<>cessaires, en se basant sur les
num<EFBFBD>ros de version. Les scripts consid<69>r<EFBFBD>s sont ceux termin<69>s par
.sql, .sh ou .php, et sont interpr<70>t<EFBFBD>s avec mysql, /bin/sh ou php
respectivement, et dans cet ordre.

Pour <20>tre consid<69>r<EFBFBD>, le script doit donc avoir un nom conforme,
c'est-<2D>-dire sous la forme \d(\.\d+)* (en expression r<>guli<6C>re), par
exemple: 0.9.1.sh, 1.0.php, etc. De plus, le fichier est consid<69>r<EFBFBD>
seulement si la version avec laquelle il est nomm<6D> tombe entre la
version de d<>part et d'arriv<69>e du package.
Afin de forcer les scripts d'une m<>me version a ce lancer dans un ordre pr<70>cis,
on peut rajouter ~x avant l'extension du script o<> x est un charct<63>re alphanum<75>rique
([0-9][a-z]). Par exemple pour forcer un script d'upgrade php a s'executer avant
un autre, il suffit de le rennomer X.X.X~1.php et X.X.X~2.php

Voir ci-bas pour des exemples.

Description formelle du fonctionnement de upgrade_check.sh
----------------------------------------------------------

Soit un upgrade d'une version X <20> une version Y. Les fichiers du
dossier d'upgrade sont examin<69>s un <20> un. Pour chaque fichier dont le
nom N.php, N.sh ou N.sql est X >= N <= Y, le fichier est ex<65>cut<75> ou
pass<EFBFBD> <20> mysql, selon le cas appropri<72>. Les versions sont compar<61>es
avec dpkg --compare-versions.  Les scripts sont ex<65>cut<75>s dans cet
ordre: *.sql *.sh *.php.

Il est donc capital de nommer correctement ce fichier.

Ces scripts devront <20>tre idempotents, car ils peuvent <20>tre ex<65>cut<75>s <20>
plusieurs reprises, comme tous les scripts postinst et config.

(Note: en r<>alit<69>, on ne v<>rifie pas la condition N <= Y. On assume que
si le script est disponible, il est applicable <20> cette version. Ceci
signifie qu'il ne faut pas "packager" un script d'upgrade N dans un
package Y si N > Y. Exemple: ne pas inclure un script 1.0 dans un
package 0.9, car il sera ex<65>cut<75>, m<>me si la version install<6C>e est 1.0.)

Pour plus de d<>tails, consultez directement le script
../upgrade_check.sh, qui g<>re ces upgrades.

Mise en situation
-----------------

Exemple: 0.9.1 sera ex<65>cut<75> lors d'une mise <20> jour de 0.9 <20> 0.9.1 (ou
1.0), mais pas d'une mise <20> jour de 0.9.1 <20> 1.0.

Autre exemple: on proc<6F>de <20> une mise <20> jour de alternc-0.9-20031009 vers
alternc-0.9.1. On trouve le script upgrades/0.9.1.sh. Celui-ci est
ex<EFBFBD>cut<EFBFBD> car 0.9-20031009 >= 0.9.1 <= 0.9.1. Il serait aussi ex<65>cut<75> pour
une mise <20> jour vers 0.9.2, 1.0, etc.