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

[Manuel Pégourié-Gonnard]

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 ;)
> 
Yep.

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

Manuel.