On 2/5/2013 2:12 PM, William A. Rowe Jr. wrote:
In catching up with building 2.2.23 and getting somewhere with 2.4.3
(soon to be .24 and .4 from today's email notes), I'm left with one
quandary.
The 2.2 builds all used OpenSSL 0.9.8 and that's where I would leave
it, while 2.4 builds aught to use 1.0.1. That, and libxml2 and lua
are the packages we don't bundle.
Since chances are from responses previously posted here on the subject,
any binary distribution coming from a.o is not going to be able to load
mod_php (PHP 5.4's php5apache2_4.dll currently) so it forces the use of
mod_fcgid. That being the case, I see no reason not to use openssl 1.0.1.
But for the expat and pcre dependencies, the versions we shipped in
2.2.23 and 2.4.3-deps sources are falling out of date. And I doubt
a bundle of 2.4.4-deps is going to be updated either.
expat's still in APR, I know libxml2 can be used, not sure how to build
with it though.
For a binary package here at the ASF, when it comes to a third party
dependency, I would suggest we ignore the out of date bundled source,
and always package what the other OSS project has most recently
released, as long as the release remained binary forward compatible
to our prior packages.
This impacts Windows and Netware along with any other binaries people
wanted to build (aix, solaris or whatever). In most of those cases
I'd expect the 'httpd' package would be devoid of the dependencies
and just rely on the most commonly accepted library bundle. I think
it is that way in most of the deb/rpm/apt packaging repositories.
Since Windows does not have any of these dependencies built-in (other
than odbc), I see no real impact on Win. Why wouldn't we we use the
latest versions? Actually, there is one problematic one possibly, LUA,
5.1 and 5.2 are not interchangeable and could break some 3rd party
modules, thereby users will still stay at 2.2 legacy if this is the
case. mod_perl is forcing users to stay at legacy as well since my last
check it wasn't 2.4 compatible yet.
Gregg
