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