<div class="gmail_quote">On Tue, May 31, 2011 at 02:25, Ben Walton <span dir="ltr"><<a href="mailto:bwalton@opencsw.org">bwalton@opencsw.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Excerpts from rupert THURNER's message of Mon May 30 16:08:35 -0400 2011:<br>
<br>
Hi Rupert,<br>
<div class="im"><br>
> You could separate out svnserve and other repository administration<br>
> *binaries* (svnadmin, svnlook, svndumpfilter) into a separate<br>
> package.<br>
<br>
</div>This sounds like a good idea. I've seen a few bug requests for it.</blockquote><div><br></div><div>stefan had the the convincing argument that we won't save any space on this as we need to deliver all the dependencies anyway as file:// needs to be supported see "libraries" below.</div>
<div><br></div><div>my personal favourite as svn client currently is git. no svn necessary at all. just three commands are necessary:</div><div><div> git svn clone <a href="https://whatever">https://whatever</a></div><div>
git svn rebase # update</div><div> git svn dcommit # commit</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> With the svn libraries it's a different story. You will want all of<br>
> them on both the client and server. This means you'll need most (and<br>
> probably all) dependencies on both sides.<br>
<br>
</div>This would be a good subversion-common package. Both the server and<br>
client packages could then depend on it.<br>
<div class="im"><br>
> I suppose the LDAP dependecy comes from berkeley DB? Subversion has<br>
> no direct dependency on LDAP.<br>
<br>
</div>Does checkpkg tell you it's a surplus dep? If so, you could just drop<br>
it. It may be pulled in via something else and not actually be<br>
required. I haven't looked at it though.<br>
<div class="im"><br>
> You could also take a look at how the Debian packages for Subversion<br>
> split things up. They probably have things split up as much as<br>
> reasonably possible.<br>
<br>
</div>It looks like a fairly monolithic setup there.<br>
<div class="im"><br>
> The files that don't compile with SUN's cc are generated by SWIG.<br>
> Can you figure out if it's possible to make SWIG generate code that<br>
> compiles with gcc as well as Sun's cc? If so we might be able to fix<br>
> your problem by changing the way we generate these files.<br>
<br>
</div>Might John's updated swig packages alleviate this? </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> <a href="http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/files/0001-make-subversion-sysconfigdir-as-it-should-be-for-csw.patch" target="_blank">http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/files/0001-make-subversion-sysconfigdir-as-it-should-be-for-csw.patch</a><br>
><br>
> That patch looks fine. If there is a pre-processor macro that<br>
> identifies a CWS build we could also include this change upstream<br>
> wrapped in the right #ifdef.<br>
<br>
</div>Aside from the fact that this should be handled by autoconf (or<br>
whatever build system they're using) instead of the way they're doing<br>
it, I agree that the current patch shouldn't be too onerous to<br>
support. If they use autoconf and you'd like a hand building a patch<br>
for that to make this sane, let me know.<br>
<div class="im"><br>
> <a href="http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/files/fixme.sh" target="_blank">http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/subversion/trunk/files/fixme.sh</a><br>
><br>
> This I don't really understand.<br>
<br>
</div>This may be replaceable by the 'STRIP_LIBTOOL = 1' capability that<br>
Mike introduced to GAR, but I'm not sure.</blockquote><div><br></div><div>STRIP_LIBTOOL is there as well.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> Note that as of Subversion 1.7 the build system will always use the<br>
> libtool program that was used to compile APR. This was done so we<br>
> could remove the configure script code for finding the right libtool<br>
> and let APR sort this out for us instead.<br>
<br>
</div>This should be a good change overall, I think. That will likely mean<br>
that it uses /opt/csw/bin/libtool (or whatever). It may be possible<br>
that the version of libtool changes between subversion releases though<br>
since it won't be in lockstep with apr.<br>
<div class="im"><br>
> I suppose the above is something with the fixme.sh gone wrong?<br>
> I've never seen an error like this.<br>
<br>
</div>I'd suspect the same thing.<br>
<br>
Hopefully some of my feedback is useful too.</blockquote><div><br></div><div>many thanks, much appreciated :) i tried removing fixme.sh, but it still goes wrong. let me copy the part out of libtool where it fails:</div>
<div><br></div><div><div> if test -n "$relink_command"; then</div><div> # Determine the prefix the user has applied to our future dir.</div><div> inst_prefix_dir=`$echo "$destdir" | $SED "s%$libdir\$%%"`</div>
<div><br></div><div> # Don't allow the user to place us outside of our expected</div><div> # location b/c this prevents finding dependent libraries that</div><div> # are installed to the same prefix.</div>
<div> # At present, this check doesn't affect windows .dll's that</div><div> # are installed into $libdir/../bin (currently, that works fine)</div><div> # but it's something to keep an eye on.</div>
<div> if test "$inst_prefix_dir" = "$destdir"; then</div><div> $echo "$modename: error: cannot install \`$file' to a directory not ending in $libdir" 1>&2</div>
<div> exit $EXIT_FAILURE</div><div> fi</div><div><br></div><div> if test -n "$inst_prefix_dir"; then</div><div> # Stick the inst_prefix_dir data into the link command.</div>
<div> relink_command=`$echo "$relink_command" | $SP2NL | $SED "s%@inst_prefix_dir@%-inst-prefix-dir $inst_prefix_dir%" | $NL2SP`</div><div> else</div><div> relink_command=`$echo "$relink_command" | $SP2NL | $SED "s%@inst_prefix_dir@%%" | $NL2SP`</div>
<div> fi</div></div><div><br></div><div><br></div><div><br></div><div>kr, rupert.</div><div><br></div><div><br></div></div>