You say I went the 'long way round', well other than using a package, is there a shorter way to install dbd(mysql) into a custom directory? Would you like to write out the steps in a complete and unambiguous manner?Nice to hear you got it working, though you seem to have gone the long way round.
Regarding package installation, I am wondering if I would have got a useful error message when the mysqlclient_r library wouldn't have been found.
I don't see anything here that we can use.Your account seems to boil down to a call for better packaging, and we could use some expertise in that area
Interesting spin.Maybe you are unclear about the differences between QA, CCM, and packaging?
I don't think so really - I have read your bio.
But most end-users who don't want to concern themselves with that will use theirI disagree [so yes! it is arguable :-) ]. Packaging is not what 'really' matters when it comes to applications like httpd. In my opinion, for enterprise software such as httpd what really matters is:distro's packages, so (arguably) that's what really matters.
up-to-date source distribution comprehensive, organised and up-to-date documentation unit tests built inuseful (unambiguous, informative) debugging and error messages throughout
centralised patch distribution a working, centralised code update systemfull backward-compatibility (regarding interfacing third party applications)
Also, your statement implicitly suggests to me that the source distribution of 2.2.3 is not really ready for production use, just the packages.
For example, it seems to be really odd - seriously - that there have been patches for the "myql" typo in dbd.m4 for several months, and yet it is still found in the 2.2.3 source distribution. That's not packaging - that's a lack of change/control management.
There are some major issues with the current build - as I mentioned there is a bug somewhere that causes a massive bloat of httpd forks - I don't know where, but it's to do with dbd. As for whether or not I am a module developer - I could be - but a management that has no control over it's software tends to lead to dead software. I am seriously wondering if Apache 2.x will ever become as popular as it's more robust 1.3x sibling: it's my belief that if it doesn't get to work clean, out of the box (or from a compile) it will end up being a dead branch. Until I feel confident in the Apache 2.x codebase, why should I be interested in developing modules for it?
The lack of relevant error messages in mod_authn_dbd and mod_dbd is a major concern also. Here is a (non-exclusive) list of some that could be added at little cost to the development team:
DBD Driver xxx not found. It should be at yyy. See http:// dbddriversupportpage for more DBD Driver xxx file found but it is not linked correctly. See http:// dbddriverpage for more
DBD Driver xxx found but not loaded. (Reason) DBD connection failure for driver xxx - no sql server found at yyyDBD connection failure for driver xxx - authentication failed for uuu for server found at yyy
DBD connection failure for driver xxx - (other reasons / results) DBD Driver xxx handle creation failed (Reason) DBD connection failure for driver xxx - database yyy was not foundDBD connection failure for driver xxx - database yyy was found but authentication failed with sqlserver message "EEEEE"
DBD Driver xxx sql query creation failed for query = "xxxxx" (Reasons) DBD Driver xxx sql query "qqq" returned the message "EEEEEE"DBD Driver xxx sql query "qqq" failed due to lack of privileges with message "EEEEE"
And mod_authn_dbd:DBD Driver xxx authentication failed matching "pppp" with "qqqq" (with sqlserver message "EEEEE") (obviously showing the encrypted match)
Some LogDebug messages: DBD Driver xxx successfully connected to address yyy DBD Driver xxx successfully connected to sql server DBD Driver xxx successfully authenticated with sql server DBD Driver xxx successfully executed query "qqqqq" with nnn resultsSo maybe 50 lines of code, which will significantly reduce the headaches involved for end-users with DBD/driver connection or authentication issues.
None of these are to do with packaging - they serve a major purpose - which is to inform the enduser and the developers of where something is failing. More importantly to the development team, they reduce the support time for the software and improve the signal/noise ratio. They help with the process of QA.
Now I could possibly add all those messages into the code base (I could also help with other issues) - but last time I contributed, nothing happened - the code remains untouched even though the relevant bugs have been present in Apache 2.x since 2003. So I've lost some will regarding contributing to the code base.
--------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|