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