Philip Martin wrote on Fri, Jun 21, 2013 at 12:16:02 +0100: > Daniel Shahaf <danie...@elego.de> writes: > > >> --- subversion/trunk/Makefile.in (original) > >> +++ subversion/trunk/Makefile.in Fri Jun 21 08:35:37 2013 > >> @@ -912,5 +912,5 @@ INSTALL_EXTRA_TOOLS=\ > >> test -n "$$SVN_SVNMUCC_IS_SVNSYITF" && \ > >> ln -sf svnmucc$(EXEEXT) $(DESTDIR)$(bindir)/svnsyitf$(EXEEXT); \ > >> if test "$(DESTDIR)$(bindir)" != "$(DESTDIR)$(toolsdir)"; then \ > >> - ln -sf $(DESTDIR)$(bindir)/svnmucc$(EXEEXT) > >> $(DESTDIR)$(toolsdir)/svnmucc$(EXEEXT); \ > >> + ln -sf ../svnmucc$(EXEEXT) $(DESTDIR)$(toolsdir)/svnmucc$(EXEEXT); \ > > > > Shouldn't this read: > >> + ln -sf $(bindir)/svnmucc$(EXEEXT) > >> $(DESTDIR)$(toolsdir)/svnmucc$(EXEEXT); \ > > ? Otherwise, if someone changes 'toolsdir' or 'bindir', or makes > > 'svn-tools' a symlink, the symlink would be wrong or dangling. > > Change in what way? The user can configure a different bindir but > toolsdir is hardcoded as bindir/svn-tools. There is no way for a user
If someone changes the hardcoded values, then the relative symlink will break. It'd be more robust for the symlink to work without assuming a particular relationship between $toolsdir and $bindir (namely, that the latter is a child of the former). > to change toolsdir to something other than bindir/svn-tools. If we > change the hardcoded svn-tools subdir then the symlink will break but I > don't think that matters. My point wasn't that _we_ change the hard-coded value, it was the case that DESTDIR == "" and $bindir/svn-tools is a symlink. In that case the new code would install a broken symlink. > The real solution is for the svn-tools subdir > to go away and for install-tools to install the tools into bindir. I'm not sure we can do that in a patch release, so we still need another solution for 1.8.1. > Why did we ever think a subdir of bindir was a good idea? > > I suppose the user could set up a symlink for bindir/svn-tools before > running 'make install-tools', but the most likely symlink would be to > bindir itself and then no symlink is possible. Fair point, but it's orthogonal to what the destination of the symlink is decided to be. Cheers, Daniel
