[tex-live] Fwd: files generated by fmtutil/updmap -- platform independent?

Manuel Pégourié-Gonnard mpg at elzevir.fr
Mon Aug 23 01:16:05 CEST 2010

Le 23/08/2010 00:43, T T a écrit :
> On 22 August 2010 19:10, Manuel Pégourié-Gonnard <mpg at elzevir.fr> wrote:
>> I'm not sure about map files, so I won't discuss them. Concerning ls-R files, at
>> first glance, it seems doable to update them without re-scanning the whole tree,
>> which is indeed quite expensive due to disk access. Actually, one could even
>> imagine generating the ls-R files for TEXMFMAIN and TEXMFDIST from texlive.tlpdb.
> The same thought occurred to me (except I thought about using .tlpobj files).
Yep, on install the .tlpobj files can be used, but on removal we don't have them
any more. Anyway, the data in the tlpobj and in the tlpdb are hopefully the same :-)

>> The main problem could be people changing files here and manually running
>> mktexlsr afterwards. We can't always assume people do things the right way.
> That wouldn't be a problem if done with explicit switch to mktexlsr,
> like --add-tlpobj foo.tlpobj.  But this only makes sense if we finally
> get around to rewrite mktexlsr in Perl.  Then we could reuse our TL
> modules and perhaps end up with a nice and concise implementation
> (although, probably not as concise as ~20 lines long ;)

> Right.  It would make sense to do some measurements first to see where
> the actual bottlenecks are and how much the can be optimized.

I'm not against the idea of doing measurements, but as far as ls-R files are
concerned, I'm pretty sure any solution working at an abstract level (that is,
patching the file) will be orders of magnitude faster than walking a tree of
circa 100 000 files in 7 000 directory doing actual stat()s and readdir()s.

Concerning updmap, I have no opinion (yet), as I stated earlier.

>  The
> whole thing might turn out just not worth it.  On my (partial) TL
> installation running updmap & fmtutil -all & mktexlsr takes 10 sec
> (warmed up) and a few sec more on cold system, so speed was never an
> issue for me.
On my old server (P3 600, slow disks) mktexlsr alone takes a bit more than 1
minute, and that is for TL2007, 2010 is quite bigger.

>> By the way, the formats (fmt files) definitely need to be regenerated (I'm
>> probably stating the obvious, but anyway).
> It's not obvious to me, but I never really looked into this.
I mean, *when* something concerning the formats is changed, the only way to
handle that is to regenerate the formats, patching them like we would patch the
ls-R files is not an option. (Binary files, engine-dependent format, etc.)


More information about the tex-live mailing list