The more I look the less I know :( RELEVANT PARTS On looking more closely at Upgrade.Debian, I realize I don't know what "The information how to upgrade your database files is contained in the upgrade information from cyrus v1.6 below." Assuming the reference is actually to cyrus 1.5 (bug 368675), I originally took this to mean "follow the instructions for 1.5." I now suspect the meaning is "follow those parts relevant to upgrading your database files." But I'm not sure which files count as "database" files.
Part of my basis for this suspicion is that the upstream upgrade instructions involve only a couple of steps. DEFAULT DATABASE FORMAT: SEEN MAILBOX *.db state skip skip README.configure-options BDB skip Upgrade.Debian BDB BDB BDB BDB bug 342660 (not clear exactly which files) skip skip upstream upgrade instructions But one person in 342660 favors BDB as sticking with upstream. BDB flat 2.1 and earlier, as described in upstream upgrade instructions README.Debian.database also refers to *.subs (as among the state files), which is absent from the other discussions. All of which leaves me totally confused. I suspect *.db = MAILBOX; SEEN is either a subset of the "state" files or the whole thing. I'm not sure about, e.g., deliver.db. CONVERSION COMMANDS README.Debian.database describes a multistep process (in step 2.1) involving db3->flat and then flat->skiplist. Upstream upgrade instructions recommend a single berkeley->skiplist. SHUTDOWN/STARTUP/UPGRADE Upgrade.Debian says to stop the new server (step 5) after installation (step 4), and then copy a flag file to ensure it won't run (step 6). This, along with standard Debian practice, suggests the new 2.2 server will be running immediately after the relevant install. It will therefore be running against the unconverted database, which seems like a bad thing (though I guess it would just fail??). Is this how it behaves? Is that how it should behave? The answer to the second question seems to me to be no. Also, Upgrade.Debian describes a series of manual steps to shut down the server. Wouldn't it suffice to invoke the appropriate init scripts, or even just to do the install of step 4, which will uninstall the old packages (because of conflicts: relations between the two), which in turn would shut down the old server(s)? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]