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

[Richard Bos]

Hello Bernard,

Op vrijdag 14 oktober 2005 13:36, schreef 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

Patches yes.  What do you mean with configurations (I can guess what you mean, 
but I want to be sure)?

> 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.

I don't get what you want to say here.

> > 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.

What the autotools wants the us to do, is to mention each individual file 
being build/installed.  So one knows exactly, what is happing.  Just 
unpacking a tarbal is not in line with the autotools strategy...

> > > 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.

So it might be called e.g. kolab-horde?

[I stop!  I just discovered that Steffen is working very hard to create a 
kolab-horde-framework]  :))

Steffen I hope you succeed in doing this!!  Can you let us know, when you 
think that the move is ready?

(I still have the feeling that I'm dreaming when I browse the new 
kolab-horde-framework module :)

> > > 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
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel

-- 
Richard Bos
Without a home the journey is endless