[Kolab-devel] yet another way to build kolab

[Richard Bos]

Op dinsdag 8 juni 2004 00:44, schreef Steffen Hansen:
> I also want
> to be able to build RPMs (in fact that is quite important to me, but
> you probably know that by now ;-).

I want rpms too, and I build them quite often too.  Not for kolab yet, but 
that might change with the added support for autotools :)

> I changed the stuff a little: I pushed the autotools stuff one directory
> inwards, so it resides in server/kolab-webadmin/kolab-webadmin instead
> of server/kolab-webadmin. The reason is that the outer dir is used for
> stuff required to build RPMs (spec-file and Makefile that creates a
> tarbal and invokes rpm to build a package). I also changed the
> versioning a bit to the release datestamp we currently use is not part
> of the tarball version -- only the rpm release number uses that. 

In this case I would personnally change the rpm specfile into 
kolab-webadmin.spec.in and have the Version field configured as:

Version: @VERSION@

You might use this for the rpm name as well:
Package: @PACKAGE@

Of course the spec file should become part of the autotools machinery, by 
doing so the version of the tarball and the spec file are _always_ in sync.  
As the spec file now becomes intregrated into to the tarball one can obtain 
the rpm by: rpmbuild -ta tarball.tar.gz

With the suggestion above, I think that the rpm in the top kolab-webadmin 
directory can just be removed.  All you need now is:
./bootstrap, ./configure --prefix=/kolab, make, make distcheck and rpmbuild 
-ba kolab-webadmin...tar.gz(bz2).

Another note about the version; Would it be better to define it as 0.1.90.  
So, it can cleary be seen that this is a beta for 0.2.0.  The advantage is 
the package tools are now able to determine that 0.2.0 is newer than 0.1.90
or 0.2.0beta3 or 0.2.0rc4 or etc.

> I also
> had to add a chown call to Makefile.am to be able to install the stuff
> from the tarball and make it work (the templates_c dir needs to be
> writable by the webserver user), but besides that I like it.

:) Never noticed this.

> I also changed our toplevel Makefile and the rpm spec-file to work with
> the new stuff.

See above.

> Let me know what you think of the changes and how we can get the rest
> the kolab package to work in a similar way.

I liked this module as it is small and we can easily see what is good and bad.  
let's solve the spec.in issue first (it's not a big issue for me ;)

> NB: I was missing one configure option to tell it which user the
> webserver runs as to get the correct ownership on the templates_c file.
> The webserver user is read from the dist_conf file, but shouldn't it be
> possible to set it on the cmdline of configure?

I would like to use apache -V for that.  That should be done with a configure 
macro.  That 1st determines which apache is used (httpd, httpd2, apache) and 
than it continues with looking for the docroot, etc, etc.

I think for now it is good enough to have it in dist_conf, but this is 
definately not the end.

> NB: The tarball you sent was OK because it only contained a few files
> (because kolab-webadmin is a simple package), kolab will be more
> elaborate, so I would prefer a diff against CVS (or a tarball with new
> files and a diff for changed files or whatever is manageable).

For kolab it will be same.  There will be a bootstrap, configure.ac and 
Makefile.am files.  Further more are other files that get changed will be 
renamed with the suffix *.in

Once they are in, diff against cvs can be made.

I'll wait with sending the patch untill kolab-webadmin seems to be okay.

> > Perhaps it is possible for Thomas to develop a devtool for this
> > module based on the autotools.  That would than replace the bootstrap
> > script.
>
> That might be, but we don't devtool for now, just the toplevel Makefile
> for building our own RPMs.

Let's see if the toplevel Makefile can be made obsolete ;)

-- 
Richard Bos
Without a home the journey is endless