kolab 1->2 migration

[Richard Bos]

Op dinsdag 20 april 2004 00:13, schreef Thomas Lotterer:
> There is a brand new slideset [1] which tries to address questions
> arising from the curious. I would encourage every OpenPKG (=Kolab) user
> to browse through this fifty pages slideset depending on their needs and
> knowlege. The problems OpenPKG solves are discussed on the first nine
> pages.

The presensation also explains when openpkg is not needed.  At slide 8 is 
stated there are kernel and base pkgs and on top of that there are add-on 
(openpkg) pkgs.  In case of recent distributions (with up to date pkgs); 
perl, openldap, cyrus, etc are part of the base or at least are not 
considered add-on pkgs => openpkg not needed (it may sound harsh, it is not 
meant that way!).

>  I believe you are only thinking about vendor
> software versions. This is only a fraction of the wholly piece.
> Most applications have build time options, relationships with and
> dependencies to other applications. It is the OS vendor who picks the
> combinations to create the binaries. It is unlikely that multiple Linux
> Distros choose compatible build time options for the more than fifty
> applications that make up a Kolab server.

Can't this be said about kde and gnome too?  Isn't why these projects just 
release the sources only?  It's up to the distributor to integrate them, I 
believe. which is possible with the hooks that they provide (/etc/kderc ;).

> I do not understand what drove the
> Mandrake people to waste their time integrating Kolab into their native
> distribution.

As explained on slide 13, Mandrake is not supported neither tentative... that 
is 1 reason.  I use suse and I can't see that suse-9.1 will be supported 
soon, same can be said about gentoo.

I think that Luca's reply says at lot about how I feel it as well.
http://intevation.de/pipermail/kolab-users/2004-April/000212.html

Another reason is that pkgs that make up kolab require almost 100MB of disk 
space.  In case of a distributor like suse, mandrake, etc this is redundant 
disk space as they already provide the packages.  I consider disc space here 
on a CD or DVD which delivers the packages -> it means that 100MB of other 
usefull applications must be discarded instead of kolab....  Or an extra disc 
should be pressed, making the distribution more expensive....

Another reason that a distribution probably does not want to deliver pkgs 
twice in dfiferent formats is that they need to provide security patches for 
2 exactly the same applications....

As Luca stated the Mandrake kolab rpm contains many patches that are related 
to the configuration files.  I think that these can be minimized if something 
like the /etc/kolab.rc configuration file is introduced as I proposed 
yesterday or perhaps with a construction similare to autotools 
(automake/configure/etc).  Below are some of the changes that are made by 
mandrake.  As I look at it, these configuration settings could be made with 
the methods stated above.  The latter does not prevent that openpkg packages 
are being made and distributed.  It makes it only easier for others to 
package kolab in a different packaging format.

# Start LDAP as user ldap
perl -pi -e "s|-h |-u ldap -g ldap -h |;" kolab_bootstrap

#...
perl -pi -e 's;\@l_nusr\@;apache;g' httpd.conf.template
perl -pi -e 's;\@l_ngrp\@;apache;g' httpd.conf.template

perl -pi -e 's;\@\@\@l_musr\@\@\@;postfix;g' main.cf.template
perl -pi -e 's;\@\@\@l_rgrp\@\@\@;postdrop;g' main.cf.template
perl -pi -e 's;\@\@\@l_nusr\@\@\@;nobody;g' main.cf.template

I don't have the impression that something like /etc/kolab.rc or something 
like a configure script will be introduced.  The barrier to seems to high for 
that unfortenately.  Is that a correct feeling or will patches be welcomed or 
made that adapts 1 of the concepts mentioned before?

-- 
Richard Bos
Without a home the journey is endless