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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
