competition

[Simon Matter]

>
>> Debian is still stuck on 2.2 and there seems to be no progress in that
>> area.
>>
>> The main problem they apparently have, is the migration path for the
>> various
>> DB files from 2.2 to 2.3.
>> (The 2.3 version itself works fine as .deb packages)
>
> What "migration path"?  Cyrus 2.3 supports all of the same database
> backends that Cyrus 2.2 did.

I don't know the Debian packages well but from a quick look I did long
time ago it seems like those packages leave quite some work to do by the
user of the packages. That also means there are more ways for a user to
break things which may stop them making the 2.3 packages go in easily.

>
> To the best of my knowledge, you can drop in Cyrus 2.3 binaries, and
> with the same config files as 2.2 used, everything will just work.
> You can't easily go back, because I believe that 2.3 will update
> cyrus.index files to a format which 2.2 doesn't recognize, but that
> shouldn't prevent anyone from upgrading.

IIRC it's a little bit more complicated. Beside BDB, there are also some
steps to do at upgrade, like compiling sieve scripts, possibly converting
its encoding. With BDB backends you have to make sure everything fits
correctly. Binaries need to be linked against the correct version of BDB
and also the on disk BDB files need to be of the same version. Now, think
you want to do a distribution upgrade which comes with the latest greatest
BDB release and new Cyrus binaries which are using them, but your spool is
still on the old release... We all know how this ends.
The only solution - you can call it dirty workaround - I found for our
RedHat EL RPMs was to convert all BDB databases to skiplist on Cyrus
shutdown and convert them back on startup. That way the spool is always in
a state which can be migrated once Cyrus is shutdown.
Of course getting rid of any BDB in the default configuration of the RPM
binaries has helped much to prevent BDB mess.

Simon