Bug#139054: [ray.miller@computing-services.oxford.ac.uk: texlinks patch]

[Ray Miller <raym@herald.ox.ac.uk>]

On Tue, Mar 19, 2002 at 10:33:55PM +0100, Thomas Esser wrote:
> > On Tue, Mar 19, 2002 at 06:45:55PM +0100, Thomas Esser wrote:
> > > >  a) not return an error if upd_symlinkdir fails
> > > 
> > > The job of texlinks is to create the appropriate symlinks. Why should
> > > it not return an error in this case?
> >
> > because its not an error. it just means this stage is not needed
> 
> I still have no clue. What exactly makes links return that unwanted
> error?

On my system (Debian woody), $selfautoloc is the same directory as
$symlinkdir, so the search_symlinkdir() function returns 1 from the
branch I've marked "#XXX":

search_symlinkdir()
{
  kpsewhich=`check_for_binary kpsewhich`
  test -z "$kpsewhich" && return 1
  symlinkdir=`echo $kpsewhich | sed 's@/*kpsewhich$@@'`
  access -w "$symlinkdir" || return 1
  touch "$symlinkdir/tl$$"
  if test -f "$selfautoloc/tl$$"; then
    rm -f "$symlinkdir/tl$$"
    return 1 #XXX
  else
    rm -f "$symlinkdir/tl$$"
    return 0
  fi
}

This is called from upd_symlinkdir():

upd_symlinkdir()
{
  search_symlinkdir || return #XXX
  for i in `sed 's@ .*@@' cnf_file_ln.$$`; do
    install_link "$selfautoloc/$i" "$symlinkdir/$i"
  done
}

...which is the last thing called from main(). Consequently, the
script exits 1. However, this was not an error condition - symlinkdir
did not need updating. This would not normally be a problem, but the
texlinks script is invoked by a Debian post-install script which
interprets exit 1 as something bad happening. Changing the first line
of upd_symlinkdir() to:

  search_symlinkdir || return 0

fixes this problem.

The second problem is more subtle, and I agree with you that my patch
does the wrong thing. For a reason I have yet to determine, the line

test "x$src" != "x`(ls -ld $src | awk '{print $NF}') 2>/dev/null`" &&
    verbose_do rm -f "$src";

was not removing a pre-existing symbolic link. I'll see if I can
reproduce this error and determine how it was triggered.

-- 
Ray Miller, Systems Programmer & Team Leader
Unix Systems Group, Oxford University Computing Services