On Thu, Aug 09, 2012 at 05:26:32PM -0700, Vagrant Cascadian wrote:
> Peter Howard committed a patch to mercurial that mostly addresses the
> database
> upgrade issue, although the upgrade process is still a bit fragile. I've got a
> test environment set up to work on this now...
Ok, the following patch (from the mercurial repository) almost works. There
appears to be a syntax error on
revoking create privledges, but it basically works if that line is commented
out:
changeset: 121:9fe977a1baaa
tag: tip
user: Peter Howard <pet...@ok-labs.com>
date: Wed Aug 08 10:24:27 2012 +1000
summary: Fix postinst to add permission for table creation during upgrade
diff -r e40abe8162b7 -r 9fe977a1baaa debian/postinst
--- a/debian/postinst Mon May 14 01:56:21 2012 -0700
+++ b/debian/postinst Wed Aug 08 10:24:27 2012 +1000
@@ -26,10 +26,11 @@
OLD_ZM_VERSION=$(echo 'select Value from Config
where Name = "ZM_DYN_CURR_VERSION";' | mysql
--defaults-file=/etc/mysql/debian.cnf --skip-column-names zm )
fi
if [ -n "$OLD_ZM_VERSION" ] && [ "$OLD_ZM_VERSION" !=
"$VERSION" ] ; then
- echo 'grant lock tables, alter on zm.* to
'zmuser'@localhost identified by "zmpass";' | mysql
--defaults-file=/etc/mysql/debian.cnf mysql
+ echo 'grant lock tables, create, alter on zm.*
to 'zmuser'@localhost identified by "zmpass";' | mysql
--defaults-file=/etc/mysql/debian.cnf mysql
# stop zoneminder before performing database
upgrade.
invoke-rc.d zoneminder stop || true
zmupdate.pl --nointeractive --version
$OLD_ZM_VERSION
+ echo 'revoke create on zm.* to
'zmuser'@localhost identified by "zmpass";' | mysql
--defaults-file=/etc/mysql/debian.cnf mysql
fi
else
Would there be any serious problems with just leaving the create privledges in
place?
Though it still fails to upgrade properly in a variety of cases... if the
database upgrade succeeds, but zoneminder fails to start for some reason, the
upgrade fails... and after running "apt-get -f install" zoneminder tries to
upgrade the
database again, which fails, because it's already upgraded. I'm thinking it
should actually ask the database
itself what version to upgrade from, rather than relying on the version passed
into postinst. It's not immediately clear what all the ZM_DYN_*_VERSION values
in sql are used for.
Also, I've noticed that it seems to require upgrading the kernel and rebooting
before upgrading zoneminder, otherwise it fails to start (and therefore, fails
to upgrade). This may have to do with the switch to using libsys-mmap-perl.
So I guess there are at least two more issues above and beyond the database
upgrade itself.
live well,
vagrant
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
