Re: recherche sponsor pour nouveaux paquets [OBM]

Salut,

Sylvain GARCIA a écrit :
>
> Alors, pour commencer tu trouveras l'architecture tous les paquets (de
> deb.obm.org) sur cette page: http://www.obm.org/doku.php?id=debian_etch
> Le problème vient de l'utilisation du paquet de obm-conf avec obm-storage qui
> utilise dbconfig-common. J'explique le topo:
> * L'architecture des paquets (au complet) permettent dinstaller un OBM sur un
> seul serveur mais aussi sur plusieurs serveur répartis. Le but étant de répondre
> correctement au questions et hop! j'ai un OBM installé sur 4,5,.. serveurs qui
> fonctionne out of the box.
> Dans le schéma tu remarqueras que chaque paquets (ou presque) dépend de
> obm-conf, car nous avons centraliser la conf dans un paquets. Le problème et que
> dbconfig-common est capable de générer le fichier de conf, mais je ne l'utilise
> pas.
>
> * pourquoi je ne l'utilise pas?
> tu remarquera que obm-storage dépend de obm-core qui est en fait le code php
> d'OBM. Cela est necessaire lors d'upgrade de BD. Lors d'upgrade il arrive que
> nous utilisions les "API" ou je devrait dire des bouts de code d'OBM afin de
> manipuler les datas du calendrier, des contacts, du CRM ou autres.
> *si je génère la configuration avec obm-storage alors j'aurais obligatoirement a
> installer tout le code php sur tous les serveur, ainsi que le SGBD...
> *une solution possible: jouer avec le type de dépendances, mais cela oblige a
> devoir installer au préalable le SGBD, et donc le simple "aptitude install obm"
> "ne fonctionnera pas" out of the box
>
>   

Juste une remarque, utiliser l'api est d'expérience une mauvaise idée, 
car l'api évolue et du coup tes upgrades finissent par
foirer chez les malheureux qui ne migrent pas avec la même combinaison  
api-base que toi, donc soit  tu fais du bon vieux  sql
soit tu gardes les versions des api que tu utilises à l'upgrade.
Tu as aussi intérêt à upgrader sur les transactions et aussi à garder 
une version dans la base.
Tu peux jeter un oeil au db-upgrade.pl du paquet gforge pour un  
posgresql +  transaction qui ne nous a jamais pourri une base.

Tu auras du mal à faire renter le minig d'obm dans debian car il te 
faudra surement gwt,
et gwt pour lequel j'ai posé un ITP est difficilement compilable, mais 
faut pas se décourager, qqn y arrivera bien un jour...

Sinon, sur les problèmes de conf avec ldap/exim/.. on a exactement les 
mêmes problèmatiques dans gforge.
Avec le temps les choses s'améliorent et les paquets fournissent de plus 
en plus les moyens, de modifier proprement leur conf.


Bon courage


Christian


-- 
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]