Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of nkadel@gmail.com designates
 209.85.160.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAOCN9ryt0=HVU2k8A1r3nfFNxUrZqdFqHTZk=QUfiiQojxae1A@mail.gmail.com>
References: 
 <CAOCN9ry8yia2K1URt75doE3ifypEGgn4cuyRjSZDaB69DLUWig@mail.gmail.com>
	<20120816225526.GA13364@tarsus.local2>
	<CAOCN9ryt0=HVU2k8A1r3nfFNxUrZqdFqHTZk=QUfiiQojxae1A@mail.gmail.com>
Date: Thu, 16 Aug 2012 23:13:12 -0400
Message-ID: 
 <CAOCN9rz4d_Y-3raUu8oN-uZ=0rtZOtNDAWvis8soXsxwdxA1Qw@mail.gmail.com>
Subject: Re: mod_dontdothat RPM building problems with subversion-1.7.6
From: Nico Kadel-Garcia <nkadel@gmail.com>
To: Daniel Shahaf <d.s@daniel.shahaf.name>
Cc: Subversion <users@subversion.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Aug 16, 2012 at 10:38 PM, Nico Kadel-Garcia <nkadel@gmail.com> wrote:
> On Thu, Aug 16, 2012 at 6:55 PM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>> Nico Kadel-Garcia wrote on Thu, Aug 16, 2012 at 01:31:11 -0400:
>>> On Wed, Aug 15, 2012 at 7:52 AM, Philip Martin <philip@apache.org> wrote:
>>> > I'm happy to announce the release of Apache Subversion 1.7.6.
>>> > Please choose the mirror closest to you by visiting:
>>> >
>>> >     http://subversion.apache.org/download/#recommended-release
>>>
>>> Cool. I'm poking at getting a 1.7.6 SRPM set up for it. I am noticing an issue.
>>>
>>
>> In the future you may consider testing the packaging when the tarballs
>> are posted for developer testing, rather than only after their public
>> release.  (at which point they can no longer be pulled)
>
> Sorry, Daniel: I was busy on one contract until July 31 and just
> started a new one Monday.
>
>>> * Make mod_dontdothat.so installable from the Makefile. The easiest
>>> way to do it is to move it to from "tools" to "subversion", parallel
>>> to subverson/mod_dav_svn, and as a loadable httpd module, it requires
>>> special attention.
>>>
>>> * Make the other Subversion tools installable. It should be
>>> straightforward to make the other contents of the "tools" directory
>>> compiled and instlalled into the 'toolsdir', typically
>>> /usr/local/bin/svn-tools, defined in the Makefile.in. It's not
>>> currently used in subverson-1.7.x, but is used in the trunk for the
>>> "svnmucc" tools.
>>
>> Are you aware of 'make install-tools'?
>
> I looked in the Makefile and didn't see it, unlike 'install-man",
> "install-swig-rb", etc. But sure enough, it works. Gotta love
> sophisticated and impliciit components of Makefiles. Thanks for the
> pointer!
>
> Is there some reason it's not included in the default "install" list of targets?
>
>> If you want to add targets to install individual tools, too, I imagine
>> we would welcome a patch for this (but I won't have time to handle it
>> myself).  See the 1.7.5->1.7.6 diff for most of the files you'll need to
>> touch (makefile.ezt and co).
>
> That's potentially useful, but doens't fix the problem where the built
> components are in "tools" are

Gahh, got cut off and hit the wrong key. The built components in the
"tools" directory include a number of binaries, not appropriate to
docs, and filtering out what should go in in "docs" after it's already
built is awkward. What I can do easily is a hack in the .spec file:
replicate "tools" to "tools-doc" before compilation, and include
"tools-doc" as documentation for a distinct "tools" package that also
includes the binaries  intalled with 'make instlal-toole". It's a bit
funky, but will generate a clean build.