debian/rules questions and my plans for dual-build.

[Sven Mueller]

Henrique de Moraes Holschuh wrote on 06/05/2006 05:10:
> On Fri, 05 May 2006, Benjamin Seidenberg wrote:
> 
>>2.) Why doesn't configure depend on configure-stamp? Right now, it's
>>useless.
> 
> Right now I don't know, but in the 2.1 packages, configure is a *real*
> target, that did all the auto-fu needed to generate configure if it was
> outdated or missing.

Well, I had extreme difficulties getting your auto-update-for-autoconf
to work properly in the 2.2 era (I never checked wether it worked
_properly_ in the 2.1 era). The most severe problem I had would be a
policy violation: If the build was interupted (maybe also when the build
completed), a second try at building from the same source failed.

The way it is now handled is that there is a dpatch file updating the
autoconf generated files, and I update that dpatch file (mostly
automatically with autogen.sh from the 04-* dpatch file) as needed
whenever either the upstream sources to autoconf or autoconf itself is
updated.

> The right thing to do is to either switch to idled, or to make it runtime
> configurable.

This is true. However, idled is mostly a testbed to get the dual-build
tested and worked out. Once we have that, we could also try to get the
kolab patches into the main cyrus-imapd-2.2 source package (as
alternate, dual-built binary packages). I still think that would be nice
since it wouldn't duplicate the work of the kolab people and us, both
maintaining a full fledged cyrus-imapd package.

> My list of "why shouldn't we use idled" from 2.1 days was:
> 
> 1. Because cyrus-master was not babysiting it (as it was not a service, but
> rather a daemon which was fired-and-forgotten).

Sadly, this is still true. However, I haven't noticed a single idled
crash since the first build was installed on my system. And I've been
hammering my imap server with 30.000 mails/day for over a month to
stress-test it (all mails were also fetched again via imap).

> 2. Because it was not widely used.
> 
> (2) is probably not true anymore, and it is high time to fix (1) if it was
> not fixed already.

I don't know how widely it is used, but it seems to make a lot of sense
on high-volume servers. On my system, for some reason I don't really
understand, cyrus-imapd+cyrus-idled consumed about 15% less CPU cycles
compared to just cyrus-imapd, averaged over one day of the stress test.

Regards,
Sven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 188 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-cyrus-imapd-debian-devel/attachments/20060506/7d008140/signature.pgp