apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: Fwd: Prior to apr 2.0 / httpd 2.4...
Date Tue, 22 Mar 2011 00:42:37 GMT
On Mon, Mar 21, 2011 at 20:04, William A. Rowe Jr. <wrowe@rowe-clan.net> wrote:
> On 3/21/2011 6:06 PM, Greg Stein wrote:
>...
>> Even if I dropped a new release of Expat, would we want to rely on the
>> external build (and latest release being propagated) or continue to
>> ship a patched Expat within APR?
>
> 'build' - you mean package?  Yes, we default to an external apr today
> if one is found.  With none detected, ./configure works up apr's distro.
>
> For 2.0 I'd like to see us shift our expectation if we build in tree,
> to expat/ sitting in parallel to apr/ - but that's minor.  It would
> allow downstream users to either bundle or leave expat 2.0.2 unbundled
> and apr project wouldn't have to worry about new security issues at
> some point in the future when 0.9/1.x are less frequently distributed.

Oh, I'm all for unbundling. I think it is mostly about whether APR
wants to bundle the "best" Expat rather than potentially linking
against a non-secure version. Of course, I guess that could happen
today. Maybe we could simply detect the Expat version and provide a
warning ("hey! get 2.0.2. we'll go with this, but you should update.")


>> Switching to libxml2 would be possible (it is MIT licensed), but would
>> require a lot more coding work in the xml support. Users of APR (1.x)
>> also depend on Expat being available, and a switch would require them
>> to rewrite their XML parsing code. Maybe that is acceptable for apps
>> to switch to 2.0?
>
> Of course those users could continue to link to expat.  Are you saying
> they doing cross apr<>expat manipulation?  That sounds as unsound as our
> current ldap practices.

As a concrete example: Subversion directly uses the Expat APIs. We
depend upon apr-util to find/provide those APIs by including expat
into its exported link switches, or to compile/bundle Expat directly
into the apr-util library. That allows Subversion to skip a whole
bunch of config-time logic to locate/link against Expat.

Applications that expect this kind of behavior ("find me Expat") would
need to be be recoded to discover Expat for themselves. And/or
discover libxml2.

>...
>> In short: I can make a release happen, but would that matter to the APR project?
>
> It matters to expat from a credibility perspective, and it allows httpd to
> toss in 2.0.2 expat sources into their srclib/ distribution.  I don't know
> that apr cares.

Alrighty. Thanks.

Cheers,
-g

Mime
View raw message