Created attachment 287069 [details] emerge --info Judging from the change log, something was recently tweaked in the mysql build process to address bug #375063. This should cause e.g. the mysql include file to be located in /usr/include/mysql/ instead of /usr/include/mysql/mysql/. On my system, however, and with the current dev-db/mysql-5.1.58-r1 ebuild, the fix causes the kind of problems it aims to solve, as it drops one "mysql" directory too many. The headers are now directly in /usr/include/, the libs directly in /usr/lib64/, and the plugins in /usr/lib64/plugin/ which really doesn't make a lot of sense, does it? Headers like /usr/include/errmsg.h are bound to clobber the include file namespace as well. So please find a solution that gives the correct number of "mysql" directories everywhere. Unless you are absolutely certain that you'll get it right this time, please add a simple sanity check to the end of src_install: test -f "${ED}/usr/include/mysql/mysql.h" || die "Wrong location for mysql.h" To further motivate that this is wrong: it breaks the current ebuild for sci-geosciences/grass-6.4.1[mysql], which explicitely passes the established mysql directories to configure, which will abort upon not finding them: checking whether to use MySQL... yes checking for location of MySQL includes... /usr/include/mysql configure: error: *** MySQL includes directory /usr/include/mysql does not exist. Of course, I could ask for the grass ebuild to be "fixed", but I really and honestly believe the current mysql layout on my system to be an error.
Created attachment 287075 [details] build log Sorry, but as the build log exceeds the size limit of this bugzilla, I had to attach it in compressed form.
Also breaks media-tv/xbmc-10.1: In file included from Database.h:25:0, from TextureDatabase.h:24, from TextureCache.h:26, from Application.cpp:76: lib/sqLite/mysqldataset.h:30:25: fatal error: mysql/mysql.h: No such file or directory compilation terminated. make[1]: *** [Application.o] Error 1
(In reply to bug #375063 comment #41) > I'd like to ask all of you that hit the /mysql/mysql issue to sync the > tree or overlay and test mysql-5.1.58-r1 again to see if it works now for you > or if you still get the /mysql/mysql issue. Sorry, missed that part of the other bug. Also missed the fact that bug #375063 comment #37 already describes the kind of problem I have here. As that bug was marked fixed and I still encountered this issue here, I had simply assumed that the report was dealing with the duplicate dir only, not with the missing one. Anyway, I did remerge the package and that did indeed solve the issue. I guess you probably should have revbumped the package(s) after fixing the eclass. But as that the fix has been around for a fairly long time, revbumping the package now will cause a number of users to remerge the package for no reason at all. Not sure whether you want that, or rather want to deal with reports like this cropping up...
We have a mysql-5.1.59 bump to do, so I'll try to get that one done quickly.
The bump to the mysql-5.1.59 version was done a few days ago, so I'm closing this bug.
