Fwd: Re: [Kolab-devel] The kolab-resource-handlers module

[Bernhard Reiter]

Am Donnerstag, 13. Oktober 2005 22:11 schrieb Richard Bos:
> Op donderdag 13 oktober 2005 18:26, schreef Bernhard Reiter:

> The autoconfiscation effort is to make it possible to install kolab on
> regular distributions. After the autoconfiscation the packager needs to 
> define a path, user or group only once and a package can be build.  Much
> easier than it used to be, patching code over and over again, as the code
> changing (which is a good thing).  The intermediate result of the
> autoconfiscation effort is a tarbal that can be released.  But of course
> rpms/debs should be made of it.

To my knowledge all packaging systems allow the use of patches and 
configurations
so I thought the idea with the Kolab components is to have the configuration
and the patches be directly be applied by scripts coming directly with the 
Kolab Server component, thus making it a bit easier for the distributions.

> > > 2. store the horde code in its own module (I think that is best
> > > solution)
> > >
> > > 3. Something in between.
>
> Perhaps, we can have the horde stored in a tarbal and have it installed
> from the tarbal by the makefile?  Seems an awfull trick...

I am unsure why this is a trick. Anything that gets the necessary 
configuration done should be fine to help the distributions.
I think we need to take a look upon how the regular horde is packages 
currently.

> > At least part of the Horde code is needed by resmgr and freebusy,
> > so 2. never was an option. (Or am I missing something?).
>
> But isn't the horde code comparable to any of the other 3rd party packages,
> such as apache, postfix, cyrus, etc?  Kolab uses the vanilla source with
> patches in cvs in their own directories.  In mean their is no apache code
> stored in cvs, only the patches...

With Horde, the Kolab project basically included a special set, forked it
and now maintains it for the special purpose.
This was easiest at the time and we probably would not have been able to 
stabilise it fast enough otherwise.
So it is a lot different to apache, postfix, cyrus and the others.

> > You only want to have the fbview in your own module.
> > But if the part of Horde needed for resmgr and freebusy is a large
> > fraction of Horde, then we do not win much be removing this feature
> > anyway and we would need to go with 1.
>
> Understand that, but although you may _depend_ on the code it does not mean
> mean that the code is stored in the same cvs module is it?  

You are correct.

> What is the 
> reason that this horde code is stored in kolab's cvs?

That it is our copy, as mentioned above.

> I did not check, but it might be that my distro provides horde already as
> such the horde code should not come with the kolab-resource-handlers rpm. 
> The horde code should be delivered by it's own package.... seperate from
> kolab-resource-handlers code.  Actually this is to my point of view the
> issue.  

That would be a lot better of course, but this is not the current situation.
And it will be quite an effort to change this.

> Now how is it possible to provide the horde code only in an rpm?  I 
> think by storing the horde code in its own cvs module, seperated from the
> resource-handler code.

That would be a start, but it would not help us much.
The real work would be to find out how far we are off from the other horde 
code to see if we can eventually move to use vanilla Horde in the future
or to look at alternatives.

> I hope it is a little clearer.  

Thanks for explaining it again, I had the feeling that we were missing a clear 
plan here somehow. I hope I could also help to clarify the situation.

Bernhard