Please take this as editorial comments--as opposed to flaming--on what I view are problems serious enough to hold back to growth of LAMP (Linux, Apache, MySQL, PHP) as a viable Web services solution.
On Linux, any release of MySQL requires that the "mod_auth_mysql" be installed, so MySQL can do database access authorization validation via Apache. Apache will run okay and so will MySQL, but without "mod_auth_mysql" installed you cannot log into MySQL. To move from PHP 4.22 to PHP 4.3 requires that Apache be upgraded from version 2.0.40-11 to 2.0.44-1.8.0. Apache 2.0.44-1.8.0 requires a "mod_auth_mysql" release different than the two versions I have, which are 1.11.10 and 1.11.12. As near as I can tell, except for very old releases, these are the only two current "mod_auth_mysql" releases that are in existence . What it appears to me--and I'm willing to be corrected--is Apache 2.0.40-11 is dependent on a "mod_auth_mysql" version that does not exist! Therefore, I cannot run Apache Apache 2.0.44 and PHP 4.3 is not compatible with Apache 2.0.40-11. After more days of trying, than I care to discuss, I can't upgrade to PHP 4.3 on Red Hat 8.0 Linux. Then there is the issue of upgrading from MySQL 3.23.53 to current version 4.0.10. The module "mod_auth_mysql" requires a library module named, "libmysqlclient.so.10," which is installed by MySQL 3.23.53. You guessed it, by upgrading to MySQL 4.0.10 you cannot install "mod_auth_mysql" because "libmysqlclient.so.10" goes away when MySQL 3.23.53 is replaced. The missing "libmysqlclient.so.10" prevents you from installing install "mod_auth_mysql" whose purpose is described in the above second paragraph. Yes, I see ways to build my on mini-RPMs or manually preserve these modules as a workarounds. But why should I have to do this? Sighhhhh......... I find it rather frustrating that there is little or no coordination between the AMP (Apache, MySQL, PHP) development groups related to shared module release compatibly. Its like each developer group prefers to only deal with their thing, with a total lack of concern about other system elements. Yes, its free software, which I truly appreciate. So much so, that I'm developing ways I can contribute to this community in ways that will be most appreciated for their value-add. For individual element releases a few words of common module dependency issues will save days of work for thousands of LAMP users. The better solution though is to eliminate these quirks. The other solution is to become an expert in compiling and building these three AMP modules from source code. While I capable of mastering LAMP builds, it is something I refuse to do. I have other more important tasks requiring completion, which are contingent on the success of my company. Also, the locating of missing dependency source modules for LAMP code element compiles is horrendous. LAMP / WAMP is the greatest Web services platform for the SMB (Small to Medium Business) marketplace. There's nothing available from the big-boys to even begin to compete price / performance wise, in this market segment. Furthermore, SMB is the Web server / services market segment with the greatest growth opportunities. My mission is to apply LAMP to enterprises and not have to become a guru on how to glue the LAMP elements together. I would like to leave this task to others. Dividing up the labor is how we succeed as a community. I will leave the upgrade integration to others to deal with besides me. My plan now is to wait for April release Red Hat 8.1 release and upgrade then, hoping that they support PHP 4.3 in that release. Please don't post countless notes here on how I can make this upgrade path work. I'm not interested in knowing. My issue is with the LAMP upgrade problems we are all having. Pete Mackie Seaquest Software Portland, Oregon, USA 503.531.0252 http://www.seaquest.com -- PHP Install Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
