Philip Martin wrote on Fri, Jun 21, 2013 at 12:16:02 +0100:
> Daniel Shahaf <danielsh_at_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
Received on 2013-06-21 13:25:16 CEST