Re: recherche sponsor pour nouveaux paquets [OBM]
Vincent Bernat <firstname.lastname@example.org> a écrit :
OoO Pendant le journal télévisé du mercredi 28 mai 2008, vers 20:55,
Cedric Delfosse <email@example.com> 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
Reply to: