[AlternC-dev] questions pour anarcat

Retour à l'archive de la liste
Le site d'AlternC
Google Custom Search

The Anarcat anarcat at anarcat.ath.cx
Mer 2 Juin 16:16:07 CEST 2004


On Wed Jun 02, 2004 at 09:32:05AM +0200, Benjamin Sonntag wrote:
> Salut,
> 
> 2 questions pour anarcat suite à tes "commits" furieux de la nuit 
> dernière ;)

(aparté: c'est dommage que je fasse mes commits pendant vos nuits. :)

> 1. Au sujet du script d'upgrade
> Sommes-nous bien d'accord sur le fait qu'il ne faut pas séparer les 
> scripts d'upgrade par LANGUAGE mais juste mettre à disposition
> - un shell script [version].sh
> - un dossier [version]/ dans lequel on trouvera les fichiers de tout 
> type dont [version].sh a besoin
> exemple pour 0.9.1 :
>    0.9.1.sh
>    0.9.1/migration_ldap.php
>    0.9.1/migration_ldap.sql
> Ca me paraît plus pérenne comme solution d'upgrade à terme ...

Bof... Ça me dérange pas vraiment, mais disons que j'ai pas
particulièrement envie de faire des courbettes pour faire fonctionner ça
comme ça.

Sûr, on pourrait ajouter la fonction "répertoire": si <version> est un
répertoire, on entre dedans et on "exécute" (selon l'extension) les
fichiers qu'il y a dedans, en ordre.

Ainsi, si on veut avoir des scripts ordonnés, on fait un répertoire
"0.9.1", avec dedans:

0.9.1/01_migration_ldap.php
0.9.1/02_migration_ldap.sql

, par exemple.

Sinon, il y a plein de problèmes, évidemment, avec mon approche. La
première est qu'il est impossible de connaitre la version que l'on
installe dans le postinst, à moins de l'hardcoder dedans au build du
package, ce qui veut dire que si un script est packagé, mais est destiné
à une version future, il va être exécuté quand même (voir le README).
Pas un gros problème en soit.

Ensuite, l'ordre d'exécution des scripts est *.sh *.php *.sql (ou
qqchose du genre).

Ce qui signifie qu'ils ne s'éxécutent pas *nécessairement* dans l'ordre
que l'on pense, puisque le facteur de tri n'est *pas* dpkg
--compare-versions. Je n'ai pas d'exemple de mauvais comportement, mais
c'est sûr qu'il doit y en avoir. :(

J'ignore comment régler ce problème, et si c'est vraiment si grave que
ça. :)

> 2. Au sujet de local.sh / alternc.conf merci de confirmer que :
>    - alternc.conf disparaît

Yé! Oui enfin!

>    - local.sh est conservé, il possède une syntaxe "shell" et 
> contiendra les variables demandées par debconf.

Tout à fait. J'ai d'ailleurs amorcé un peu de travail en ce sens de le
fichier config, ce qui t'a probablement amené à poser ces questions,
j'imagine. :)

Le manuel debconf-devel est très instructif sur ceci: il a des bons
exemples sur comment implanter l'écriture du fichier dans le postinst.

>    - alternc.install utilisera les données de local.sh pour -appliquer 
> de manière idempotente- les modifs demandées.

Exactement, on est tout à fait d'accords.

A.
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: non disponible
Type: application/pgp-signature
Taille: 187 octets
Desc: non disponible
URL: <http://lists.alternc.org/arch/dev/attachments/20040602/07edebea/attachment.pgp>


Plus d'informations sur la liste de diffusion Dev