[Kolab-devel] Autofoo Proposal
Gunnar Wrobel
wrobel at pardus.de
Wed May 12 07:59:04 CEST 2010
Quoting Thomas Spuhler <thomas at btspuhler.com>:
> On Tuesday 11 May 2010 09:31:45 pm Gunnar Wrobel wrote:
>> Hi Jeroen,
>>
>> Quoting "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:
>>
>> > Hello,
>> >
>> > 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.
>>
>> >
>> > 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
>>
>> You are right and the dist_conf files are a problem as they configure
>> the package for a specific server configuration *while building the
>> package*. Not very flexible indeed and something that should be changed.
>>
>> 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.
>>
>> 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.
>>
>> Having the system analyzing the server and trying to guess the
>> intentions of the user might turn out to be problematic in many cases.
>> I'd rather have the user tell the system what is desired by a few
>> configuration variables in a central configuration file.
>>
>> The easiest solution that I see for that is to remove the whole
>> automake/dist_conf process and have no build time configuration of
>> kolabd anymore. The only thing that should happen would be to detect
>> the distribution and install the default configuration from dist_conf
>> in /etc/kolab/kolab.globals. This would then be used by kolabconf to
>> generate the template configuration during runtime *only*.
>>
>> This has already been started to a certain degree but not yet
>> completed. perl-kolab used to rely on the dist_conf approach, too. And
>> all of its configuration variables nowadays live in the kolab.globals
>> file in kolabd. The restructured perl-kolab is a simple perl package
>> now that can be easily build and installed by any package management
>> system. It's configuration only happens during runtime.
>>
>> 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.
> the /dist_conf was indeed a very painful process when making the
> native Mandriva distribution. But now it's done and adapting to to
> small changes is very easy.
> Be aware that different distributions use very different paths and
> even different package names such as php5 or just php.
> You refer to perl-kolab. Well for a native installation, some
> parameters need to be changed in the spec file depending on the
> distro.
Yes, modification of the spec files are to be expected if you package
for a different distribution. The perl-kolab rpm resulting from
packaging is however relatively unaware of the configuration on the
server it gets installed to. The older version had many path locations
written directly into the code via the dist_conf mechanism. Same as
kolab-webadmin still does it.
This embeds the configuration firmly into the RPM when building the
package and means that you need to rebuild once a specific path
changed. This is okay for the OpenPKG situation but usually more
difficult on a native installation.
Cheers,
Gunnar
> just my 2c
>>
>> Cheers,
>>
>> Gunnar
>>
>>
>>
>> >
>> > --
>> > 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
>> >
>>
>>
>>
>
> --
> Thomas
>
> _______________________________________________
> 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/3fed9992/attachment.sig>
More information about the devel
mailing list