[Kolab-devel] obmtool

[Thomas Lotterer]

On Mon, May 03, 2004, Darrel Ray Clute, III wrote:

> Here is an example of what the options would be in obmtool.conf:
> 
BTW, obmtool calls the scriptlets commands.

> %stable
> 	(list of OpenPKG 2.0 packages for stable, no amavis, spamassassin or
>   clam)
> 
> %current
> 	(list of OpenPKG Current packages)
> 
Good idea.

Using an option to change something within the obmtool process is not
ideal. People using obmtool quickly come to the point where they are
using obmtool.conf as part of the system's documentation. Requiring
additional input from outside leads to gaps in the documentation. My
conclusion is that all relevant settings, including the prefix, should
be part of the obmtool.conf. Maybe an enhancement would be to provide
an option to override variables whose default are given in obmtool.conf
or create something like a obmtool.priv for such purposes. I'll have to
think about this.

For the Kolab community I recommend that two pathes are chosen, one for
stable and another for current. The advantage is that documentation and
binary packages can be provided/used more easily. It is obvious that
the stable path uses "/kolab". It would be a good idea to use a two
or more level deep path for current to ensure future Kolab releases
support arbitrary pathes. That path should not interfer (not be a
subdirectory of) stable. Suggestions? Mine is: /kolab-devel/current
allows "slash k tab slash" to get to /kolab and "slash k tab dash" to
get to /kolab-dev".

There will be at least a third command required, something like
%stable-update. The reason is that sometimes the rebuild of existing
packages must be forcibly triggered because a included library has
changed. You can tell obmtool to do this using @trigger instead of
@install. The bad side effect is that obmtool does what you told it
and triggers rebuild all the time. Currently there is no good way make
obmtool smarter in this area so a valid workaround is to provide another
command for updates.

Last thing to consider is using %stable vs. %solid. The latter suggests
to the user that everything is kept as much as possible and only
minor (security) updates are done with everything else running as
before (even most bugs). Updates within solid should be no-brainer
install-and-forget-it.

> Also are there any known plans to produce Horde OpenPKG RPM's?
> 
I have this on my personal TODO list.

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