[Pkg-roundcube-maintainers] Bug#708339: Bug#708339: roundcube-core: db upgrade issues going from squeeze to wheezy

[Vincent Bernat]

reassign 708339 dbconfig-common
retitle 708399 Upgrade steps executed twice
thanks

 ❦ 15 mai 2013 09:23 CEST, Frédéric Gobry <gobry at 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 at 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-roundcube-maintainers/attachments/20130515/e425b803/attachment.pgp>