[Kolab-devel] Kolab release confusion

[Thomas Lotterer]

On Mon, May 03, 2004, Stuart Bingë wrote:

Stuart,

> A rather embarrassing question, however I felt it necessary to ask in
> the hope that it would not only clear the situation up for me but for
> others who are also perplexed by the confusion :-)
> 
You are not alone ;-)

> The problem is basically that I'm not entirely sure of the way that
> the Kolab source code on Intevation's CVS server, ZfOS and OpenPKG
> interoperate with regards to Kolab releases.
> 
What we currently have is
- Kolab took OpenPKG CURRENT from somewhere around OpenPKG 1.1 times and
  did local modifications which were required because they needed things which
  didn't work or weren't included in OpenPKG at that time

- I created ZfOS as OpenPKG companion site. First issue it should
  address was the reintegration of local Kolab modifications back into
  OpenPKG CURRENT to finally replace Kolab-OpenPKG void. This first
  worked with what can be downloaded from there under the name of
  kolab-1.0.14-20031126

- The next step of integration was the blessing of the kolab related
  packages to OpenPKG class PLUS or higher to get them into a official
  OpenPKG release where security engineering takes place. That first
  worked under the name of kolab-20040217-2.0.0

- A side effect of the integration work was that the OpenPKG packages
  include both the genuine Erfrakon/Intevation and the Code Fusion
  engine.

- Another issue ZfOS should address was the creation of a generic
  install tool which, in the case of Kolab, could replace the
  QIM. The result is the obmtool which was included in the
  two previous collections of RPMs and who's official home is
  ftp://ftp.zfos.org/comp/obmtool/

- ZfOS should also keep selected OpenPKG CURRENT packages. These have a
  short livetime because every package replaces its predecessor making
  it unavailable for further download.

- Yet another issue ZfOS should address was to make binaries availabe.
  OpenPKG only provides binaries for a core set of platforms, only with
  default options and only for a single prefix (/cw for OpenPKG 1.x,
  /openpkg for OpenPKG 2.x). Kolab needs a different prefix, different
  UID/GIDs, special options and more platforms.

> As I'm currently in the process of reorganising Intevation's CVS
> into a more intuitive system (whereby development- and release
> engineering-related work are separated, as was discussed on the list
> previously) I'm also trying to integrate Ralf Engelschall's excellent
> 'devtool' utility that Thomas submitted to the old kroupware list on
> the 28th of January, which seemed to slip through the cracks. As a few
> of the files in CVS relate to release engineering I'm not sure whether
> to include them, or indeed where would be the more 'correct' place for
> them to reside.
> 
Needless to say, I'd love to see that devtool being used. I would also
highly recommend Kolab to be released as a tarball in the future. Let
vendors do the development and distros do the packaging. In addition,
Kolab should be made available as OpenPKG packages, to make the
developer's efforts reproducable. Think of using OpenPKG and obmtool to
provide a reference cross-Unix-platform solution - based on the Kolab
tarball. Still others can integrate Kolab into their own world with
their own tools ... like Mandrake has done in their 10 release.

In the meantime something new happens and you should be aware of it also
it'll take some more weeks to be released. Ralf is currently working
on a tool called "cvsfusion" which allows to join two CVS into one on
a file-by-file and branch-by-branch basis. This functionality is far
beyond CVS' vendor branch because it allows to join any number of own
with any number of vendor branches. When used for OpenPKG the net result
is that you can import the wholly original OpenPKG repository into your
own as often as you like. You can then create or keep your own branches
and merge changes as you require it. For Kolab that means the part that
focuses on creating OpenPKG "fork" packages (due to technical, time,
philosophical whatever reasons) should follow the structure of the
openpkg-src module 1:1.

> The files in question would be obmtool.conf, rc.kolab, the RPM spec files and 
> Makefiles for kolab and perl-kolab. The question is whether I need keep them 
> on Intevation's CVS server, whether they can be removed, or whether or not 
> they belong elsewhere.
> 
I believe the goal is to eventually remove every localized Kolab package
after OpenPKG integrated the changes back into CURRENT.

> Firstly; are these spec files the authoritative specs that OpenPKG use when 
> building the kolab and perl-kolab RPMs? I'm assuming not, and that OpenPKG 
> have their own specs kept in OpenPKG CVS - if so, can we remove them?
> 
Believe it or not. Because no tarball is available OpenPKG 2.0 and
OpenPKG CURRENT uses the kolab SRPM just to extract the embedded tarball
from its contents. Ugly but true.

> Secondly; how do the various versions of obmtool.conf found all over 
> Intevation's CVS and ZfOS's FTP server relate? Which one would be considered 
> authoritative?
> 
see above.

> Thirdly; is the rc.kolab file on Intevation's CVS server the actual RC script 
> that OpenPKG use for the Kolab RPM, or does OpenPKG maintain their own 
> version? Do we need to keep this file?
> 
A OpenPKG rc file for any package is assumed to control that package.
That's what the OpenPKG rc.kolab does. The Kolab rc.kolab takes care
of all related daemons which is a violation of the OpenPKG spirit and
cannot be accepted. I believe the all-in-one rc was neccesary to control
the order of starting and stopping all related daemons. This was not
possible (or working) in early OpenPKG releases. Today we are still far
from perfection (like dependency based order) but there is a priority
number which turned out to be enough for Kolab.

> And lastly; the various Makefile's in the kolab and perl-kolab directories - 
> are these only used to ease testing, in that a test RPM can easily be built 
> and installed while developing? If this is the case then I think it would 
> make more sense to move this functionality into the devtool, so that there is 
> a single process to both build proper releases and test builds. This may not 
> even be necessary with the new structure, as if you wish to develop and test 
> all you need do is check out the 'devel' module and start using the code in 
> that directory.
> 
Other projects use devtool and have a %release and a %snapshot section
or something similar.

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