kolab 1->2 migration

[Richard Bos]

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

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?

The configuration file, let's call it /etc/kolab.rc should tell the kolab 
scripts where e.g. an application and it's required other files are located.  
If the kolab.rc is not present kolab works as it does now.

An example of /etc/kolab.rc could be:
[webserver]
name=apache
exec=/usr/sbin/apacheclt
configdir=/etc/apache
configfile=/etc/apache/htppd.conf
syslog=/var/log/apache

[ldapserver]
name=openldap
exec=/usr/sbin/slapd
configdir=/kolab/etc/openldap

etc

Above is just an example, based on nothing but an idea.  

As said it is based on an idea, but if it works it would give the following 
possibility as well.  One starts with the pkgs provided by openpkg.  If those 
work one is than able to merged the config information in the /kolab path to 
the distributors config file.  This could be done 1 application at a time.  
If the merged config does not work one adjust the /etc/kolab.rc and switch 
back (and forward) to the openpkg and the distributor's application.

It requires probable a lot of work to the kolab drivers as all the application 
and configuration files must be addressed or accessed using variable names.  
Mandrake integrated kolab with their distribution, but they needed a lot of 
patches.  Perhaps that the kolab.rc could reduce the number of patches??

Perhaps this has been discussed before, I did not find it.

-- 
Regards,

Richard Bos
Without a home the journey is endless