Re: expat upgrade to 2.1.0

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

On Sun, Nov 1, 2015 at 12:59 PM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:

> On Sun, Nov 1, 2015 at 12:16 PM, Graham Leggett <mi...@sharp.fm> wrote:
>
>> On 31 Oct 2015, at 7:48 PM, Michael Felt <ma...@gmail.com> wrote:
>>
>> > I would like to repspond positively on this suggestion that "something"
>> be done.
>> > It could be updated, and fortunately expat is not a package with
>> frequent (security) updates,
>> > but it is external. What may have been good before is perhaps not as
>> correct anymore.
>> >
>> > a) expat needs to be closer to mainstream: there are many features
>> > in expat that have been introduced since then.
>> > The embedded expat is not packaged as an internal (aka static) library
>> - but appears as a separate library.
>> >
>> > I ran into this problem when packaging something else that needed the
>> latest and greatest (i.e., 2.0.1 as base).
>> >
>> > My solution is to repackage apr, apr-util and httpd after removing
>> > the internal expat - so that I have latest and greatest for both - and
>> can update it,
>> > in principle - separate from apr.
>> >
>> > I would vote to make external expat the default and/or just remove
>> expat from apr.
>>
>> Unfortunately our version rules forbid the removal of expat from
>> APR(-util) v1.x, as this would break APR for people who are using expat
>> already.
>>
>> Adding the option to link to an external expat is definitely an option,
>> on condition there is a backwards-compatible guarantee on behaviour from
>> the APR library.
>>
>
> Philosophically, we cannot remove apr_xml functionality or compatibility,
> and we don't change build options across subversion bumps (1.5.x to 1.5.y
> is always expected to 'just work'), but there is precedence for changing
> the build schema between minor versions, as long as the resulting apr still
> offers backwards binary compatibility, and we document in CHANGES.
>
> E.g. we could remove expat from the bundle of 1.6.0, and insist the user
> obtain this themselves, either the final expat 0.9 or a later expat 2.1
> depending on the level of sub-dependency compatibility they require.  They
> even have the option of pick libxml2 if none of their code has a dependency
> on entry points in expat itself (we never made such a promise, and that
> goes for openssl, ldap, etc).
>
> We've long supported expat 2.  I don't think I've built from apr's expat
> sources since the mid null'sies.
>
> But it won't be removed from apr 1.5.next, for the reasons Graham points
> out.
>

And to reiterate my point, Graham incorrectly suggests that we have some
binary
contract with our users to support 100% binary compatibility with every
entry point.
That is not true.

We have a contract to maintain 100% binary compatibility in our public
interface.
What happens underneath that public interface is entirely subject to
change, even
between subversion bumps (except in the odd instance that we have buried our
own private interface in a compile-time symbol resolution in the consumer's
executable object).

I've asserted that we have an obligation between subversion bumps to never
disrupt the consumer's build schema. If one takes a minor or major package
bump, you expect that the build flags, toggles, dependencies etc are all
subject to change.  Jumping from 1.5.4 to 1.5.5 you cannot be expected to
rework all of your build wiring to accommodate an arbitrary project change
to their build schema.

So let's simply drop this from branches/1.6.x and be done with it, provide
advise on http://apr.apache.org/ that users should obtain the latest (now
2.2.0)
release directly from the expat project.

Re: expat upgrade to 2.1.0

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

On Wed, Aug 10, 2016 at 3:22 PM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:

> On 31 Oct 2015, at 7:48 PM, Michael Felt <ma...@gmail.com> wrote:
>>> >
>>> > I would vote to make external expat the default and/or just remove
>>> expat from apr.
>>>
>>
> So let's simply drop this from branches/1.6.x and be done with it, provide
> advise on http://apr.apache.org/ that users should obtain the latest (now
> 2.2.0)
> release directly from the expat project.
>

Actually, for apr-util 1.5.x, there is the alternative of libxml2, which
would be
interesting for anyone who requires that full functionality for
mod_proxy_html
and similar. Has anyone given that alternative some real-world exercise and
determined how it fares in reliability or performance? That could also be
mentioned on the front page of the apr website.