Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 Description of problem: There are many of us who would like to begin using MySQL v4. V4 has many improvements of which we wish to take advantage. MySQL has now moved all production recommendations to v4. Some of us have been installing MySQL v4 from binary and just stomping on whatever but this is not the approach that we wish to take. We have also tried installing the MySQL v4 RPMs from www.mysql.com but these have namespace conflicts with how Redhat has named its MySQL packages (MySQL v. mysql - why?) and dependency problems like libmysqlclient.so.10. I would like to request for Redhat to put out at least a *beta* rpm of MySQL v4 (probably 4.0.12 now) that we could begin to use for testing migration efforts to MySQL v4. Redhat would certainly get some valuable feedback from those of us who were willing to test MySQL v4. thx, Gerry Reno Version-Release number of selected component (if applicable): mysql-3.23.54a-11 How reproducible: Always Steps to Reproduce: 1.read description 2. 3. Additional info:
http://www.mysql.com Database Server Production: 4.0.12 Alpha: 4.1.0 Recent: 3.23.56 <snip> On Wednesday 23 April 2003 19:56, xxx wrote: > Just curious, do anyone know when the 4.0.13 will be released? Thank you. Probably, next week. Egor Egorov Egor.Egorov@ensita.net MySQL AB </snip>
An idea to consider might be implementing a switch for MySQL for V3 and V4 similar to the MTA switch for sendmail and postfix. That way you could provide both V3 and V4 RPM versions of MySQL and then select through /etc/alternatives which version was active. This would make it much easier for those who would like to migrate from V3 to V4. thx, Gerry Reno
Yes, this is something we are looking at. If it were only a matter of packaging up mysql proper, this would not be a problem. However, we have to consider the other packages that relate to mysql as well as migration of existing mysql installations.
Yes, I understand the problem is not trivial. It's more than packaging up a mysql RPM. Heck, even I can do that. The dependent packages are definitely the tricky part - I know; I've tried doing this. Nonetheless, we do need a way to migrate to V4 and I think that a switch mechanism makes sense. It would support those that still want to remain on V3 while providing the ability to use V4 for those who have migrated. Packages that are dependent on MySQL probably aren't using functionality that is specific to any MySQL version and so as long as they are not relying upon anything that is version specific they should be ok. And if they are then of course they would need to be visited. It may also be necessary to develop a set of migration scripts. Whatever mechanism is developed it should also be flexible enough to also account for future versions of MySQL such as v5 which will include stored procedures and many will certainly want to have access to this version when it is finally released. thx, Gerry Reno
http://www.mysql.com Database Server Production: 4.0.13 Alpha: 4.1.0 Recent: 3.23.56 http://lists.mysql.com/mysql lenz@mysql.com 2003-05-20 <snip> MySQL 4.0.13, a new version of the popular Open Source Database, has been released. It is now available in source and binary form for a number of platforms from our download pages at http://www.mysql.com/downloads/ and mirror sites.
Ok... I've packaged up MySQL 4.0.13 and it should be in Rawhide tomorrow. There was a shared library version switch between mysql 3.23.56 (current supported version) and 4.0.13 (rawhide version). mysql 3.23.56 provides libmysqlclient{_r}.so.10 mysql 4.0.13 provides libmysqlclient{_r}.so.12 The backlevel shared libraries are in a new package, mysqlclient10, which will be avaiable in Rawhide at the same time.