[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: mktexlsr called to often in postin of tetex-base?



Hi,

Hilmar Preusse <hille42@web.de> wrote:

> i.e. we're calling mktexlsr 3 times. I understand that we have to call
> before updmap-sys and after fmtutil-sys, but do we really have to
> call betwenn updmap-sys and fmtutil-sys?

The first two calls to mktexlsr can be somehow justified by the
recommended (at least by me!) sequence to use whenever you update map
files (resp. format files):

  update-updmap
  mktexlsr
  updmap-sys

resp.

  update-fmtutil
  mktexlsr
  fmtutil-sys

But it's true that when both operations are done in a row, the second
mktexlsr call is useless in most cases. The only case I see where it
makes a difference is if the update-fmtutil call *creates* fmtutil.cnf,
instead of updating it. Which can happen, though not very frequently.

As for the third call, after fmtutil-sys, I think this one is really
useless, because near the end of main(), fmtutil-sys has the following
code:

  for i in *.fmt *.mem *.base; do
    test -f "$i" || continue
    rm -f "$destdir/$i"

    # We don't want user-interaction for the following "mv" command:
    if mv "$i" "$destdir/$i" </dev/null; then
      verboseMsg "$progname: $destdir/$i installed."
      $mktexfmtMode && echo "$destdir/$i"
    fi
    mktexupd "$destdir" "$i"
  done

Just as with updmap(-sys), Thomas Esser was careful to have fmtutil-sys
register the files it creates in the ls-R database.

> IMHO there is room for optimization. If not, please explain.

Yes, there is room IMHO too. However, calling mktexlsr does not take
*very* long, so we won't gain that much. Still, 0.5 second or so on my
system for non-first runs (later runs are faster than the first one due
to the caching performed by the kernel).

> P.S.: Can I assume that debian-tetex-maint is dead? Actually I see
> only spam coming over this list. The last good poster was Moshe, who
> had debian-tex-maint in Cc.

It's dead. AFAIK, the only recent traffic on this list came from:
  - bugs -tetex-maint is still subscribed to;
  - me (only one mail sent to -tetex-maint and not -tex maint, thanks
    to Frank who noticed that) because I had forgotten to update a
    parameter in my Gnus configuration.

Regards,

-- 
Florent



Reply to: