> >> 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 ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
