Thanks for routing the bug. Just to be clear, I think there are 2 issues: the upgrade step being executed twice, and the backup being overridden by the partially upgraded database when a second attempt is made. Let me know if you think I should file them separately.
2013/5/15 Vincent Bernat <ber...@debian.org> > reassign 708339 dbconfig-common > retitle 708399 Upgrade steps executed twice > thanks > > ❦ 15 mai 2013 09:23 CEST, Frédéric Gobry <go...@yorglu.net> : > > > I've upgraded my squeeze system to wheezy and faced problems during the > roundcube mysql update. > > > > Detailed sequence: > > > > * The first upgrade failed because I had modified the mysql permissions > of root@localhost. This is > > not a bug in itself, I just let you know for the context: > > > > Creating database backup in > /var/cache/dbconfig-common/backups/roundcube_0.3.1-6.mysql. > > ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using > password: NO). > > unable to connect to mysql server. > > error encountered backing up the old database: > > ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using > password: NO) > > > > * once I had modified the permissions back, I retried the upgrade (in > "don't ask questions" mode) > > but this failed again: > > > > creating database backup in > /var/cache/dbconfig-common/backups/roundcube_0.3.1-6.mysql. > > applying upgrade sql for 0.3.1-6 -> 0.5-1. > > applying upgrade sql for 0.3.1-6 -> 0.6+dfsg-1. > > applying upgrade sql for 0.3.1-6 -> 0.7-1. > > applying upgrade sql for 0.3.1-6 -> 0.7.1-1. > > dbconfig-common: flushing administrative password > > applying upgrade sql for 0.3.1-6 -> 0.5-1. > > error encountered processing > /usr/share/dbconfig-common/data/roundcube/upgrade/mysql/0.5-1: > > mysql said: ERROR 1146 (42S02) at line 5: Table 'roundcube.messages' > doesn't exist > > > > I'm surprised to see that the 0.3.1-6 - > 0.5-1 step took place twice. > The failure is > > caused by the "messages" table being dropped in the 0.3.1-6 -> 0.7-1 > update. > > > > I then started hacking my way through it, and noticed that the backup in > /var/cache was > > actually in a strange mixed state. Turns out that the backup is > recreated at _every_ > > attempt. So, after the first failed attempt, the backup is replaced with > a half-backed > > one, which means that even if I had fixed the duplicate application of > the update > > script, I wouldn't have been able to go smoothly through the whole > > process. > > The upgrade is handled by dbconfig-common. It is a known problem that a > failed upgrade may lead to partially updated DB but this is not your > case. I don't know why the upgrade step has been executed twice. > > Reassigning to dbconfig-common and let's see if we can get a hint. > -- > Write clearly - don't sacrifice clarity for "efficiency". > - The Elements of Programming Style (Kernighan & Plauger) > -- Frédéric
