[pkg-kolab] Re: [Kolab-devel] New with Kolab (Hello all)
jonathan at impilinux.co.za
Thu Mar 15 11:41:06 CET 2007
Bernhard Reiter wrote:
>> According to the Kolab roadmap, version 2.1 is expected to be
>> released in April 2007. We will be implementing the release candidate
>> versions until the final release is ready.
> This is the right approach from my perspective.
Glad you agree, as Stephan says, the best way to get a release candidate
stable is to actually use it!
>> We're considering a few options to get it into native Debian packages.
> It would be good to have good native Debian packages, but you must understand
> the effort it will take to put them up to the same quality
> with Kolab Server/OpenPKG.
Understood. What we're doing at the moment is doing a OpenPKG
installation, remove the parts we won't need in our Kolab distribution,
and then packaging the /kolab system in about 15 packages. Things that
are removed from /kolab include /RPM, /includes, /info and /local. Then
we do an rpm -qa to get a list of all the packages, and then use a
simple for loop to remove all the packages from /kolab and place it in a
directory for later packaging:
for file in `/kolab/bin/openpkg rpm -ql $1`; do
echo Moving $file;
tar --no-recursion -c $file | tar -C /data/kolab-pkg/$1/ -x
You have to use tar, since cp and mv doesn't play too nicely with
recuring directories that are used by multiple packages.
I ran across a problem, where some files remained behind in the /kolab
system, there was also a problem where some files were apparently
installed by two different rpm packages (Debian doesn't allow that), so
I filtered duplicates out of /kolab to prevent later problems.
for directory in `ls -1 /data/kolab-pkg`; do
for file in `cd /data/kolab-pkg/$directory ; find`; do
rm -f $file;
Agter that, I combine a *lot* of the packages, for example, I combine
the contents of all the perl-* directories to form one perl directory
that will be packaged, and all the horde- and PEAR- packages were
combined for a horde package too.
I then ended up with the following packages:
impi-kolab server is just a meta-package that contains the other
packages as dependencies, which includes the rc script, and some
postinst foo that creates the users and sets up the host system. BTW, I
had to made some changes to the rc script to be LSB compliant:
1. I had to add the following section:
### BEGIN INIT INFO
# Provides: kolab
# Required-Start: $syslog
# Required-Stop: $syslog
# Should-Start: $local_fs
# Should-Stop: $local_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Kolab groupware environment
# Description: Kolab groupware environment,
# customised for Impi Linux.
### END INIT INFO
2. LSB requires you to have a restart and a force-reload option as well,
so I added:
restart ) exec /kolab/etc/rc all stop && /etc/rc all start ;;
force-reload ) exec /kolab/etc/rc all stop && /etc/rc all start ;;
Not sure if there's a better way do to #2, suggestions are welcome, it
would be nice to get the LSB compliance in upstream Kolab, although it's
understandable that LSB isn't that important when your system is meant
to run on just about every Unix system that is currently supported :)
>> We don't really want Kolab in /kolab since it's not FHS'sy place to
>> put it, and upstream would never approve of it either.
> I think that this is a minor issue, as far as I remember FHS was not made for
> such situations having another system layer in there. A standard followed
> too strictly become a problem itself as well. :)
> You can place Kolab Server with OpenPKG anywhere, just use a symlink
> from /kolab to it.
Yes, I moved everything to /usr/lib/kolab, and the postinst script for
impi-kolab-server simply creates the /kolab symlink, which means that
the package doesn't have to copy a single file into /. Lintian and Linda
still points out that a lot of the files in /usr/lib/kolab doesn't
belong there, if we're really going to get pedantic over FHS compliance,
we'll have to split the files up and create symlinks, as done with the
>> We're also
>> considering using the current Debian versions of kolab-cyrus, etc, and
>> simply packaging the newest Kolab specific packages (kolabd,
>> kolab-resource-handlers, kolab-webadmin and kolabadmin), although that
>> comes with its own complications.
> Each package is quite easy to get, but you need to quality control the whole
> combination. What would be helpful is, if we all create more methods for
> automated scripting which could test all flavors of Kolab Servers.
> http://kolab.org/cgi-bin/viewcvs-kolab.cgi/utils/testing/ has some helpers
> in there, like send_filtertest_emails.py, but this is just a starting point.
Ooh, that will be quite helpful. Ultimately, I would like to see the
process I have set out above automated, which at this stage seems
>> From what I've read so far, it seems
>> that it might be best to use the OpenPKG installation until Debian
>> upstream has created native packages.
> This is what we recommend as well, I know Benoit likes to have native Debian
> packages and UGS shows that it can be done, but the effort is not to be
> Definately, if you find a Kolab Server installation that is not working as it
> should, you should compare its behaviour to a Kolab Server/OpenPKG first.
> And Kolab Server/OpenPKG is easiest to install and configure from all variant,
> as far as I know. Just two commands. ;)
Oh really? With our young little package we have now, we already do it
with just one command :p
More information about the pkg-kolab-devel