Building binaries and 3rd party dependencies

["William A. Rowe Jr." <wr...@rowe-clan.net>]

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.

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.

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.

Comments or thoughts?

Re: Building binaries and 3rd party dependencies

["William A. Rowe Jr." <wr...@rowe-clan.net>]

On Fri, 15 Feb 2013 19:39:17 +0100
Ruediger Pluem <rp...@apache.org> wrote:
> > 
> > I guess with the 2.2.23 question you meant what to include in a
> > 2.2.23 build done right now? Since we plan to have 2.2.24 soon (and
> > I guess you are going to provide Windows binaries for 23 and 24),
> > I'd say 2.2.23 is mostly interesting in case someone experiences an
> > unexpected compatibility problem. In this case it would be saner to
> > build 2.2.23 binaries using the original APR/APU versions
> > 1.4.6/1.4.1. Anyone looking for the latest and greatest would
> > switch to 2.2.24 including 1.4.6/1.5.1.

I concur, thanks for the response.

> IMHO the previous procedure was to keep major.minor stable for APR /
> APR-UTIL in the supplied tar ball and only increase to the latest
> patch level of that major.minor. Only exception was if httpd needed
> new features from APR / APR-UTIL major.minor (keeping major stable at
> all times of course and only increase minor) which was also an
> indication to the users that they need to use a new major.minor
> version. Or do we decouple the APR / APR-UTIL version we put in the
> tar ball from the minimum version detection for APR / APR-UTIL in the
> httpd autoconf part?

The major.prev version stops getting significant bug fixes, so although
the version major must stay put, minor bumps are forward compatible.

I can easily picture a user wanting to add a thirdparty module which
depends on the major.current release of APR or APU, even if the core
httpd code and bundled modules do not need it.

Bill

Re: Building binaries and 3rd party dependencies

[Ruediger Pluem <rp...@apache.org>]

Rainer Jung wrote:
> On 15.02.2013 18:21, Rainer Jung wrote:
>> On 15.02.2013 17:55, William A. Rowe Jr. wrote:
>>> I guess the other question is whether 2.2.24 should be tagged with the
>>> original apr-util 1.3 family, or whether we should pick up 1.5.1?  And
>>> back to the older 2.2.23 sources, should it be the then-current apr-util
>>> that was bundled in the .tar.gz distribution?
>>
>> APR and APU are not part of the svn tag, are they?
>>
>> It looks like 2.2.23 was rolled with APR 1.4.6 and APU 1.4.1 in the
>> tarballs, the current versions at that time. I'd say there's no reason
>> not to proceed like that, ie. using 1.4.6/1.5.1 for 2.2.24 source
>> tarballs and binaries.
> 
> I guess with the 2.2.23 question you meant what to include in a 2.2.23
> build done right now? Since we plan to have 2.2.24 soon (and I guess you
> are going to provide Windows binaries for 23 and 24), I'd say 2.2.23 is
> mostly interesting in case someone experiences an unexpected
> compatibility problem. In this case it would be saner to build 2.2.23
> binaries using the original APR/APU versions 1.4.6/1.4.1. Anyone looking
> for the latest and greatest would switch to 2.2.24 including 1.4.6/1.5.1.

IMHO the previous procedure was to keep major.minor stable for APR / APR-UTIL
in the supplied tar ball and only increase to the latest patch level of that major.minor.
Only exception was if httpd needed new features from APR / APR-UTIL major.minor (keeping major
stable at all times of course and only increase minor) which was also an indication to the users
that they need to use a new major.minor version.
Or do we decouple the APR / APR-UTIL version we put in the tar ball from the minimum version detection
for APR / APR-UTIL in the httpd autoconf part?

Regards

Rüdiger

Re: Building binaries and 3rd party dependencies

[Rainer Jung <ra...@kippdata.de>]

On 15.02.2013 18:21, Rainer Jung wrote:
> On 15.02.2013 17:55, William A. Rowe Jr. wrote:
>> I guess the other question is whether 2.2.24 should be tagged with the
>> original apr-util 1.3 family, or whether we should pick up 1.5.1?  And
>> back to the older 2.2.23 sources, should it be the then-current apr-util
>> that was bundled in the .tar.gz distribution?
> 
> APR and APU are not part of the svn tag, are they?
> 
> It looks like 2.2.23 was rolled with APR 1.4.6 and APU 1.4.1 in the
> tarballs, the current versions at that time. I'd say there's no reason
> not to proceed like that, ie. using 1.4.6/1.5.1 for 2.2.24 source
> tarballs and binaries.

