On 25.08.2015 17:31, Stefan Fuhrmann wrote: > On Tue, Aug 25, 2015 at 12:55 PM, Branko Čibej <br...@wandisco.com> wrote: > >> On 25.08.2015 13:49, br...@apache.org wrote: >>> Author: brane >>> Date: Tue Aug 25 11:49:09 2015 >>> New Revision: 1697654 >>> >>> URL: http://svn.apache.org/r1697654 >>> Log: >>> * branches/1.9.x/STATUS: >>> - Approve r1693886. >>> - Temporarily veto r1694481; the change looks broken. >> [...] >> >>> @@ -98,5 +84,22 @@ Candidate changes: >>> Veto-blocked changes: >>> ===================== >>> >>> + * r1694481 >>> + Fix Unix build on systems without GPG agent. >>> + Justification: >>> + This is a user-reported issue. >>> + Votes: >>> + +1: stefan2, philip >>> + -1: brane (You can't just remove a public API implementation, >>> + even if it is deprecated. And the prototyps is still >>> + right there in svn_auth.h) >>> + >>> Approved changes: >>> ================= >> r1694481 (conditionally) removes the implementation of a public API, >> whilst leaving the prototype in svn_auth.h untouched. This is a >> violation of our ABI compatibility rules, and also a linking error >> waiting to happen. >> > Except that the very problem is that > svn_auth__get_gpg_agent_simple_provider > is not implemented either if SVN_HAVE_GPG_AGENT > is not defined. And that linker problem is the one being > already reported and fixed by the patch. > > You are still right that we introduce another linker problem > further down the road for some people that stumbled > across the first one in the past. And not implementing > the public API is a bad thing. > > So, I think we need to do some coding to fix this on /trunk. > Question is whether we want to skip r1694481 as a stop- > gap patch for 1.9.1 and enable people to build SVN again.
Daniel suggested inserting a dummy handler if we don't have the GPG agent support. I think that may be the only reasonable solution for both trunk and 1.9.1 (or .x if we don't thing it's important enough for .1). The real effort here is double-checking that a dummy handler won't break credentials resolution. -- Brane