Zope 2.12 et Plone 4 via des paquets Debian ?

Quels sont les problèmes posés ?

S'il existait des paquets jusqu'à Zope 2.10, pourquoi n'y en a-t-il pas eu pour Zope 2.11, ni pour Zope 2.12 jusque là ?

La raison principale est que Zope, jusqu'au Zope 2.10, fournissait une archive (tarball) contenant l'ensemble du serveur. Cette archive était facile à packager comme n'importe quel autre programme.

À partir de Zope 2.12, seuls des eggs correspondant à différents morceaux de Zope sont diffusés, et c'est à easy_install, pip ou buildout de télécharger tous les morceaux et de les compiler ensemble.

Les solutions

Afin d'avoir un paquet Zope 2.12 sur Debian, une petite équipe s'est réunie lors d'un meeting sur IRC : composée de plusieurs développeurs Debian (Jonas Meurer, Michael Mulich, Arnaud Fontaine) et de moi-même (Gaël Le Mignot).

Afin d'arriver à un plan d'attaque, nous avons posé un certain nombre de contraintes :

• le paquet Debian doit supporter la coexistence de plusieurs versions majeures (comme Zope 2.12 et Zope 2.13) sur la même installation, comme c'était le cas jusqu'alors ;
• il ne doit pas gêner les paquets déjà existant des composants du Zope Toolkit (ztk), utilisés par certains framework ou par des programmes Python ;
• il doit permettre d'utiliser tous les modules Python natifs.

Le principal problème pour remplir tous ces objectifs a été que les composants du ztk ont tendance à changer assez vite, et ne respectent pas toujours la compatibilité ascendante.

La solution retenue a donc été de faire un snapshot des composants du ztk nécessaires pour une version donnée de Zope, et de mettre cette version dans un paquet versionné (par exemple zope2.12). Cette solution n'est pas totalement satisfaisante, mais est celle qui répond au plus grand nombre d'objectifs initiaux.

Le paquet actuel

Un paquet expérimental existait déjà, réalisé principalement par Michael Mulich. Ce paquet fonctionne en trois étapes :

1. Un script, à lancer manuellement pour construire le paquet, charge les composants d'une version de Zope donnée en utilisant pip, et fabrique une tarball avec.

2. La compilation du paquet proprement dite (qui sera à terme lancée sur les autobuilders Debian) qui prend la tarball et la compile pour l'architecture choisie (par exemple amd64 ou i386).

3. L'installation du paquet lui-même, qui peut se faire sur une autre Debian, indépendamment des deux étapes précédentes.

Grâce au travail d'Arnaud Fontaine, et un petit patch de ma part pour lui faire utiliser la dernière version de Zope 2.12 (le 2.12.17) ce paquet est désormais utilisable, il est en phase de polissage, et sera bientôt soumis aux FTP Masters de Debian, pour inclusion dans la Sid (puis ultérieurement dans la Testing, et enfin peut-être en backport sur squeeze).

Pour ceux qui souhaitent le tester dés maintenant (attention, il s'agit bien d'un paquet non officiel pour l'instant, même si nous l'utilisons quotidiennement), il est disponible, compilé pour Squeeze en AMD64 sur http://debian.pilotsystems.net.

L'attaque sournoise du shebang récursif

Une petite anecdote, mais qui mérite d'être citée car d'autres peuvent en être victimes : il s'agit de l'attaque sournoise du shebang récursif.

Imaginons la scène : après avoir testé et validé le paquet de Zope 2.12 sur ma Sid, tout heureux d'avoir un paquet opérationnel, je le compile sur notre VM dédiée à la compilation de paquets Squeeze. Je le déploie sur une VM dédiée à accueillir des Plone 4 mutualisés.

Et là... dans un roulement de tonnerre et un flash de lumière, dzhandle refuse de créer une instance avec un "Cannot execute binary file". Je cherche des histoires d'architecture, de bibliothèque, non, rien de tout ça.

Sortant ma pelle et mon casque de mineur, je creuse un peu plus. Et je me rends compte du problème suivant : dzhandle appelle /usr/lib/zope2.12/bin/mkzopeinstance. Ce programme a comme shebang (le nom de l'interpréteur à utiliser, après le #! initial) un script nommé /usr/lib/zope2.12/bin/python qui lui-même utilise le Python du système mais en lui rajoutant des chemins de recherche.

Donc : un programme utilise comme interpréteur un autre programme lui-même interprété. On a un shebang récursif. Or, le noyau utilisé jusque là sur nos VMs, le 2.6.26-xen de la Lenny, ne supporte pas les shebang récursif.

Il a donc fallu mettre à jour le noyau utilisé par la VM, opération délicate vu que nos DOM0 n'ont pas encore été migrés en Squeeze (cette opération est prévue, mais non réalisée pour l'instant).

En effet, en utilisant le 2.6.32 des backports de la Lenny, la machine virtuelle se bloquait sur le "Waiting for root filesystem...".

Après avoir testé différentes options (le noyau en -xen ou pas, les disques en sda1/sda2 ou en xvda/xvdb, ...), je finis par comprendre que c'était le module blkfront (utilisé pour gérer les disques en mode paravirtualisé sur Xen) qui n'était pas inclus à la construction de l'initrd.

Assez surpris d'avoir du creuser aussi profondément et d'avoir du me battre avec un noyau, un xen et un initrd pour une histoire de shebang, j'ai utilisé une solution radicale : copier l'image du noyau et l'initrd installés sur une Squeeze, et les utiliser pour démarrer cette VM. C'est du temporaire, les DOM0 seront migrés d'ici peu. Mission accomplie.

Extraction des eggs de Plone 4

Maintenant qu'un Zope 2.12 géré en paquets Debian et via dzhandle tourne, il ne restait plus qu'à installer un Plone 4 dessus.

Mais Plone lui-même n'est plus diffusé sous la forme d'un tarball non plus. Il a donc fallu écrire un script qui, depuis un Plone installé via l'Unified Installer, fait le tri entre :

• les eggs fournis par des paquets Debian (comme PIL ou autres modules Python) ;
• les eggs déjà inclus dans le paquet Zope 2.12 de Debian ;
• les eggs utilisés par Plone lui-même.

Ensuite, il n'y a plus qu'à installer ces eggs dans le lib/python de l'instance créée par dzhandle, et le tour est joué.

Ce tarball est disponible dans https://svn.pilotsystems.net/projets/plone-tar/

Pistes pour le futur

Actuellement, le Zope est géré par l'architecture Debian, mais Plone est plutôt installé manuellement instance par instance. Cette solution est peu satisfaisante, et il serait souhaitable de créer un paquet Debian pour Plone.

Le problème est qu'un changement de version de Plone, même mineur (du 4.0.4 au 4.0.5 par exemple) n'est pas une opération anodine, et demande des interventions dans la ZMI et peut perturber le fonctionnement d'applications tierces. Il faudra donc :

• soit créer des paquets très versionnés (plone4.0.4 comme nom de paquet) ce qui est lourd et peu élégant ;
• soit fixer une version, et s'y tenir, ne faisant que du backport des mises à jour de sécurité, ce qui est dommage est en terme de petites corrections de bugs.