On Wed, Sep 22, 2010 at 07:50:25AM +0200, Simon Matter wrote: > > > >> 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. Now - BDB database SHOULD be upgradable. I want to find a BDB expert to help me with that - (a) detecting that an upgrade is necessary, and (b) doing the upgrade. I've already changed ctl_cyrusdb -r (run on startup) to automatically convert between skiplist, bdb and bdb-hash formats based on reading the magic at the start of the file on disk. So the only thing really left to do is making sure we can upgrade BDB databases automatically. Sure downgrades will suck, but that's not quite so scary. .... given the issues with BDB. Is it worth embedding a copy of BDB into the Cyrus distribution rather than using the OS one? I know it's generally considered bad taste, but it sure makes keeping in sync easier! Bron ( the downside being security issue tracking, of course ) ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
