Sat 09 Dec 2006 04:40:08 PM UTC, comment #18:
Let's continue this discussion at task #4226
|
Sat 09 Dec 2006 04:35:25 PM UTC, comment #17:
Yes, I used an old form. This is an important issue if it overrides changes. E.g. Bugzilla tracks it fine --- it shows a page about conflict with several options, like "post the comment only", "discard everything" or "apply my changes fully".
|
Sat 09 Dec 2006 04:30:01 PM UTC, comment #16:
I think what mysqldump produced with the option now used is fine (I used them in the past, then removed them for some reason, because something was broken, but now everything seems to rework ok), I think we are safe now.
(BTW, i think you posted this comment with an old form because it erased my latest changes, that an issue described at https://savannah.cern.ch/bugs/?21477 )
|
Sat 09 Dec 2006 04:13:31 PM UTC, comment #15:
A good way to test would be to self-compile MySQL 3.x, install it to sth. like /usr/local/mysql-old and the configure and make Savane with temporary modified $PATH. However, that's a lot of work and I don't volounteer to do it.
|
Sat 09 Dec 2006 04:09:13 PM UTC, comment #14:
Sorry, when I downgraded to 4.0 the server refused to start up. So I upgraded again to 4.1.
|
Sat 09 Dec 2006 03:28:50 PM UTC, SVN revision 6492:
Backport fix of bug #7972 for repackaging 3.0+2 (task #4225)
(Browse SVN revision 6492) |
Sat 09 Dec 2006 03:18:13 PM UTC, comment #12:
Ok, I think it should be ok now. Could you retry with mysql 4.0?
(you have to re-run `make` in the top directory after `svn update`)
|
Sat 09 Dec 2006 03:16:42 PM UTC, SVN revision 6490:
Attempt to fix bug #7972 by playing with mysqldump options
(Browse SVN revision 6490) |
Sat 09 Dec 2006 03:02:32 PM UTC, comment #10:
This is a longstanding issue, see sr #800.
I thought it was ok at that time, unfortunately, during 2.0, the fix was no longer working.
I'm checking right now what I can do about it.
|
Sat 09 Dec 2006 03:00:45 PM UTC, comment #9:
You are right Paul, it would have been nice to test the install process on older MySQL version. Unfortunately, I do not have a pool of old systems available, I cannot test every version.
|
Sat 09 Dec 2006 02:58:01 PM UTC, comment #8:
As I said in my previous comment, there is no backporting work to do, Savane does not need MySQL 4.1, it does not even need MySQL 4.
The problems lies in mysqldump that add useless things. That the thing we have to check, how to make sure it avoids this useless strings. I already did some test in the past for release 2.0 but apparently not enough.
|
Sat 09 Dec 2006 02:56:48 PM UTC, comment #7:
Well, in this case it makes sense to fix the issue and regenerate SQL files. I suggest that you test database setup on the earliest supported MySQL version before each (major) release then.
|
Sat 09 Dec 2006 02:54:10 PM UTC, comment #6:
OK, with 4.1 database setup went smoothly. (I restored charsets too, so that is not a problem with 4.1 either.)
So, this bug comes down to unstated dependency on 4.1. You decide if to make it official or try to backport to 4.0.
|
Sat 09 Dec 2006 02:52:54 PM UTC, comment #5:
(if we fix this bug, it would deserve a repackaging of 3.0 with this bug fix applied)
|
Sat 09 Dec 2006 02:52:07 PM UTC, comment #4:
But actually, why would we want to have Savane dependent of MySQL 4.1 while we even now that it runs perfectly well on MySQL 3?
The bug is not over the dependancy, the bug is the fact that mysqldump produced sql files that are not compatible over versions with no reason, as we do not use stuff specific to one version or another.
|
Sat 09 Dec 2006 02:49:34 PM UTC, comment #3:
However, it seems that 4.1 is also shipped. I'll check with that and if it works fine, maybe it makes sense to just make dependency on MySQL 4.1 explicit. (And make `configure' fail with a helpful message if it is not present.)
|
Sat 09 Dec 2006 02:44:18 PM UTC, comment #2:
I guess that you use idioms not compatible with MySQL 4.0. I.e. after removing all charsets with `sed' I have error on ``date` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP'.
Not sure if it is OK to use syntax not supported by MySQL coming with the latest stable Debian distribution.
|
Sat 09 Dec 2006 02:14:42 PM UTC, comment #1:
The problem that is have no clue why this does not work. Actually, it should anyway recommend utf8.
On debian testing, I recreated a database the other day without problem.
I guess that if you simply remove "DEFAULT CHARSET=latin1" it should work. Somehow, we should find a make to get mysqldump to produce always valid files.
|
Sat 09 Dec 2006 01:47:43 PM UTC, original submission:
Database setup process gives me an error:
It fails on this SQL statement:
I guess this is a problem with MySQL install since others seem to install it fine. Anyway, then Savane should track such errors at configure time and give a comprehandable explanation of what is wrong. Current failure leaves me with no clue of what to do.
Mysql version is 4.0.24_Debian-10sarge2.
|