[Kolab-devel] Autofoo Proposal

Wed May 12 08:17:09 CEST 2010

Quoting "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:

> Gunnar Wrobel wrote:
>> Hi Jeroen,
>
> Hi Gunnar,
>
>> > I'm playing around with releasing, in full, the power of autofoo onto some
> of
>> > the Kolab packages.
>>
>> "Some of the packages"? It would be restricted to kolabd, wouldn't it?
>> At the moment kolab-webadmin is the only other package that still uses
>> the dist_conf approach and that needs to be changed at some point.
>>
>
> Euh, yes, only kolab and kolab-webadmin from the source package  
> point of view.
> I was thinking of the binary fall-out with possible sub-packages and such.
>
>> >
>> > I came to this plan through dist_conf/ and OpenPKG, which I believe have a
> 1-
>> > to-1 relationship.
>> >
>> > Instead of using static dist_conf/* files, which turn outdated
>> > rather quickly,
>> > are volatile and do not allow for any flexibility on the user end, I
>> > wanted to
>> > use autoconf.
>> >
>> > Hence, I whipped up a Wiki page[1] explaining what I want to do and
>> > how I want
>> > to get there.
>> >
>> > [1] https://wiki.kolab.org/index.php/Autoconf_Proposal
>>
>> Another build time tool will not change the basic problem though. It
>> will still configure the package while building it. The server
>> configuration can easily be changed during runtime though. Yes, you
>> can rebuild your kolabd package but to me a changed configuration
>> should usually not result in a package rebuild. At least if no change
>> in linking binaries is involved.
>>
>
> The "problem" of configuration is two-fold, I think.
>
> One is the problem of the default configuration files that end up on the
> system by installing the packages. These are provided by the distributor,
> vendor and/or by upstream. In this case, the distributors and the vendor will
> have to go with a single build ending up on many systems as possible, at the
> least administrative effort for all participants in the ecosystem.  
> The default
> configuration files must therefor align with various other aspects of the
> system.
>
> The configuration is difficult enough without an extra paragraph in the
> configuration manual on changing a default setting ;-) Additionally,  
> one could
> argue it's way more efficient to spend the time upstream once, at the
> distributor once, then to have thousands of people run in circles checking
> their default configuration files for error-by-default.

No, of course that is not desired. Right now the default configuration  
works out of the box and this should indeed stay that way.

>
> The other side of the problem is what happens when (part of) the  
> configuration
> on the system is changed. Some distributions require /etc/init.d/*, others
> have *ctl commands, and some prefer to have such handled by kolabsrv.
> kolabconf can be used for such (execute the actions to propagate the changed
> settings), but needs to know where to find what, too. We can leave  
> that to the
> user, but we have to start out with sane defaults.

Certainly.

>
> The way that the packages work once deployed is subject to all of these
> conditions (and probably some more). However, each of these aspects is
> (related to what is) injected into the packages during built time.
>
>> I'm also against auto-detecting the server configuration. The Kolab
>> server configuration is quite complex and actually not very flexible
>> when it comes to exchanging one of its components. LDAP has a certain
>> amount of flexibility, the spam filter too, but exchanging apache will
>> already be difficult. Exchanging postfix would seem impossible to me.
>>
>
> By saying "auto-detecting the server configuration", what I meant to say is
> detecting where, for example, php is located (it's used in, for example, the
> master.cf.template, but also the httpd.conf.template), or  
> cyrus.conf, and many
> others.

To that I agree. It would simply mean that maintaining the dist_conf  
file becomes much easier as the maintainer does not need to search for  
these settings manually. Using autoconf during build time for that  
seems perfectly valid.

> For example, I would like to have an option that allows me to disable
> kolab assuming the LDAP server is local (and thus pulling in the requirement
> by means of packaging). Red Hat Enterprise Linux customers and CentOS users
> don't think that's funny. Yet though, on a standalone Kolab server, requiring
> some ldap server makes perfect sense (think ClarkConnect). I would thus like
> to be able to toggle those options during build time.
>

That however is something different and here I don't see how autoconf  
would help. The packages will probably be build on some build server  
and whether LDAP is installed there or not does not seem to matter to  
me. Isn't the installation of the package the relevant step here?

For the scenario you describe I could imagine that the user could wish  
for a --with-local-ldap=no option on the RPM. This would then remove  
the default local LDAP configuration against a stanza that tells the  
user that this section still needs to be configured for an external  
LDAP for Kolab to run.

Or do I misunderstand your intentions concerning the LDAP configuration?

Cheers,

Gunnar

>> As mentioned I agree with you that the dist_conf approach is
>> problematic for packaging Kolab natively. I have been on a path to
>> remove it step by step from the Kolab server during the last years.
>> I'd just like to continue that path and if its something that hinders
>> you in packaging Kolab natively then it is something we might rather
>> tackle sooner than later.
>>
>
> I'm working on it too, let's see if something like autoconf can help us for
> some part.
>
> Kind regards,
>
> --
> Jeroen van Meeuwen
> Senior Engineer, Kolab Systems AG
>
> e: vanmeeuwen at kolabsys.com
> t: +316 42 801 403
> w: http://www.kolabsys.com
>
> pgp: 9342 BF08
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/devel/attachments/20100512/9f57de7b/attachment.sig>