Nice to hear you got it working, though you seem to have gone
the long way round.
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?
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 their
distro's packages, so (arguably) that's what really matters.
I 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:
up-to-date source distribution
comprehensive, organised and up-to-date documentation
unit tests built in
useful (unambiguous, informative) debugging and error messages
throughout
centralised patch distribution
a working, centralised code update system
full 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 yyy
DBD 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 found
DBD 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 results
So 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: [EMAIL PROTECTED]
" from the digest: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