I guess with the 2.2.23 question you meant what to include in a 2.2.23
build done right now? Since we plan to have 2.2.24 soon (and I guess you
are going to provide Windows binaries for 23 and 24), I'd say 2.2.23 is
mostly interesting in case someone experiences an unexpected
compatibility problem. In this case it would be saner to build 2.2.23
binaries using the original APR/APU versions 1.4.6/1.4.1. Anyone looking
for the latest and greatest would switch to 2.2.24 including 1.4.6/1.5.1.

Regards,

Rainer

Re: Building binaries and 3rd party dependencies

[Rainer Jung <ra...@kippdata.de>]

On 15.02.2013 17:55, William A. Rowe Jr. wrote:
> I guess the other question is whether 2.2.24 should be tagged with the
> original apr-util 1.3 family, or whether we should pick up 1.5.1?  And
> back to the older 2.2.23 sources, should it be the then-current apr-util
> that was bundled in the .tar.gz distribution?

APR and APU are not part of the svn tag, are they?

It looks like 2.2.23 was rolled with APR 1.4.6 and APU 1.4.1 in the
tarballs, the current versions at that time. I'd say there's no reason
not to proceed like that, ie. using 1.4.6/1.5.1 for 2.2.24 source
tarballs and binaries.

Regards,

Rainer

Re: Building binaries and 3rd party dependencies

["William A. Rowe Jr." <wr...@rowe-clan.net>]

On Fri, 15 Feb 2013 13:06:22 +0100
Rainer Jung <ra...@kippdata.de> wrote:

> On 05.02.2013 23:12, William A. Rowe Jr. wrote:
> 

> Don't know how windows handles the use of two versions of a DLL in
> the same process.

They must have different file names (not paths); e.g. a versioned dll
filename libpcre-7.dll would be distinct from libpcre-8.dll, but most
thirdparty vendors don't version and even use entirely unreleated names
for dynamic libs on Windows than they had chosen for Unicies.  (For ex
openssl's LIBEAY32.dll vs libcrypto.so).

> For 2.4 I think starting with latest pcre is fine, later major updates
> may depend on compatibility again.

I agree that breaking binary compatibility changes shouldn't be rolled
in once people are using a given major.minor build from the ASF.

> expat: currently still bundled directly or inside deps as apr-util
> builtin. No strong opinion here whether to use that one or the
> latest. I personally would stick to expat for 2.4 and not switch to
> libxml2.

For 2.4?  I can experiment with both solutions.

I guess the other question is whether 2.2.24 should be tagged with the
original apr-util 1.3 family, or whether we should pick up 1.5.1?  And
back to the older 2.2.23 sources, should it be the then-current apr-util
that was bundled in the .tar.gz distribution?

Re: Building binaries and 3rd party dependencies

[Eric Covener <co...@gmail.com>]

On Fri, Feb 15, 2013 at 7:06 AM, Rainer Jung <ra...@kippdata.de> wrote:
> On 05.02.2013 23:12, William A. Rowe Jr. wrote:
>> 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.
>
> +1
>
>> That, and libxml2 and lua
>> are the packages we don't bundle.
>
> Those are additional 2.4 modules dependencies. +1 to bundle the latest
> libs in the first Windows binary release. For libxml2 later updates
> might always be able to go to the latest again, for Lua probably only
> minor updates are OK, because scripts may break.
>
>> 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.
>
> Note that pcre is not part of the deps tarball.
>
> For 2.2 I'd stick to the bundled pcre, but that's not a strong opinion.
> Note that when updating there's a chance of hitting incompatibilities
> with modules that also use PCRE like mod_security. Don't know how
> windows handles the use of two versions of a DLL in the same process.
>
> For 2.4 I think starting with latest pcre is fine, later major updates
> may depend on compatibility again.
>
> expat: currently still bundled directly or inside deps as apr-util
> builtin. No strong opinion here whether to use that one or the latest. I
> personally would stick to expat for 2.4 and not switch to libxml2.
>
>> 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.
>
> Bundled is only pcre (2.2) and expat (2.2, 2.4). As said for those I
> don't have a strong opinion.
>
> For the unbundled ones, the choice of the "right" version might depend
> on linker behaviour when different versions get mixed by httpd and
> 3rd-party modules. For a first binary build of 2.4 I would agree to
> choose the latest unbundled ones.
>
>> 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.
>
> For Linux type platforms and more recent versions of the Unix platforms
> some of the deps exist in acceptable versions as part of the standard OS
> distribution. Because of 3rd-party module compatibility it might then be
> best to build against these versions.

+1.

Re: Building binaries and 3rd party dependencies

[Rainer Jung <ra...@kippdata.de>]

On 05.02.2013 23:12, William A. Rowe Jr. wrote:
> 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.

+1

> That, and libxml2 and lua
> are the packages we don't bundle.

Those are additional 2.4 modules dependencies. +1 to bundle the latest
libs in the first Windows binary release. For libxml2 later updates
might always be able to go to the latest again, for Lua probably only
minor updates are OK, because scripts may break.

> 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.

Note that pcre is not part of the deps tarball.

For 2.2 I'd stick to the bundled pcre, but that's not a strong opinion.
Note that when updating there's a chance of hitting incompatibilities
with modules that also use PCRE like mod_security. Don't know how
windows handles the use of two versions of a DLL in the same process.

For 2.4 I think starting with latest pcre is fine, later major updates
may depend on compatibility again.

expat: currently still bundled directly or inside deps as apr-util
builtin. No strong opinion here whether to use that one or the latest. I
personally would stick to expat for 2.4 and not switch to libxml2.

> 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.

Bundled is only pcre (2.2) and expat (2.2, 2.4). As said for those I
don't have a strong opinion.

For the unbundled ones, the choice of the "right" version might depend
on linker behaviour when different versions get mixed by httpd and
3rd-party modules. For a first binary build of 2.4 I would agree to
choose the latest unbundled ones.

> 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.

For Linux type platforms and more recent versions of the Unix platforms
some of the deps exist in acceptable versions as part of the standard OS
distribution. Because of 3rd-party module compatibility it might then be
best to build against these versions.

Regards,

Rainer

Re: Building binaries and 3rd party dependencies

["William A. Rowe Jr." <wr...@rowe-clan.net>]

On Fri, 15 Feb 2013 10:29:53 -0800
Gregg Smith <gl...@gknw.net> wrote:
> 
> Nothing political, it was from experience of years past when I was 
> handed a benchmark script. I am eating crow here as I see nothing 
> different when using fcgid from my test years ago. I am seeing
> different results in mod_php and not for the better. So it seems
> today they're even speed wise, both completed at the same time. In
> years past when I ran this script I had much different results.

To really observe a measurable difference, run your tests using a
pool of non-TS PHP fcgi-sapi's.  Now that is some significant
performance gain, since all the crossthread locks are eliminated.

> I have now seen new light.

:)

