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

Bug#407115: marked as done (mktexlsr called to often in postin of tetex-base)

Your message dated Tue, 17 Aug 2010 11:25:44 +0900
with message-id <[🔎] 20100817022544.GS26638@gamma.logic.tuwien.ac.at>
and subject line Re: Processed: reassign, merge
has caused the Debian Bug report #407115,
regarding mktexlsr called to often in postin of tetex-base
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
407115: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407115
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: tetex-base
Version: 3.0.dfsg.3-5
Severity: wishlist

Hi all,

once again to submit@b.d.o.

I'm filing that as wishlist now, after asking for it a few month ago.
Maybe you did change the code since then and I did not notice. If
this is the case, please complain.

I upgraded my tetex-base package and noticed the following:

<snip>
Setting up tetex-base (3.0.dfsg.3-1) ...

mktexlsr: Updating /usr/local/share/texmf/ls-R...
mktexlsr: Updating /var/lib/texmf/ls-R-TEXMFMAIN...
mktexlsr: Updating /var/lib/texmf/ls-R-TEXMFDIST-TETEX...
mktexlsr: Updating /var/lib/texmf/ls-R...
mktexlsr: Done.
Running updmap-sys. This may take some time... done.

mktexlsr: Updating /usr/local/share/texmf/ls-R...
mktexlsr: Updating /var/lib/texmf/ls-R-TEXMFMAIN...
mktexlsr: Updating /var/lib/texmf/ls-R-TEXMFDIST-TETEX...
mktexlsr: Updating /var/lib/texmf/ls-R...
mktexlsr: Done.
Running fmtutil-sys. This may take some time... done.
mktexlsr: Updating /usr/local/share/texmf/ls-R...
mktexlsr: Updating /var/lib/texmf/ls-R-TEXMFMAIN...
mktexlsr: Updating /var/lib/texmf/ls-R-TEXMFDIST-TETEX...
mktexlsr: Updating /var/lib/texmf/ls-R...
mktexlsr: Done.
</snip>

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 between updmap-sys and fmtutil-sys?

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

Further additions coming from Frank and Florent:

<Frank>
> 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?

If a pdftex format includes font information, would it need a map file?
I don't think so.
</Frank>

<Florent>
> 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).
</Florent>

<Frank>
No, I don't think it has changed in teTeX.  I think that TeXlive
behaves more clever here, but I'm not sure.

I don't think it's worth to fix this in teTeX - personally I do not
plan any more uploads except those targetted at etch.  But for the
TeXLive packages, we should take care for optimization.
</Frank>

Thanks,
  Hilmar
-- 
sigfault

--- End Message ---
--- Begin Message --- 
On Mo, 16 Aug 2010, Debian Bug Tracking System wrote:
> > merge 407115 485866
> Bug#407115: mktexlsr called to often in postin of tetex-base
> Bug#485866: texlive-base-bin: mktexlsr in postinst: potential triggers candidate?
> Merged 407115 485866.

??? mktexlsr is already a triggered action. There is not more that can be
done by now.

Closing these bugs.

Best wishes

Norbert
------------------------------------------------------------------------
Norbert Preining            preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan                                 TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
PIMPERNE (n.)
One of those rubber nodules found on the underneath side of a lavatory
seat.
			--- Douglas Adams, The Meaning of Liff

--- End Message ---
Reply to: