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

[Thomas Lotterer]

On Mon, May 03, 2004, Steffen Hansen wrote:

> On Monday 03 May 2004 16:45, Stephan Buys wrote:
> 
> > If you want to develop, just check out 'devel' and start hacking
> > (remember to 'opa /kolab') and be sure to uninstall the perl-kolab
> 
> What does that mean 'opa /kolab' ?
> 
http://www.openpkg.org/doc/handbook/openpkg.html#environ-opa

> > If you want to release then check out 'releng' (as well as 'devel').
> > There are three directories in here; kolab, perl-kolab and obmtool.
> > obmtool contains the obmtool.conf that we will use, whereas kolab
> > and perl-kolab contain all the files used for creating a Kolab or
> > Perl-Kolab release. In order to release you'll have to copy the
> > devtool scripts in 'utils/devtool' to the relevant directory, then
> > run './devtool release'. This will copy all the source files from
> > devel into their release locations within the current directory and
> > roll the necessary tarballs.
> 
> Can you give some examples about how to use devtool and shtool so
> I can get up to speed and merge in my stuff (and implement the new
> features)?
> 
The structure is very simple: run "./devtool foo". Then devtool will
take the %foo shell snippet from devtool.conf and prepend the wholly
devtool.func and run that generated script. Strong rpm feeling, simple
and powerful. It's up to the project organization to create the
%scriptlets and adopt them to their environment. My recommendations and
experience from other projects are:

    %autoclean
    %autogen
    %checkout
    %configure
    %depend
    %dist
    %install
    %release
    %snap
    %tag
    %test
    %upload
    %version

In most if not all cases a developer should get an idea of what these
are doing by examining the names. Some are "meta" scriptlets only
calling others. I provided examples for the most important ones.

> The first "showstopper" for me was running devtool. It needs
> devtool.func from utils and devtool.conf from releng and it seems to
> want both to be in the current dir.
> 
That's true. The devtool triple should always stay in the same
directory in order to build a working group of files. This also allows
a %scriptlet to call "./devtool %otherscriptlet" with no need for
setting a PATH. This also allows all devtool/devtool.func files to be
updated on the favourite pace of the project. And updates are rare.
More importantly the project specific devtool.conf can be customized
seperately.

> > Not everything relating to using devtool to release is in; we'll
> > have to considerably customise devtool.conf for each module (there
> > are a lot of FIXMEs around the place), however for the moment the
> > basics are there. Thanks go to Ralf Engelschall and Thomas Lotterer
> > for this release system. (Note that you'll need the 'cvs2cl' program
> > in order for the CVS log to ChangeLog/Changes functionality to
> > work).
> 
> Where do I get cvs2cl?
> 
i.e. ftp://ftp.openpkg.org/release/2.0/SRC/PLUS/cvs2cl-2.52-2.0.0.src.rpm

> > Other developers may also want to move some of the directories in the
> > current server module over to the new system as well; I'm not sure
> > how everyone feels about this though.
> 
> Most of those are obsolete as the required changes are in OpenPKG.
> The only one I can think of that we need that might not have been
> integrated would be the groupfile_hack patch for cyrus. I'll import
> whatever I need soonish.
> 
The hack was included into OpenPKG with a FreeBSD port of the Linux'ish
getgrent() added, http://cvs.openpkg.org/chngview?cn=12796 The
interesing thing is that I have never seen a situation where Kolab
actually requires this hack. I believe the whole stuff stays dormant
within Kolab.

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