Re: Building binaries and 3rd party dependencies

[Gregg Smith <gl...@gknw.net>]

On 2/15/2013 12:33 AM, William A. Rowe Jr. wrote:
> On Wed, 06 Feb 2013 14:26:33 -0800
> Gregg Smith<gl...@gknw.net>  wrote:
>> mod_fcgid alleviates both compiler/OpenSSL problems since it's
>> running php in it's own process true,  but at the cost of speed. I'm
>> not sure I would consider that "optimal," but it works!
> I'd like to counter some FUD - do you have a scrap of data to back
> up your claim?  Not a single PHP project member still endorses the
> mod_php plan as superior to a well balanced set of sapi-fcgi php
> client workers on unix.  Why Win32 folks think they would be special
> is beyond me.  Every dev I personally collaborate with, who measured
> performance, is solidly behind fcgid on Windows as well, except for
> a few PHP-Win32 project team participants.  I really am not sure
> what this is about, politically, but I'd love to see your data and
> test bench configuration.

Nothing political, it was from experience of years past when I was 
handed a benchmark script. I am eating crow here as I see nothing 
different when using fcgid from my test years ago. I am seeing different 
results in mod_php and not for the better. So it seems today they're 
even speed wise, both completed at the same time. In years past when I 
ran this script I had much different results.

I have now seen new light.

Gregg

Re: Building binaries and 3rd party dependencies

["William A. Rowe Jr." <wr...@rowe-clan.net>]

On Wed, 06 Feb 2013 14:26:33 -0800
Gregg Smith <gl...@gknw.net> wrote:
> 
> mod_fcgid alleviates both compiler/OpenSSL problems since it's
> running php in it's own process true,  but at the cost of speed. I'm
> not sure I would consider that "optimal," but it works!

