On 7/15/06, Max Bowsher <maxb1@ukf.net> wrote:
> Oh. I think we need a third party to intervene here - I think its pretty
> clear we are never going to reach an agreement just between the two of us.
>
> To my perspective, the above usage is just taking advantage of a bug.
> I note that autogen.sh only buildconfs apr and apr-util - which is
> inconsistent, as it doesn't try to handle neon.
I don't think I have presented anything other than actual arguments
against the change: we have supported this setup for years and we
shouldn't break things silently. How am I being unreasonable? I
don't view changing our INSTALL requirements as something that should
be done hastily.
The responses have been that this code is "long obsolete" and a "bug"
- neither of which are true statements - it was intentional (present
since at least r1) and worked just fine until this change was made. I
suggested one such fix to resolve my veto. If you don't like that
suggestion, then you are more than welcome to come up with an
alternative to resolve it.
Back to the matter at hand: on second thought, I do think we may want
to keep this code even if it's not a SVN checkout because of the
impact this has for people using SVN releases with bugs in autoconf
and libtool - therefore, we have often recommended that they re-run
./autogen.sh to pick up local fixes. This would now complicate the
process for them slightly. So, I believe the right fix may now be to
dist.sh not autogen.sh - i.e. install the release tarballs of
apr/apr-util *after* autogen.sh is run instead of beforehand. (BTW,
neon isn't a required dependency, so I don't view its omission as
particularly noteworthy.)
I am always willing to discuss any other compromises that you'd like,
but I'm against removing this 'bug'. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 15 20:23:10 2006