kolab 1->2 migration

[Thomas Lotterer]

On Mon, Apr 19, 2004, Richard Bos wrote:

Richard and all who ask why using OpenPKG,

> 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?
> >
OpenPKG is about Cross-Platform Unix Software Packaging.

Everyone who is focused on a single Platform or whose administrative
scope is limited to a small number of Installations is entitled to never
understand the problem not to mention the solution.

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.

> 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?
> 
Try to get a simple daemon working on a bunch of Linux Distros and
find out how hard it is. 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. With the death of United Linux
that goal is probably missed forever. It might be impossible to pick
compatible options if you extend the scope of the build environment to
BSD and Solaris. You'll find that even the creation of a rc file can
become a science - compare RedHat, SuSE, Mandrake, Debian and Gentoo
and I promise you need at least three different files to support them
all. Following this example you also need to maintain at least three
different package formats. Still, this example is limited to the Linux
world. It becomes much more complex when you want to support BSD and
Solaris where some core utilities behave differently from Linux. Things
get harder when you want to create a solution with minimal interference
with the OS and the ability to be installed side by side with similar
components shipping with the OS and the ability to get installed
multiple times, i.e. to create virtual sites, development environments,
staging areas etc. OpenPKG has solved those problems and already put
in man-years of effort to make this happen. The Kolab (Kroupware)
team understood the capabilities and made a wise step building their
solution in a OS neutral environment. I do not understand what drove the
Mandrake people to waste their time integrating Kolab into their native
distribution. It is like purchasing a boat for driving down the road.
It needs major adjustments to make it work. Not only once. But every
time a new accessory is released. Not to mention the release of a whole
new boat. Even worse, most if not all of their hard work and feedback
they have regarding roadability of a boat is useless for boatbuilders
to improve their next generation product. Hopefully it makes Mandrake
customers happy to receive Kolab software and support with the OS.
Customer satisfaction is the only viable reason for this expenditure I
can think of. I would have preferred to see them supporting OpenPKG -
but I'm biased ;-)

[1] http://www.openpkg.org/doc/slideset/openpkg/

--
Thomas.Lotterer at cw.com, Cable & Wireless