as the python bindings did not compile for more than 6 months, I commented them for the first try of svn-1.7. but I d have a bad feeling if we let this package further than unstable. any help to sort out that build error is greatly appreciated.
rupert On Jun 2, 2011 10:06 PM, "rupert THURNER" <[email protected]> wrote: > 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. ::.