I'd like to counter some FUD - do you have a scrap of data to back
up your claim?  Not a single PHP project member still endorses the
mod_php plan as superior to a well balanced set of sapi-fcgi php
client workers on unix.  Why Win32 folks think they would be special
is beyond me.  Every dev I personally collaborate with, who measured
performance, is solidly behind fcgid on Windows as well, except for
a few PHP-Win32 project team participants.  I really am not sure
what this is about, politically, but I'd love to see your data and
test bench configuration.

Cheers,

Bill

Re: Building binaries and 3rd party dependencies

[Gregg Smith <gl...@gknw.net>]

On 2/6/2013 8:14 AM, William A. Rowe Jr. wrote:
> That may or may not be an issue.  On Windows we can load both the PHP
> and mod_ssl flavors of OpenSSL at the same time if their dll names are
> unique.  Unless msvc resources opened in httpd are closed by mod_php
> or visa versa, two flavors of msvc can also coexist.  So mod_php aught
> to load and function although mod_fcgid is still more optimal.

In a perfect world, but the realities today seem to be different. Then 
again, only VC9 Apache binaries are able to run mod_php anyway.

mod_fcgid alleviates both compiler/OpenSSL problems since it's running 
php in it's own process true,  but at the cost of speed. I'm not sure I 
would consider that "optimal," but it works!

Gregg

Re: Building binaries and 3rd party dependencies

["William A. Rowe Jr." <wr...@rowe-clan.net>]

On Tue, 05 Feb 2013 16:43:13 -0800
Gregg Smith <gl...@gknw.net> wrote:

> 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.

That may or may not be an issue.  On Windows we can load both the PHP
and mod_ssl flavors of OpenSSL at the same time if their dll names are
unique.  Unless msvc resources opened in httpd are closed by mod_php
or visa versa, two flavors of msvc can also coexist.  So mod_php aught
to load and function although mod_fcgid is still more optimal.

> > 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.

I plan to give libxml2 a spin in apr for httpd 2.4, given that
mod_proxy_html requires that lib anyways.

Re: Building binaries and 3rd party dependencies

["William A. Rowe Jr." <wr...@rowe-clan.net>]

On Tue, 5 Feb 2013 23:47:03 -0600
"William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
> 
> > 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.
[...]
> > > 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.
> 
> > > 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.
> 
> I hope our consensus is that the httpd project is wrong and that the
> upstream is right.  Some of us hoped this would all go away, but some
> 2.4 RM's are quite insistent in producing already-stale -deps
> packages. And although the project voted to throw away distribution
> of any of the dep libraries, this all persists.  Leaves the few of us
> willing to help is a really obnoxious situation.

I am really looking for input from others, especially those who hope to
add other binary distributions again at httpd.  Not one tree I had to
remove was a permanent decision - they were simply too far out of date.
Any committer can add their platform under /dist/httpd/binaries/{arch}

If we plan to ship /dist/httpd/binaries/, the question I posed above
does demand a modern consensus.  Outside of the ASF, I never look at
any ASF distribution of a non-ASF component, but go straight back to
primary sources.  I'm asking, vis a vie 2.2, 2.4 and onwards, if this
is the group's desired approach for binaries/?  I really can't roll
one binary or help with autobuilds until this decision is made.

Re: Building binaries and 3rd party dependencies

["William A. Rowe Jr." <wr...@rowe-clan.net>]

On Tue, 05 Feb 2013 16:43:13 -0800
Gregg Smith <gl...@gknw.net> wrote:

> 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.

For 2.4?  Of course.  For 2.2?  That would seem to violate POLS.
[Pricipal of Least Surprise]

> > 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.

Either way, is apr expat at 2.1.0?  I'm not holding my breath.  APR only
recently bridged the gap with Nick's work at apr_xml integration of the
libxml2 lib.

> > 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.

Well, the impact is entirely on win32, whether we ship what isn't on
windows (and is an old version provided by the ASF in source) or what
isn't in windows (and was refreshed to the OEM/Project latest revision).

The only question from an RM/packaging PoV is that we might release, in
binary form, third party libraries which differ from the stale, packaged
source tarballs.  The ASF only releases source code.  So you see the
conundrum as a packaging manager?

I hope our consensus is that the httpd project is wrong and that the
upstream is right.  Some of us hoped this would all go away, but some
2.4 RM's are quite insistent in producing already-stale -deps packages.
And although the project voted to throw away distribution of any of the
dep libraries, this all persists.  Leaves the few of us willing to help
is a really obnoxious situation.

Thanks for the thoughts!

Bill

Re: Building binaries and 3rd party dependencies

[Gregg Smith <gl...@gknw.net>]

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