Why OpenPKG

[Bernhard Reiter]

On Monday 19 April 2004 21:42, Richard Bos wrote:
> Op maandag 19 april 2004 16:07, schreef Bernhard Reiter:
> > On Friday 16 April 2004 11:37, Luca Villani wrote:
> > > Alle 10:58, venerdì 16 aprile 2004, Bernhard Reiter ha scritto:
> > > > Our plan is to improve integration with the OpenPGK project.
> > >
> > > Can you explain to me the OpenPKG platform adoption reasons?
> >
> > Check the first section of the technical document for elaborate reasons:
> > http://www.intevation.de/cgi-bin/viewcvs-kolab.cgi/server/doc/technical/o
> >pe npkg.sgml?rev=1.9&content-type=text/vnd.viewcvs-markup
>
> This is my first email to this list and let me start with saying that it's
> hard to imagine how much knowledge is needed of all the applications, that
> make up kolab, to get them integrated and working toghether nicely.  And
> this includes of course openpkg, I have read the document that Bernhard
> refers to above (even in paper format) several times but the questions
> remain :(

I have created an issue in our tracker so that we do not forget to explain
the reasons better.

> I went for the install last weekend and I can't say it was not as easy as
> apt install <something>.  While I think that I had the easy track with
> SuSE-9.0 as underlaying distribution with binaries available for download.

It got a lot easier with OpenPGK 2.0, btw.
Check www.zfos.org.
Those are development version, though.

> I have the question, why the executables from the distribution can't be
> used (if these are up to date enough, as is the case with mandrake 10 and
> soon with suse-9.1).  Is it not possible to obtain distribution
> independence via a configuration file instead of the openpkg overkill?

In principle every distributor can integrate the configuration files
and the kolab-engine and web-admin interface to gain a Kolab compatible server.
For the project this was not the best path because of the target group 
and the quality assurance.

Anyone setting up a serious groupware server for a larger company
or institution will dedicate a whole server machine to it.
Also the platform decision will be already made.
The design of Kolab1 was geared towards this.
With OpenPGK you can supported Kolab controlled in several deployments
running on top of different operating systems.

A second point is the quality control. To get the system stable in a set time
we expected to control every little detail about the used components.
This means every configuration option, place in the directory and linked libraries
and compiler versions. OpenPGK made that feasable.

So it is okay if we get more native packaging efforts, 
but the testing and developing community needs to grow to support those "ports".

Best,
Bernhard


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/users/attachments/20040421/1a51f4c8/attachment.p7s>