Vincent Bernat <bernat@debian.org> a écrit :
OoO Pendant le journal télévisé du mercredi 28 mai 2008, vers 20:55, Cedric Delfosse <cedric@debian.org> disait:En effet, obm-storage et obm-ui dépendent tous les deux de obm-core, qui finalement contient tout le code. Est-il envisageable de couper obm-core en deux sous-paquets, un qui serait utilisée par obm-storage (ou alors carrément inclure cette partie dans obm-storage), et un autre qui serait utilisée par obm-ui (ou inclure cette partie dans obm-ui).En fait, il serait dommage de devoir installer obm-core (qui semble surtout contenir du code web) sur un serveur juste parce qu'on a paramétré la base MySQL OBM dessus.
Je suis d'accord avec toi, cependant, actuellement d'OBM ne me permet pas de faire cela. Lors de la conception du découpage des paquets nous avons beaucoup réfléchi sur cette problématique. Pourquoi obm-core devrait s'installer sur un serveur qui ne gère que la BD?? En fait bien que obm-core inclut majoritairement du code PHP il faut voir cela comme un "ensemble d'API" ( je précise, les guillemets ;-) ). La problématique vient en fait de l'upgrade de la BD OBM. Lors des développements des différentes versions d'OBM, nous utilisons les "API" disponibles dans le code PHP pour le faire évoluer. En effet, si une MAJ de BD entraîne un nouveau schéma pour le stockage des évènements du calendrier ( par exemple) il est beaucoup plus simple d'utiliser le code d'OBM pour faire cela plutôt qu'un script sql ou shell seul. Le problème est donc pour les MAJ. Et là je n'ai pris comme exemple que le calendrier, mais il existe aussi de la gestion de projet, un CRM, etc, faire une MAJ de BD devient vite un enfer ( croyez moi :-D )
Vincent, est-ce la même chose qui te gênait dans le packaging ?Un peu. En fait, obm-storage se contente de configurer la base de données avec dbconfig-common. Mais si obm le faisait, ce serait pareil : dbconfig-common sait configurer une base distante. obm-ui se contenter d'installer une conf d'Apache. obm pourrait le faire de la même façon. Maintenant, Sylvain a donné sur debian-mentors@ quelques arguments dont un schéma pour expliquer les dépendances. Du coup, je suis un peu moins catégorique qu'avant, mais ça me semble toujours bizarre (je trouve que tout devrait être dans le même package). Une autre question pour Sylvain en fait. Avec les packages actuels, on peut installer obm-storage sur une machine et obm-ui sur une autre, mais c'est tout ?
Oui c'est exact, mais à terme on pourra installer les autres services gérés par OBM sur d'autres machines, qui ont besoins chacun de obm-conf. Comme tu l'as dit, le schéma sur debian.mentors explique l'architecture complète de l'objectif.
Tous les paquets du schéma existent, mais ne sont pas intégrable en l'état.L'un des avantages ( ou inconvénients ) d'OBM est que l'on utilise les logiciels fournis par les distributions. Nous n'avons pas notre porpre cyrus ou notre propre postfix; la configuration de ces services est difficile dans le cadre d'une intégration dans Debian (remplacement des fichiers de conf...On en reparlera dans une autre discussion :-D ). Mais j'étudie et cherche une solution pour incorporer le tous.
Je pense que commencer par intégrer les paquets actuels serait un bon pas en avant pour permettre ensuite de travailler sur le reste.
Comme je l'ai déjà précisé, je suis à l'écoute de toutes vos remarques, notamment sur le découpage du packaging. Cependant pour l'instant, et pour ma part, je ne pense pas qu'un autre découpage des paquets soit possible pour assurer l'objectif final qui est une intégration totale d'OBM. Pour l'instant, tous les arguments que vous m'avez avancé étaient justifiés pour une intégration partielle d'OBM et surtout mono serveur. Mon but est que tout le monde puisse installer un OBM sur une grosse architecture et non seulement sur un seul serveur. Pour une install monoserveur il existe le Meta-paquet OBM qui lui tire tous les autres paquets. L'install reste donc facile pour une installation monoserveur via le paquet OBM mais peut ensuite se faire de façon plus fine en installant seulement les paquets et donc services que l'on veut sur tous nos serveur. Tous les monde est donc content.. ( boutade!)
En tous cas, je vous remercie de vos retours, et surtout de cette discussion pour faire avancer le shmilblik.
-- NOBODY LIKES SUNBURN SLAPPERS NOBODY LIKES SUNBURN SLAPPERS NOBODY LIKES SUNBURN SLAPPERS -+- Bart Simpson on chalkboard in episode 7F23