[Kolab-devel] Re: [GOsa] GOsa and Kolab accounts

[Cajus Pollmeier]

Am Montag, 21. März 2005 12:12 schrieb Bernhard Reiter:
> Now really to kolab-devel at .
> http://www.kolab.org/mailman/listinfo/kolab-devel
>  Bernhard
>
> Am 21. Mar 2005 um 11:38:52 schrieb Bernhard Reiter:
> > Am 18. Mar 2005 um 21:45:57 schrieb Cajus Pollmeier:
> > > Am 18.03.2005 um 19:43 schrieb Bernhard Reiter:
> > > >somebody has to do it.
> > > >Best would be to find a nice customer for the combination.
> > >
> > > I'd like to do some integration - maybe you can provide some
> > > information on how it is possible to use standard Debian packages for a
> > > complete Kolab deployment. We've done this with Kolab1 for some time,
> > > but I had no success with newer versions.
> >
> > The best place to discuss this would be kolab-devel, I think,
> > (thus I am crossposting.)
> > Because I do assume that you want to do this for Debian in General
> > and not just for Gosa. If you agree we could go into the details there.
> >
> > > I don't like the "everything we need is in /kolab" way.
> > > It makes live more complicated for us (we
> > > can't use it with our standard servers because the configuration needs
> > > are not mappable, we've problems if you don't provide security fixes
> > > fast enough, etc.) and for you (you've to provide these security fixes,
> > > you've to integrate your patches in each new upstream release, etc.).
> > > It would be the best approach to integrate patches with upstream, I
> > > guess. That's not meant in a negative way, beware. But in some
> > > customers cases this is a "no go".
> >
> > As I wrote before: Kolab's use of OpenPKG has advantages and
> > disadvantages. Note that OpenPKG is a project which is independent of
> > Kolab, has a community, corporate sponsors and a good track record. So it
> > is not the Kolab project alone to produce security updates. Our patches
> > to the
> > openpkg packages are minimal.
> >
> > > Integration - well. Both projects have similiar ways to get things
> > > running. I.e. kolabGroupOfNames, gosaGroupOfNames, kolabDepartments,
> > > gosaDepartments, etc. It would be really nice to have this stuff
> > > unified in some way and use one schema for both, beeing compatible. But
> > > it's real live - the nice thing of having standards is that there are
> > > so many of them ;-)
> >
> > I agree that it would be nice to have, but then again it is hard work
> > and Kolab and Gosa developers would need a business case for it.

I'm right now taking a quick tour through the (LDAP) differences between 
several object classes applied by GOsa and Kolab. Will be back here for 
discussion when I'm a bit more familiar with the kolab structures...

Cheers,
Cajus