Re: expat upgrade to 2.1.0

[Michael Felt <ma...@gmail.com>]

On 2015-09-08 12:50, Stefan Hett wrote:
> Hi,
> a while ago I've been pointed by Bert to the fact that APRUtil 1.5.4
> includes Expat 1.95.7 which is rather old (from October 2003). According
> tohttp://www.libexpat.org/  there has been another 1.95 release with
> mostly bugfixes (1.95.8 in July 2004) and the latest one is 2.1.0 (from
> March 2012).
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.

>
> Especially in light of 2.1.0 incorporating several security fixes, Bert
> suggested that I upgrade Expat to the latest version.
>
> I'm wondering whether it wouldn't be useful if APRUtil would update its
> Expat integration directly. Originally I planned to provide a patch for
> that, but after checking things out I realize that it'd take me a
> significant amount of time (especially since I'd have to check/test the
> Linux integration) to bring the patch up to a quality which could be
> accepted.
>
> I also read that there are plans for APR 2 to incorporate APRUtil
> directly and drop the direct integration of Expat. Nevertheless, I think
> that APR-Util 1.5.x will still be around for several years, it might
> still serve a purpose to upgrade Expat in 1.5.x.
>
> In case that helps, I've put together the patch I'm using to upgrade
> Expat in APRUtil for building Apache HTTP & SVN on Windows to this
> issue:http://www.luke1410.de:8090/browse/MAXSVN-1
> In principle it's just copying over the files from Expat 2.1.0 following
> the description from glsmith here:
> https://www.apachelounge.com/viewtopic.php?t=5416  .
> Only some tweaks were made to keep some of the APRUtil specific changes
> I spotted.
>
> Please note that this was only tested in my own build environment and
> only on Windows. It certainly won't work on Linux as is.
>
> Regards,
> Stefan
>

Re: expat upgrade to 2.1.0

[Branko Čibej <br...@apache.org>]

On 31.10.2015 18:48, Michael Felt wrote:
> I would vote to make external expat the default and/or just remove
> expat from apr.

That's already been done on trunk (which will become 2.0) but is not
something we can backport to the 1.x line, IMO.

-- Brane

Re: expat upgrade to 2.1.0

[olli hauer <oh...@gmx.de>]

On 2015-10-31 18:48, Michael Felt wrote:
> On 2015-09-08 12:50, Stefan Hett wrote:
>> Hi,
>> a while ago I've been pointed by Bert to the fact that APRUtil 1.5.4
>> includes Expat 1.95.7 which is rather old (from October 2003). According
>> tohttp://www.libexpat.org/  there has been another 1.95 release with
>> mostly bugfixes (1.95.8 in July 2004) and the latest one is 2.1.0 (from
>> March 2012).
> 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.
> 

In case you build apache from source, there is already an option to build apr-util against expat-2.0.1, no need to change the bundled one.
Use `--with-expat=$path/to/libexpat' as configure arg to apr-util and you are done.

I suspect most every distribution / project building binary packages will overwrite the bundled expat explicit.
E.g. FreeBSD [1], RHEL (and derivates like CentOS and ScientificLinux [2]).

[1] https://svnweb.freebsd.org/ports/head/devel/apr1/Makefile?view=markup
[2] http://ftp1.scientificlinux.org/linux/scientific/7x/SRPMS/vendor/apr-util-1.5.2-6.el7.src.rpm

-- 
HTH,
olli

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.

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

Re: expat upgrade to 2.1.0

[Graham Leggett <mi...@sharp.fm>]

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.

Regards,
Graham
—