Bug#369882: cyrus-doc-2.2 upgrade issues

[Henrique de Moraes Holschuh]

On Thu, 15 Jun 2006, Ross Boylan wrote:
> Does this mean that Debian departed from upstream for 2.1?  Because the

Debian 2.1 is far closer to upstream 2.2 than you would believe.  Look at
the size of the Debian diff for 2.1 if you doubt it.  It is the most
advanced Cyrus 2.1 on earth :-p   So, basically, yes, we departed from
upstream for 2.1 (and upstream took my patches for 2.2 :-) ).

> upstream notes seem to imply that the databases were not skiplist at
> 2.1.

They were not.  But I knew better, and switched them (AND added logic to
detect database type mismatches before cyrus was started when I noticed I
might need to do such a switch) as soon as it was clear they were stable
enough.  Cyrus 2.2 and newer can do database type switch at runtime, so the
old database type mismatch detection stuff can actually be used to
auto-detect what the initial 2.2 config for database types should be.

> Also, the news that it's all skiplist is suprising in view of the
> exchange in 342660.  As I noted earlier, it seems to say that Debian
> uses bdb, although it also refers to that as being consistent with
> upstream (which it's not, if upstream is skiplist).

Upstream uses a mix of skiplist and bdb in 2.2, and would have done that too
eventually for 2.1.  Debian uses a mix of skiplist and bdb 3.2 in cyrus 2.1
(rock stable).  I think we use skiplist + bdb 4.x (faster, not nearly as
rock-stable) for 2.2.

> I assume those instructions apply only to sieve scripts stored on the
> imap server, not those in regular user home directories (another point

It applies to *all* scripts AFAIK. That means scripts stored on regular user
homes that don't get compiled, don't run.  And it means that when the time
comes to require a full recompile because of bytecode changes (this HAS
happened at least once), they must be recompiled as well.

Cyrus is a black box,  Debian never partake of any misguided attempts to
twart that by placing files on user homes (but we didn't remove the ability
to shoot one's self on the foot either.  Maybe that was a big mistake).

I don't think Cyrus even tries to protect itself against someone messing
with its stuff behind its back other than the casual sanity checking of
values it gets from files in the spool, so it will probably not notice
someone messed with the sieve scripts and bytecode (to recompile it by
itself).

> it would be useful to clarify).  (I mean the IMAP server conceptually;
> user home directories might be on the same box as the IMAP server, but
> they aren't under the control of the server).

Cyrus has control of *everything* pertaining its spool, or rather it was
designed to, and *must* have control of *everything* pertaining to its
spool.  I don't think this changed even for 2.3 (beta), let alone for 2.2.

My strong suggestion is for everyone to follow the black-box rule, because
otherwise they will have to deal with the pain that *will* come sooner or
later.  It is a pity upstream doesn't stress this strongly enough.

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