[Kolab-devel] yet another way to build kolab

[Thomas Lotterer]

On Thu, May 27, 2004, Richard Bos wrote:

Dear Richard and Kolab developers!

On Fri, May 28, 2004, Bernhard Reiter wrote:
> On Friday 28 May 2004 14:04, Richard Bos wrote:
> [why three packages]
> 
> The separation is good, because the components have different tasks.
> Thus they should be upgradable independently.
> 
Also I never actually tried it, the design of the Kolab server allows
components to run on different machines, i.e. the web interface on one
machine and the engine on a different machine. The directory might be
run on a third machine - discrete components allow service separation.

On Mon, May 31, 2004, Steffen Hansen wrote:
> [wants php-smarty to become a OpenPKG package]
> 
I'll have a look into this.

> Currently all packages besides perl-kolab, kolab and kolab-webadmin
> and php-smarty are available from OpenPKG. The reason the packages are
> provided together with the kolab ones is to have a fix environment for
> testing. The packages are taken from OpenPKG-CURRENT, which changes
> very often. I'd like our environment to change more slowly, so we keep
> a copy of a working package a little longer than OpenPKG-CURRENT.
> 
The fix environment is also beneficial for development, troubleshooting,
support and portability - for everything that must be reproducable.

> But please notice that some of the packages are built with special
> options for kolab. See obmtool.conf.
> 
Yep.

> Once OpenPKG-2.1 is released (any prognosis?)
> 
Mid Jul 2004, see http://cvs.openpkg.org/getfile/openpkg-re/todo.txt

On Tue, Jun 01, 2004, Richard Bos wrote:
> As stated in the subject I have an alternative Makefile for
> some kolab cvs modules. My favorite one at the moment is the
> one for kolab-webadmin. The latter because there are no real
> differences, if I compare the files provided via the rpms from
> http://ftp.kolab.org/kolab/server/development/ and my makefile (the
> differences seems to be updates in cvs compared to the rpms).
> 
> The tarball that is the result of the above mentioned
> Makefile is located at: http://linux01.gwdg.de/apt4rpm/kolab/
> (kolab-webadmin-1.90-20040601.tar.gz). The tarball can be configured
> with ./configure (use --help) for the possible reconfigurations. The
> usual commands like make, make DESTDIR=.... install and make distcheck
> work.
> 
I took a look at this work today and I suggest Kolab should use it.

On Fri, May 28, 2004, Stuart Bingë wrote:
> On Tuesday 25 May 2004 22:58, Richard Bos wrote:
> > I don't know, what [devtool] can or not. It would be nice if someone
> > could shed some light on it.
> 
> There are two tools that OpenPKG have made available to the Kolab
> project - obmtool and devtool. Obmtool handles the management of
> OpenPKG "distributions", such as Kolab, whereas devtool is used for
> release management of individual packages, such as the kolab or
> perl-kolab packages.
> 
Think of obmtool being a "installer". This tool is nearly useless for
developers of Linux Distros and alike which want to avoid use of OpenPKG
and replace it with their native packaging format. However, they should
gain some insight by looking into obmtool.conf because it lists special
package options to be used with Kolab.

> Devtool [...] is geared more towards building releases rather than
> building source code, i.e. packaging a set of files to be distributed
> in a release tarball, managing version information for a project, etc.
> 
Exactly. It is not a replacement for make or the GNU autotools. In fact,
it calls them - if the development environment supports it. Currently,
Kolab is missing the autotools and that's what Richard Bos is going to
contribute.

On Fri, May 28, 2004, Richard Bos wrote:
> Can I state that 'devtool' compares to 'make distcheck'?
> 
It is a superset. Or a wrapper. The devtool calls "make" but it does
some pre and postprocessing like tagging CVS, preparing a version File,
creating and uploading the tarball.

> Is devtool able to create kolab releases with a different prefix than
> /kolab? Most likely alternative prefix would be '/' (l_prefix=/) and
> referring to perhaps already installed servers (like /usr/sbin/apache,
> /usr/bin/openldap, etc).
> 
In the end (not reality today), IMHO a Kolab (component) release should
drill down to a tarball and the ingredients are not yet prepared for a
certain prefix.

    ****

I want to explain my point of view regarding development, release
engineering and packaging. My experience in this area comes from OSSP
so I'll use an arbitrary example for discussion, OSSP uuid (Universally
Unique Identifier) library. Please take the time to review, understand
and finally revamp Kolab if you like it.

 ftp://ftp.ossp.org/pkg/lib/uuid/uuid-1.0.0.tar.gz = tarball
 http://cvs.ossp.org/dir?d=ossp-pkg/uuid = cvs web interface
 http://cvs.ossp.org/getfile?f=ossp-pkg/uuid/devtool.conf = simple
 http://cvs.ossp.org/getfile?f=ossp-pkg/lmtp2nntp/devtool.conf = complex

The library uses the usual GNU equipment shtool, libtool and autoconf.
It also contains a generic devtool/.func with a specific devtool.conf. A
developer checks out CVS and runs

    $ ./devtool autogen
    $ ./devtool configure
    $ while [ unfinished ]; do editing; make; testing; done #work

As you can see, devtool, the GNU autotools and make work together. There
is nothing magic with devtool.conf, it's just a kind of documentation
you should prepare for yourself, collegues, vacation replacement etc.
anyway. Only that this documentation is executable :-)

When a development cycle is finished it's time for release. The usual
tasks to be executed by the release engineer are automated through
devtool

    $ ./devtool version # handles version numbering properly
    $ ./devtool dist    # creates the tarball
    $ ./devtool upload  # guess ...

It should be noted that devtool* is NOT part of the tarball! Having
developed and released, we already satisfied the "./configure; make;
make install" adminstrators.

However, packaging systems were invented to take the next step of
automation. This is were Kolab chose OpenPKG. This should be the
first time in the development and engineering cycle were OpenPKG
comes into play and it is perfectly valid to make OpenPKG optional
or create a alternate solution, i.e. based on RPM (RedHat, SuSE,
Mandrake ...), dpkg (Debian), ports (FreeBSD), pkgsrc (NetBSD),
pkginfo (Solaris) etc. Assuming we pick OpenPKG for packaging, a spec
file has to be created which downloads the tarball we just created
and automates the "configure; make; make install" procedures. The
"configure" step, regardless of being done manually or by packaging,
should be the first place where the DESTDIR appears. See the spec at
http://cvs.openpkg.org/getfile/openpkg-src/uuid/uuid.spec

Finally, packaging often requires that for a package to be build or
installed successfully, other packages are required. This is the end
of the OSSP uuid example because it is only a simple library with no
special requirements. Back to Kolab. Some packaging systems have such
interpackage relationship management embedded, others use one or more
tools that wrap around the packager, i.e. YaST (SuSE), Apt (Debian and
others), pkg_add (FreeBSD), urpmi (Mandrake). Some people prefer a
enterprise solution for deployment, i.e. Ximian Red Carpet. To ease
installation of Kolab using OpenPKG packages, obmtool can be used.

I hope this makes the relationship between GNU autotools, devtool and
obmtool more clear.

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