[Kolab-devel] Kolab CF

[Thomas Lotterer]

On Tue, Jan 20, 2004, Stephan Buys wrote:

> 1) zfos uses pure OpenPKG-current packages, the erfrakon releases have some
> packages with patches which diverge from OpenPKG. I cant say for sure, but
> I think that most of the important patches from erfrakon have been integrated into
> OpenPKG-current. 
> 
Correct. Unless I made a mistake all Kolab changes were integrated into
OpenPKG. There is no need to use Kolab patched packages until they
introduce a new feature to an existing OpenPKG package. ZfOS packages
*are* OpenPKG packages. Even when you're doing a binary compare or md5
check you won't find a difference.

The OpenPKG team scans the vendor download sites of every package they
maintain twice a day and update CURRENT packages. Because Kolab depends
on about fifty packages, some of them being very prominent and under
heavy development, their respective CURRENT OpenPKG packages are updated
often. The OpenPKG ftp site only keeps the most recent CURRENT package.
Kolab installations, manual QIM or automated obmtool, would have to be
updated very often. During the couple of days I did the integration
work this happened multiple times. So I decided to use the ZfOS storage
and bandwith resources to create a snapshot of the OpenPKG CURRENT
packages relevant to Kolab. That also means that if you have a ZfOS
Kolab base installation you can always upgrade to the latest OpenPKG
current package - it has the Kolab changes inside and will continue to
have them inside. Be forewarned: CURRENT packages are the most recent
vendor packages and might be completely broken - another reason why a
snapshot is more comfortable at the price of being to bleeding edge.

With the next release of OpenPKG things will change a little bit.
Kolab could be based on a OpenPKG RELEASE which will be kept on the
OpenPKG ftp server for a long time. No more snapshotting required.
Kolab would also automatically inherit OpenPKG security updates. The
latter becomes especially important because the current release of
Kolab spun off from and is using code from OpenPKG v1.2. According to
the OpenPKG security engineering the next release of OpenPKG, to be
expected in the next six weeks, will render OpenPKG v1.2 outdated and
security updates will no longer be created by the OpenPKG team, see
http://www.openpkg.org/security.html

> 2) The zfos distribution uses the obmtool scripts to install Kolab, where the 
> erfrakon release uses the QIM. 
> 
When I looked at the Kolab community I often came accross installation
problems. Some people desperatly tried to follow the QIM, others became
really angry about not getting it to work. Because the Kolab packaging
and installation process depends so heavily on OpenPKG we feel we're
somewhat accountable for that situation. The obmtool tries to simplify
installation a lot by automating it. It would also allow other packagers
to wrap around it and create their native kolab package, i.e. Debian
"kolab.deb" which includes obmtool and the whole Kolab stuff (o.k., a
100MB package, but it would work).

> 3) The zfos distribution uses only the native rc (startup and shutdown) scripts
> with the builtin OpenPKG mechanisms, where the in the erfrakon release the
> process is handled by the rc.kolab script (although monit was supposed to 
> manage this, but never worked consistently)
> 
> There are a couple of minor differences and tweaks, but the two dont differ 
> too much. zfos tends to use more recent packages as well.
> 
The rc stuff needed some porting as OpenPKG policy/philosophy does
not accept some things that were/are done in original Kolab. Just to
name a few: rc.kolab directly starts and stops other deamons which
come with their own rc file. It uses commands only available on Linux
where OpenPKG must work evenly across Linux, FreeBSD and Solaris. Some
scriplets behave like they own the whole system and kill all openldap
servers where they should only stop their own. This violates the OpenPKG
philosophy of staying away from the OS as much as possible and allow for
multiple parallel installations on the same machine. So the rc.kolab
stuff was reshaped and moved into the correct rc files. Thanks to
Stephan's feedback (I hope) we resolved the start/stop ordering problem.
I believe that ordering problem was the initial reason for Kolab to
put all logic into a single file. I have to admit that a fraction of
the rc.kolab functionality was lost when it comes to being verbose
and trying to be intelligent and remedy situations where daemons's
start/stop process became disordered.

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