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

[Henrique de Moraes Holschuh]

On Sat, 06 May 2006, Sven Mueller wrote:
> 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

Heh :-)

> 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

Which means the *proper* way (which is not necessarily the *best* way ;-) )
to do the build would be to unpack the upstream tarball somewhere (the
"build-tree"), patch it, auto-fu it, then build.

This is not anywhere close to a nightmare in Sid, in fact, it is resilient
and sturdy enough with the latest batch of auto*, that I wouldn't worry
about it.

This is quite different from what we do, though.  As for the build breaking
if you stop it in the middle, that is a fixable bug, but one I never
bothered with, I think.

> > 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

I could take a shot at this, but not this week unfortunately :(

> > (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

It does.  Full IPC would do as well (shared memory between all imap/pop/lmtp
services messing with the same mailbox), but although that would be MUCH
faster, it would not be nearly as easy to implement, or as resilient.

It would make the "keep thunderbird and outcr00k happy" slowdowns history,
though.  Those two clients expect (rightly so, I suppose) that if you do
something over one IMAP connection, all other connections to the same
mailbox will pick it up immediately.  And outcr00k, in the best Microsoft
irresponsible tradition, used to go up in flames if this assumption did not
hold true.

Cyrus in Debian is patched to fix this, since 2.1 days.

> understand, cyrus-imapd+cyrus-idled consumed about 15% less CPU cycles
> compared to just cyrus-imapd, averaged over one day of the stress test.

Looks good.  I'd have idled as the idle backend as default, were it not for
the lack of resilience (which *is* fixable).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh