Upgrading cyrus

[Patrick Goetz]

Jeroen van Meeuwen (Kolab Systems) wrote:
> 1) the export/import on service stop/start is not *mandatory*, I'm not sure 
> why you think it *needs* to be done every time the process is stopped/started. 

Sorry, I took this:

On 09/14/2010 04:16 PM, Jeroen van Meeuwen (Kolab Systems) wrote:
> > > Indeed it [cyrus-imapd.cvt_cyrusdb_all] exports the databases on
service
> > > shutdown, and then imports them back on service startup;


to mean *every* time the service is started or shut down.  Not even this
is a deal killer, in my opinion, but in Debian this would most naturally
be handled by a post installation script, which (I think) would cover
every case of an update or system upgrade.  Of course the user could be
warned in a comment in imapd.conf that the script *must* be run if the
database formats are changed.


> 
> FYI, the point becomes moot with the release of Cyrus IMAP 2.4, which includes 
> automatic database format and configuration detection and conversion. Any 
> solution we come up with lasts for the remainder of the support lifecycle for 
> cyrus-2.2 and cyrus-2.3 only.
> 

Yes, I got this from the discussion on the cyrus-devel list.  However,
it's still worth moving ahead with getting cyrus 2.3 into (deb)
production.  Lots of code changes (in 2.4) invariably means lots of new
bugs, and the 2.3.x codebase appears to be relatively stable.  In any
case, the problem of upgrading 2.1.x and 2.2.x systems will exist
regardless.

Thanks for pointing out the redhat script.  Using this as a base for a
similar script for debian seems very manageable, at this point.  What
would be nice to know is the question I asked previously: what were the
compile time db defaults for all previous debian-released versions of
cyrus?  Is there a straightforward way of obtaining this information?
The long gap between new debian cyrus package releases actually is a bit
of a blessing in this case, since there will only be a few cases where
this is a run time option.  <:)