i manage to enter all the information on how to access the mysql database check it through the command line and all that but it still gives me the error that it can not connect Reproducible: Always Steps to Reproduce: 1.emerge tikiwiki 2.setup databases 3.try to use tikiwiki Actual Results: got a fatal error message about mysql_connect() function not being found Expected Results: it should have connected to the mysql database without any difficulty i had this bug and i fixed it after about a day or two of smashing my head into the wall. turns out that i didn't have mysql enabled in my use flags, and by default tikiwiki installs and uses mysql. then remerging php and php_mod with mysql support fixed the problem so i believe that it should be implemented that when emerging the ebuild should make sure that at least one of the supported databases is in the USE flags. and a comment at the end would never hurt :D thanks a lot for your patience and time :D Loki, A Proud Gentoo User
dev-portage@ is reporting bugs in the package sys-apps/portage Package: www-apps/tikiwiki Herd: web-apps Maintainer: web-apps@gentoo.org Reassigned bug to web-apps@
you don't need a database on the same machine to use tikiwiki. eg I have a number of webapps that connect to a remote DB using PHP's ODBC support - there is no way we can check for all possible routes.
wouldn't you still have to have one of the possible databases in your USE flags? unless you intend on using a mod_php and php on a different machine as well...
USE=odbc doesn't install any database on your machine. Your statement is only true for a certain subset of databases that don't offer seperate connectivity packages.
however USE=odbc will add support for odbc within php and mod_php, and that is really the main aspect i'm concerned about. i realise that the databases don't have to be on the same machine, but that really is besides the point, as php and php_mod will not support this database being local or remote if they are not compiled with support for this database
just out of curiosity. is there anything that is going to be done about it? or should i give in a proposed fix?
there is little that we can do that would really be effective at this point. just depending on both a database layer and PHP doesn't mean that PHP is compiled with that database. The portage dev folks have ultimately said there will be support at dependancy calculation time to check for a package being built with a use flag, but that won't be for 6 months at least. The best hack that is presently doable is to simply compare PHP's USE flags with a given set that tikiwiki would provide, and throw a warning if things are looking not good.
1.9.0 in CVS, warns about mysql support