First test failed because it could not connect to the server. Because on this server user root doesn't exist.
This is exactly the sort of situation force install is intended to solve. You know why the test is failing, so just tell CPAN.pm to ignore the failed test and install anyway. If, after installation, you find that the module really doesn't work, you can then uninstall it, but many times (I would say at least half the time, in my experience) when a test fails, it's the test that's broken, not the module itself. This is especially likely to be the case in this sort of situation, wherein you know why the test is failing.
On the other hand, it does also make sense that if MySQL is really really old you might have to use an older version of DBD::mysql with it, or else upgrade MySQL.
Of course, "really old" is relative. There's really old as in, "I've got a really old version of Wine on my Gentoo box. I haven't emerged it it in, like, a month or two", and then there's "I've got a really old version of Firefox on my workstation, so old that it's called Firebird", and then there's "My production server has some really old versions of things, because I haven't had time to migrate it from woody to sarge yet", and then there's "This crusty old SunOS box has a really old version of sendmail. I think it's the version that came with the OS." Since you didn't give us the actual version number of your "really old" version of MySQL, it's hard to know whether it's really so old that it's reasonable for DBD::mysql to not support it.
In reply to Re: Mysql 3.23.58 and DBD::mysql
by jonadab
in thread Mysql 3.23.58 and DBD::mysql
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |