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

[Marc Espie]

> From: Norbert Preining <preining at logic.at>
> Date: Sat, Aug 21, 2010 at 4:18 AM
> Subject: Re: [tex-live] files generated by fmtutil/updmap -- platform
> independent?
> To: Edd Barrett <vext01 at gmail.com>
> Cc: tex-live at tug.org
> 
> 
> On Fr, 20 Aug 2010, Edd Barrett wrote:
> > This is what we want to try and avoid, as for users on slow machines (some crazy
> > people use texlive on their PDAs) it takes forever.
> 
> Ouchhh.... wellll
> 
> > Seeing as we only have 2 texmfs that would install any fonts, I hope to be able
> > to pre-generate the 2 configurations for those (along with ls-R etc...). Any
> > further comments on this?
> 
> If there are only two packages and you can make sure that always the
> right updmap.cfg or better psfonts.map is installed, then it can work out.
> 
> But what if other users/system admins want to install their private fonts?
> 
> Imagine a department with University/company specific fonts that need
> to be activated? This *IS* a real situation I have seen myself several
> times.
> 
> Think about possible usage szenarios.
> 
> In the above case I would prepare on more package
>        texlive-pda
> or so where no changes are possible, but for the rest I would allow some
> dynamic adaption.
> 
> Otherwise you will get flooded with bug reports:
>        How do I activate a font map file?
>        I want to get rid of the TeX Live installed beellek fonts?
>        TeX doesn't find our department fonts?
> ...

I think you guys have things wrong, from a packaging point of view.

In the current world, most people install texlive from packages made
by their distributors.   The way things are organized corresponds to
a view of the Unix world that went out of favor 10 years ago.

The current script organization is a "lazy" view, you run all kinds of
stuff during the actual installation of the package. There are two
operations at work:
1/ scanning a set of files to generate map/ls-R/whatever information.
2/ store that information on the local machine.

On *any* machine which runs with prebuilt packages, doing the first operation
during install is a complete waste of time.

Heck, the texlive packages are huge, it already takes some time to extract
it, then (get this), when you run updmap and mktexlsR, it takes *almost as
much time* to finish the installation.d

This is a total disgrace, most of this information should be auto-generated
during packaging.

How about this:
- during packaging, scan information *relevant to the package at hand* and
store it in the package (as a partial map/partial ls-R), in a specific
place (say a given directory).
- during install, after doing each and every package, just merge those
partial maps together, and create the "final" map files and ls-R.

If an admin has his own files, well, he can run those tools to generate
those partial maps, and have them picked up during installation/update.

I'm pretty sure this is not even hard-to-do, you would just have to
figure out a place to dump partial information, and extend the tools
slightly to separate the scanning/merging/creating map information.

I'm pretty certain that *you can get rid of 99% of the time spent running
special commands* during install for the end user.  This makes a huge
difference for people wanting to run texlive on small netbooks (or
zaurii), and will even be useful for people with fast machines.

Even if the admin has his own files, this is totally dwarfed by the total
size of the texlive installation. Generating those map *once* during packaging
is a huge gain.