sounds good to me. I've built recent versions of subversion on RHEL7 and it
is a right pain in the neck, chasing those dependencies down to serf,
especially since the last time I looked serf depended on python2 instead of
python3. Your proposal gets my vote, FWIW.
On Wed, 16 Sep 2020 at 22:14, Julian Foad <julianfoad_at_apache.org> wrote:
> Dear devs,
>
> I propose a patch restoring support for APR 1.4 so that svn 1.14 can be
> built and packaged on CentOS 7.
>
> The WANdisco folks continue to package svn for a variety of target
> systems. Packaging for CentOS 7 which has APR 1.4.8, they ran into the
> problem that just before svn 1.14.0 we bumped the dependency requirement
> to APR 1.5.0 and removed support for older APR versions.
>
> Here's the change we made:
> > r1874094 | jamessan | 2020-02-17 03:49:42
> > Require at least version 1.5 of APR
> >
> > Since r1874057, the apr_pescape_shell() API is being used to escape
> filenames
> > when invoking $SVN_EDITOR. This was added to APR in 1.5.0, released on
> > 2013-11-13.
> >
> > * INSTALL
> > (): Document new minimum APR version
> >
> > * build/generator/gen_win_dependencies.py
> > (_find_apr): Bump minimal_apr_version to 1.5.0
> >
> > * configure.ac
> > (APR_VER_REGEXES): Bump minor version in 1.x regex to 1.5
> >
> > * get-deps.sh:
> > (APR_VERSION): Specify 1.5.0 as default version
> >
> > * subversion/include/private/svn_dep_compat.h
> > (apr_time_from_msec): Removed, since it's provided by APR 1.4.0 or
> later
> >
> > * subversion/include/svn_types.h
> > (apr_hash_this_key, apr_hash_this_key_len, apr_hash_this_val): Remove
> > prototypes, since they're provide by APR 1.5.0 or later
> >
> > * subversion/libsvn_subr/iter.c
> > (hash_do_baton): Remove condition requiring APR 1.4.0 to define this
> type
> > (svn_iter_apr_hash): Remove pre-APR 1.4.0 code
> > (apr_hash_this_key, apr_hash_this_key_len, apr_hash_this_val): Remove
> > definitions, since they're provided by APR 1.5.0 or later
> >
> > * subversion/libsvn_subr/pool.c
> > (apr_pool_create_unmanaged_ex): Remove conditional alias to
> > apr_pool_create_core_ex, for APR versions < 1.3.3
>
> The context is we'd recently started using apr_pescape_shell() in
> r1874057, shortly afterwards changing to using apr_escape_shell()
> instead, and those escaping functions are new in 1.5.0.
>
> Ian at WANdisco told me:
> > The dependencies we have issues with are apr and apr-util as 1.14
> requires at least APR 1.5 and Red Hat ship 1.4.8 in EL7. I tried ignoring
> the version and using the old apr but it doesn't compile due to some
> missing symbols.
> >
> > Because of this if we want to ship any 1.14 build for EL7 we have to
> build our own (later) APR and APR-Util packages which in turn means libserf
> and apache httpd would need to link against these too.
>
> They are looking for a more self-contained solution.
>
> I propose adding support more or less as in the attached patch. It:
>
> - reverts r1874094, thus restoring the support we had for APR 1.4
> (and even 1.3 by the look of it), but we never had backward
> compatibility support for apr_escape_shell();
>
> - adds a local copy of the 'apr_escape_shell()' function, copied
> from APR 1.7.0.
>
> One adjustments is needed before this is ready to commit: I must make
> the 'apr_escape_shell' part conditional on APR version. Note also that
> the support for 'apr_escape_shell()' adds 4 files, as that's how the
> code was laid out in APR. We could combine them but I preferred to copy
> it as exactly as possible.
>
> If this is an acceptable approach, I would propose it for backport to a
> 1.14.x point release.
>
> WANdisco would prefer to package our upstream svn source release exactly
> rather than patch it in their packaging, and that is why I am proposing
> adding this support.
>
> Of course I understand that APR pre-1.5 is pretty old and the argument
> to not complicate the current code with too much backward compatibility
> support code. So the question is whether this is too much or whether
> supporting building on distros like CentOS 7 out of the box is the
> better option.
>
> - Julian
>
--
Regards,
Andrew Marlow
http://www.andrewpetermarlow.co.uk
Received on 2020-09-17 12:54:44 CEST