Seeing as MySQL has now declared MySQL 4.1.4 a "gamma" release - with a "use this for new development" comment - I thought I'd submit a 4.1.x ebuild that I've been using and keeping more-or-less updated since MySQL 4.1.0 was released. The (fairly small) differences between the 4.0.20-r1 and 4.1.4 ebuild are as follows: - NEWP gets a -gamma added to the end - I changed keywords to "-* ~x86", as I have no idea whether 4.1.4 works properly on other archs - Recreated 4.0.18-install-db-sh.diff as 4.1.4-install-db-sh.diff - Recreated 4.0.18-thrssl.patch as 4.1.4-thrssl.patch; in addition to context changes around the first hunk, the second hunk of the 4.0.18 patch is no longer needed - removed the two commented out patches for the bug 46242 security fix - removed the recent mysqlhotcopy security fix patch as 4.1.4 contains this fix
Created attachment 38723 [details] mysql-4.1.4.ebuild
Created attachment 38725 [details, diff] mysql-4.1.4-install-db-sh.diff
Created attachment 38726 [details, diff] mysql-4.1.4-thrssl.patch
I just noticed that the PDEPEND for DBD-mysql needs to be updated to require at least 2.9004, which is currently package.mask'ed.
Created attachment 39101 [details] Jason's ebuild with updated upgrade warning and latest CVS changes merged Jason, your ebuild works fine for me. Thanks a lot :-) I just updated the warning about recompiling packages that are linking to libmysqlclient as revdep-rebuild also has to be run when upgrading from 4.0. In addition, I merged a change that was made to the 4.0.20-r1 ebuild some days ago.
The ebuild also works fine for MySQL 4.1.4a.
MySQL 4.1.5-gamma has been released. The ebuild also works with this release.
For me, using 4.1(.5) breaks a few things... Perl's DBD-mysql is one, as mentioned in another comment. Also, a ruby mysql module has the same problem. In both cases, problem with the number of arguments to the my_shutdown function.
DBD-mysql-2.9004 works fine with MySQL 4.1, but it's still hard masked for some reason.
> DBD-mysql-2.9004 works fine with MySQL 4.1, but it's still hard masked for some reason. But does DBD-mysql-2.9004 work fine with MySQL 4.0? If not, you have the most likely reason for the hard mask.
*** Bug 67145 has been marked as a duplicate of this bug. ***
Created attachment 42112 [details] mysql-4.1.6.ebuild I've updated the ebuild for 4.1.6. Notable changes include: - synced with 4.0.21 ebuild, notably changing permissions and uses 4.0.21's redone install-db-sh and thrssl patches. The diff between 4.0.21 and 4.1.6 ebuilds is now very small (6 lines changed, 5 removed). - changed PDEPEND to require >=DBD-mysql-2.9004 (if USE=perl) - added "ruby" use flag, that pulls in >=mysql-ruby-2.5. Someone please tell me if 2.5 doesn't build with MySQL 4.1.x - according to the mysql-ruby page it should.
What's the big idea about having DBD-mysql-2.9004 hard masked in profiles/package.mask anyway? Isn't it usually enough to do it in the ebuild KEYWORDS variable? Then one can override it in e.g. /etc/portage/package.keywords, unlike now where you presumably have to edit the package.mask file to make it install. Maybe it's just me :-). I never really did understand why all masks aren't just done in the ebuilds.
I'm not sure on the specific reasons for the mask, but much easier than editing package.mask every time you sync is to add: =dev-perl/DBD-mysql-2.9004 to the /etc/portage/package.unmask file.
4.1.7 (non-gamma, first production release) is now available. I sure would like to see this in the portage tree, even if it is hard-masked for awhile.
Me too; why not put this in the tree and hard-mask it? I even, with some hacking of the PHP eclass, made it compile and use php/mod_php with the new mysqli and the old mysql support at the same time (which is really needed for migration of code). It would be great to be able to do that without hacking eclasses as well.
Grabbed the mysql-4.1.6.ebuild above, removed "-gamma" from the "NEWP=${P}" line, and renamed to 4.1.7. Failed with error that I will attach. Any suggestions?
Created attachment 42709 [details] Error output on 4.1.7 emerge failure
Created attachment 42761 [details] mysql-4.1.7.ebuild I've just added a fixed ebuild for MySQL 4.1.7 because I ran into compile problems when recycling the 4.1.6 ebuild. All I did was adding the dependency ">=sys-apps/texinfo-4.7" and removing "-gamma" from the filename since MySQL 4.1 IS STABLE NOW. Wee. :-)
mysql-4.1.7.ebuild works for me. Thanks!
*** Bug 67871 has been marked as a duplicate of this bug. ***
A dilemma with this is that it doesn't provide a clean upgrade path for 4.0 users in the sense that 4.0 -> 4.1 doesn't have binary compatible libmysqlclient. If people are connecting to a remote mysql server via a client on another computer, will a 4.0 client connect to a 4.1 server? Or do all of the clients have to be upgraded too? I think (and this is just a thought) that this program needs to be slotted so 4.0 and 4.1 can run together while administrators perform the migration. Comments welcome.
please add a "cluster" USE Flag http://dev.mysql.com/doc/mysql/en/MySQL_Cluster_building.html
4.0 clients won't talk to a 4.1 server. it's the same problem we had during the 3.23 to 4.0 migration. but with the added complexity that this time a bit more work is required in terms of what you do with MySQL. slotting mysql is extremely non-trivial (it's been tried before), as it would require seperate database directories and configuration directories - which would then make version upgrades like this a PITA. It's going to be upgrade - then revdep-rebuild. Looking at the lib problem from a different angle, I looked up how FreeBSD deals with it. When removing something, they move it to /usr/compat/{bin,lib} if it's still used by something else directly.
> 4.0 clients won't talk to a 4.1 server afaik, they will, but the client can only connect to the server if the user's password has been encoded with the old password hashing algorithm (this can be acheived using MySQL's OLD_PASSWORD() function). There's also a startup function for forcing the old password hashes in the server. Maybe a comment about this should be added to the default my.ini. Otherwise, the client is told to "consider upgrading the MySQL client" by the server. About upgrading: Yes, the new libmysqlclient is not binary compatible, the user would have to run revdep-rebuild after upgrading to MySQL 4.1. And on top of that, he should run the mysql_fix_privilege_tables script in order to prepare the user table for the new (and longer) password hashes and to add the timezone tables. MySQL gets along without having run the script, but in this case the new password hashes (that should be more secure according to MySQL) and the timezone functions are deactivated.
hello 4.1.7 does not build here. mysqld.o(.text+0x39c8): In function `handle_connections_sockets': : undefined reference to `deny_severity' /usr/lib/libwrap.a(options.o)(.text+0x946): In function `twist_option': : undefined reference to `deny_severity' /usr/lib/libwrap.a(options.o)(.text+0xbef): In function `severity_option': : undefined reference to `deny_severity' /usr/lib/libwrap.a(options.o)(.text+0xbf7): In function `severity_option': : undefined reference to `allow_severity' collect2: ld returned 1 exit status make[4]: *** [mysqld] Fehler 1 Someone has an idea how to resolve this? regards thomas
hello again. Reemerge of sys-apps/tcp-wrappers solved my problem. regards t.
my "emerge mysql" complains about: * Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: * * /usr/local/portage/dev-db/mysql/files/mysql-4.0.21-install-db-sh.diff I guess I need that file, however, the closest match (in attachements) has been barred-out. What file sould I put there?
I copied the entire contents of the "files" directory to the local version of the MySQL repository before merging. It needs some common patches from the "older" (i.e. the ones in the portage tree) versions.
Created attachment 43333 [details] mysql-4.1.7.ebuild with cluster USE flag i tested the old ebuild and it works then i added the cluster use falg reemerged it and it works too
Robin, what do you think about this upgrade plan...: Commit 4.1.7 to portage, package.masked. In pkg_prefetch(), have some logic that basically doesn't allow you to emerge the package if you have an existing version already installed with a note that upgrades aren't yet supported. Then, we can start playing with the upgrade path. From my testing, a 4.1 client can connect to a 4.0 server if you're careful about it.
If binary compatibility cannot be maintained for an upgrade, why not block MySQL 4.1 on MySQL 4.0 and have the ebuild pop out a warning message saying, "You must use 'emerge world -e' to ensure that all programs link properly"? It's a horrid solution for now, but as long as it is masked, things ought to be ok. And thanks for all the hard work in getting this ebuild functioning! It is greatly appreciated out here in the field.
Not an emerge -e world, just do a revdep-rebuild is all thats needed.
I'd really love to see this included into Portage, even if it's hard masked. This is the latest production server and it's the one devs are encouraged to develop against. On a side note, the PHP eclass will probably have to be updated with this one. since once you install MySQL 4.1, the PHP eclass will only build mysqli support so then you can't connect to 4.0.x servers anymore with PHP. Really it should build both mysql and mysqli or maybe separate USE flags... but that's a separate bug report...
yeah, tried and it worked. comiled just fine. just had to rune the 'foo.ebuild digest' stuff to generate checksums, but it worked. now I am midway in the revdep-rebuild process. so far, mod_php 5.0.2 is the only issue, claiming that it does not support the mysqli extension, and wont support until mysql 4.1 in in portage. cant it be added, masked? this would open up the way for php maitainers to solve this issue too, since the ebuild said they wont even try until this one is in portage.
DBD-mysql had an hiccup too. but the developers probably wont touch it until mysql 4.1 is in portage. should I file a bug anyway? ----- gcc -c -I/usr/lib/perl5/vendor_perl/5.8.4/i686-linux/auto/DBI -I/usr/include/mysql -march=athlon-xp -pipe -DHAVE_ERRNO_AS_DEFINE=1 -DUSE_OLD_FUNCTIONS -DDBD_MYSQL_WITH_SSL -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -march=athlon-xp -fomit-frame-pointer -pipe -funroll-loops -m3dnow -msse -mmmx -DVERSION=\"2.1027\" -DXS_VERSION=\"2.1027\" -fPIC "-I/usr/lib/perl5/5.8.4/i686-linux/CORE" dbdimp.c /usr/bin/perl5.8.4 -p -e "s/~DRIVER~/mysql/g" /usr/lib/perl5/vendor_perl/5.8.4/i686-linux/auto/DBI/Driver.xst > mysql.xsi /usr/bin/perl5.8.4 /usr/lib/perl5/5.8.4/ExtUtils/xsubpp -typemap /usr/lib/perl5/5.8.4/ExtUtils/typemap mysql.xs > mysql.xsc && mv mysql.xsc mysql.c Warning: duplicate function definition 'do' detected in mysql.xs, line 193 Warning: duplicate function definition 'rows' detected in mysql.xs, line 291 gcc -c -I/usr/lib/perl5/vendor_perl/5.8.4/i686-linux/auto/DBI -I/usr/include/mysql -march=athlon-xp -pipe -DHAVE_ERRNO_AS_DEFINE=1 -DUSE_OLD_FUNCTIONS -DDBD_MYSQL_WITH_SSL -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -march=athlon-xp -fomit-frame-pointer -pipe -funroll-loops -m3dnow -msse -mmmx -DVERSION=\"2.1027\" -DXS_VERSION=\"2.1027\" -fPIC "-I/usr/lib/perl5/5.8.4/i686-linux/CORE" mysql.c mysql.xs: In function `XS_DBD__mysql__dr__admin_internal': mysql.xs:101: error: too few arguments to function `mysql_shutdown' make: *** [mysql.o] Error 1 !!! ERROR: dev-perl/DBD-mysql-2.1027 failed. !!! Function perl-module_src_compile, Line 65, Exitcode 2 ----- libwww,vorbis-tools recompiled just fine
Tiago, if you had read the previous comments, you would have known about DBD-mysql and how to solve the problem.
I hacked my php eclass to make it compile with the mysqli extension. Furthermore, I had to make some other changes to the eclass to make it possible to compile both mysqli and old-style mysql in at the same time. I have posted my patch (to /usr/portage/eclass/php5-sapi.eclass ) as an attachment (or rather: I will in 2 mins from now ;-) ). As for DBD-mysql, I think the newest masked version works.
Created attachment 44145 [details, diff] Patch for /usr/portage/eclass/php5-sapi.eclass to allow PHP5 with mysql and mysqli at the same time.
Uh, thanks for showing me what I should have done firstplace, I should have read teh full Bug report. anyways, I used the php-sapi patch to compile php5.0.2 and it worked! mysql is complaining about phpmyadmin queries, but that may be a phpmyadmin's problem.
phpmyadmin woes after the upgrade: after the upgrade, when I 1) select a database 2) just click on the sql button ----------- comando SQL: Documenta
phpmyadmin woes after the upgrade: after the upgrade, when I 1) select a database 2) just click on the sql button ----------- comando SQL: DocumentaçãoEdita SELECT label, id FROM `pmadb`.`PMA_bookmark` WHERE dbase = 'ctd' AND ( user = 'root' OR user = '' ) Mensagens do MySQL : Documentação #1267 - Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '=' ---------- I can still type a query and try to perform it, but in the place it would show the results, it says: --------- comando SQL: DocumentaçãoEdita SELECT column_name, mimetype, transformation, transformation_options FROM `PMA_column_info` WHERE db_name = 'ctd' AND table_name = 'PRODUCTS' AND ( mimetype != '' OR transformation != '' OR transformation_options != '' ) Mensagens do MySQL : Documentação #1267 - Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '=' ---------- it looks like the 'ilegal collation' problem is related to phpmyadmin tables to me. should I refrain posting these gripes here until there is an actual ebuild in portage, file a bug for phpmyadimn, or what?
mysql-python-1.0.0 will not build against MySQL-4.1 (the usual API change to mysql_shutdown() is the issue), but 1.1.7 (not yet in Portage) will build against any version from 3.23 to 4.1, and this is the preferred version for Python 2.3 and newer. (I am the author of this package.)
Tiago, looks like phpmyadmin has some problems with the new character set feares of MySQL. The swedish you see, is MySQL's default character set/collation. Whatever it is, I don't think this is the right place to post it; It's hardly a bug with the MySQL ebuild... either a bug with phpmyadmin or you did something wrong when upgrading to 4.1 I think. Maybe try the forums instead?
Sune, Tiago: This is a known phpMyAdmin bug. It appears if, after upgrading to MySQL 4.1, phpMyAdmin's tables for relations, bookmarks, etc. weren't fixed using the script "upgrade_tables_mysql_4_1_2+.sql" which is bundled with phpMyAdmin 2.6.0. This leads us into another problem: since the phpmyadmin ebuild creates those tables automatically, the upgrade mechnism should somehow be automised, too. phpMyAdmin 2.6.1 will probably include a fix so it will work with tables created under MySQL 4.0, although it's strongly recommend to fix the tables.
caleb: that deployment plan of 4.1 package.masked sounds good, and having it block as long as mysql-4.0 is installed. i'm testing out 4.1.7 now, if it compiles for me then i'll put it in the tree hardmasked. for everybody here - we will not be supporting parallel (slotted) installs of mysql4.0 together with mysql4.1 (or any other version pair of mysql) - this definetly applies to PHP.
in cvs now, package.masked. this is the first mysql4.1 that appears to work for me.
*** Bug 34600 has been marked as a duplicate of this bug. ***
> in cvs now, package.masked Thanks a lot, Robin. :-) > we will not be supporting parallel (slotted) installs > of mysql4.0 together with mysql4.1 (or any other > version pair of mysql) - this definetly applies to PHP. OK, but nevertheless, you should allow to build both php extensions (MySQL and MySQLi) against MySQL 4.1. If someone wants to write php4 compatible code, he would avoid MySQLi, whereas php5 development should prefer MySQLi over MySQL. But anyway, this should go into a seperate bug report, shouldn't it?
Alexander, you can use my patch to enable mysqli and mysql at the same time in PHP5.. but of course it should be solved from official side instead, I agree (also because the patch is for a file which is overwritten with each sync you make).
in #c24 are mentioned multiple configuration files, this should not be necessary for my.cnf but only for /etc/init.d scripts, the following is an extract from the mysql manual. http://dev.mysql.com/doc/mysql/en/Automatic_start.html [mysqld-major-version] means that groups with names like [mysqld-4.0], [mysqld-4.1], and [mysqld-5.0] will be read by servers having versions 4.0.x, 4.1.x, 5.0.x, and so forth. This feature was added in MySQL 4.0.14. It can be used to specify options that will be read only by servers within a given release series.
Created attachment 47761 [details] preview of a slotted mysql overlay features: This mysql-overlay create a slotted mysql installation. completely revritten pkg_config() utf8 for mysql-4.1 e 5.0 (see also glep 31) please keep in mind that this is a preview, I've posted it because I cant' work on it in the next few days, so maybe someone would apreciate (and finish it ;) how to use: backup all your data around the world: /etc/mysql /var/log/mysql /var/lib/mysql emerge -C mysql emerge =mysql-4.1.8 emerge mysql-4.1.8 config emerge =mysql-4.0.23 emerge mysql-4.1.8 config # not tested yet bring manually the stuff working revdep-rebuild TODO: utf8 in create database (easy) TODO: tweak /etc/my.cnf patches (easy) TODO: comment in my.cnf to look at /usr/share/doc/mysql-${PV}/conf-samples (easy) TODO: explain to the user how to upgrade (*must* be done manually it's not stuff for stupid programs) (medium) TODO: /usr/include/mysql/ still overlap (medium) TODO: simlinks for man files (/usr/share/man/man1/mysql-4.0.1.gz -> /usr/share/man/man1/mysql.1.gz) (easy rt.fine.m) TODO: /usr/share/mysql/sql-bench/, /usr/share/mysql/mysql-test (medium, low pri) TODO: mysql-config ( ebuild ? ) to change default mysql server (difficult, important) and relink the following? /usr/lib/libmysqlclient_r.so -> libmysqlclient_r.so.12.0.0 /usr/lib/libmysqlclient_r.so -> libmysqlclient_r.so.14.0.0 TODO: make mysql-5.0 compile again (easy time to spend) TODO: add block USE="utf8" -> <mysql-4.1.3 (easy) TODO: insinto /usr/include/mysql ; doins include/{my_config.h,my_dir.h} (difficult, important) TODO: mv /usr/share/mysql-4.0/mysql/* /usr/share/mysql-4.0/ (easy) TODO: A lot of cosmetics, better dosym, /var/run/mysqld/ links, ${ROOT} (easy but a bit long) TODO: to stop mysql u ust use pkill -f mysql , not so fair (medium) WARN: tested installing first 4.1 then 4.0 on a clean system, try reverse order TEST: its possible to have a shared [mysqld] config and then specific conf. for every [mysqld-X.Y] server?
Created attachment 47762 [details] oops, too much hours here, this is the right one
Created attachment 48037 [details] new improved version DONE: utf8 in create database DONE: tweak /etc/my.cnf patches DONE: /usr/include/mysql/ still overlap (medium) DONE: /usr/include/mysql -> /usr/include/mysql-4.1/mysql/ DONE: /etc/init.d/mysql-4.0 restart is ok TODO: simlinks for man files (should be done ?) TODO: comment in my.cnf to look at /usr/share/doc/mysql-${PV}/conf-samples TODO: explain to the user how to upgrade (*must* be done manually it's not stuff for stupid programs) (medium) TODO: /usr/share/mysql/sql-bench/, /usr/share/mysql/mysql-test should be a different package mysql-bench ? TODO: mysql-config ( ebuild ? ) to change default mysql server TODO: Cosmetics, better dosym, ${ROOT} WARN: tested installing first 4.1 then 4.0 on a clean system, try reverse order TEST: its possible to have a shared [mysqld] config and then specific conf. for every [mysqld-X.Y] server? tested with USE="~x86 -berkdb -cluster -debug -innodb perl readline -ruby -selinux ssl -static tcpd utf8" http://www.francesco-riosa.com/gentoo/my_logs.tar.bz2 (120 kB) has some build log of emerge, of mysql, myodbc, ulogd and the output of qpkg -l (may be not really the latest) any comment, request, suggestions ?
a) to make "emerge =myodbc-3.51.06" go ok having more mysql versions installed, follow theese steps: # cd /usr/lib/mysql # rm libmysqlclient.so # ln -s ../libmysqlclient.so.12.0.0 libmysqlclient.so # rm libmysqlclient_r.so # ln -s ../libmysqlclient_r.so.12.0.0 libmysqlclient_r.so # rm -rf /usr/include/mysql # ln -s /usr/include/mysql-4.0/mysql/ /usr/include/mysql # emerge =myodbc-3.51.06 b) now /etc/init.d/mysql* scripts are "splitted", really there is only one mysql file, the other are symlinks to the unversioned one. Probably it's a better solution add /etc/conf.d/mysql with a variable inside that specify wich version to use. if requested I will submit the updated ebuilds or patch.
