[Kolab-devel] CVS - New Modules and Tools (releng, devel, utils)

[Stuart Bingë]

Hi Steffen,

On Monday 10 May 2004 11:05, Steffen Hansen wrote:
> I am still quite clueless about how this is supposed to work. Can you
> give some concrete examples on how to work with those split cvs
> modules?

To get the modules ready:
# su -
# opa /kolab
# perl -e --nodeps perl-kolab
# cd /yourprojects/kolab
# cvs checkout devel releng utils

To develop:
# cd devel/kolab
# vim kolabd
# vim Kolab/LDAP.pm
... edit, save ...
# ./kolabd
or
# ./kolabconf
... test your changes ...

Once the OpenPKG perl-kolab is uninstalled, these commands will use your 
modified perl-kolab modules sitting in the current directory and the Kolab 
subdirectory.

When you want to build a release:
# cd /yourprojects/kolab
# cd releng/perl-kolab
# cp ../../utils/devtool/* .
After the devtool scripts have been copied, all you'll need to do from now on 
to build a release is:
# ./devtool release

This copies all necessary files relating to the release 
from ../../devel/kolab, while simultaneously transforming them to their 
'release' state, e.g. by substituting any occurrences of '/kolab' with 
'@l_prefix@', and then rolls a release tarball. If we want to do any more 
transformations we simply have to edit the scriplets in devtool.conf.

The reason you have to copy the devtool scripts to each releng directory is 
that I thought it would be best to have a single copy of the scripts in the 
utils module, instead of a separate copy for each releng sub-project (a lot 
simpler when it comes to updating the scripts). It is different for 
devtool.conf, version.pm and README, as these files (while part of the 
devtool package) are project-dependant, and should be totally different from 
one project to the next.

It should however be safe to do a CVS commit in a releng subdirectory after 
you've copied the devtool scripts across and run ./devtool release, as I've 
added the necessary lines in the various .cvsignore files to exclude all 
these copied devtool/development script files.

> Just doing opa /kolab and start hacking away in devel/kolab/ doesn't
> quite work for me. Important files are in the releng module (kolab.conf
> for example -- without that nothing works). Is there some nifty way of
> copying or linking things into place for development?

You don't need to uninstall the 'kolab' OpenPKG module, only perl-kolab; as 
the kolab module contains all these necessary files - templates, config 
files, etc - you'll need it to be installed. The only difference is, you'll 
be using the modified 'kolabd' and 'kolabconf' scripts in your checked-out 
devel module in place of the existing scripts installed with the kolab 
package. You'll also have to do a '/kolab/etc/rc kolab stop' to shut down the 
OpenPKG kolab daemon, so that you can run './kolabd' from your devel checkout 
without an existing kolab daemon running simultaneously.

The reason for moving the templates/config files/etc to the releng module was 
that these files are infrequently modified, at least when compared to the 
actual script source files. When you're developing the daemon you will mainly 
be modifying and using the perl-kolab files and the daemon/conf scripts - if 
you want to make a change to the default conf files or the templates, it's 
usually an isolated event and which is simple enough for you to manually copy 
the new templates to their proper locations. I guess we could create a script 
that links all the /kolab/etc/kolab templates/config files to your releng 
checkout?

By the way, the templates have moved (I'm sure you've already noticed); 
they're now all in releng/kolab/templates and they no longer have the 
".template" extension. This is an initial step towards integrating our 
metadata/dynamic template loading system into CVS. You'll also notice there's 
now a Templates.pm module in devel/kolab/Kolab - this is the major workhorse 
for the new template system; it pretty much replaces the existing 'Conf' 
perl-kolab module. There are still a couple of changes I need to integrate to 
the existing perl-kolab modules and the daemon/conf scripts (as well as the 
metadata to all the templates) in order to get the new system up and running 
- these changes should be coming next. Once that's done kolab.spec and 
perl-kolab.spec will need to be updated to properly handle the new Templates 
module (and exclude the Conf module), as well as the templates/ subdirectory.

> By the way: I have a more or less completely new web admin interface for
> kolab with several improvements over the original one. Should I just
> dump it on top of the old one or should I rather move it to devel
> (where I think it belongs) ?

Please, put it wherever you feel it fits best. As I said, the reason I put it 
in the releng module was that there are no transformations that need doing in 
order to get it ready for a release. If it does goes into devel however, we'd 
have to update the %copydevel section of releng/kolab/devtool.conf to include 
a "cp ../../devel/kolab/admin ." or whatever, in order to prepare the admin 
interface for release.

With regards to the version you have - the admin interface in 
releng/kolab/admin is a verbatim copy of the old server/kolab/kolab/admin, as 
it stood on 2004-05-03 - I'm not sure if this is the latest version or not?

I hope this clears things up for you.

Cheers,

-- 
Stuart Bingë
Code Fusion cc.

Office: +27 11 673 0411
Mobile: +27 83 298 9727
Email: s.binge at codefusion.co.za

Tailored email solutions; Kolab specialists.
http://www.codefusion.co.za/