[tex-live] Bug in updmap?!

[Fabrice Popineau]

> out, which isn't solved by shouting at Gerben. Both you and Gerben
> have a tendency to get angry and shout at people, but I don't think it
> ever helps.

I won't deny it. And you  know that I'm fed up with the way
things are going for many months now.

> For what its worth, yes, I know I have in the past been as emotional
> as you and Gerben, with an equal desire to blame someone :-}

But I'm definitely not looking for  someone to blame. 

I'm merely stating a fact that the kind of discussion about updmap is _a
non-sense_, because   this   syntax should  have   been  discussed prior
introducing it, not after.

If I referred back to this BachoTeX meeting (I didn't attend btw), it is
simply to stress that the lack of clear design decisions from whatever
management team (that does not exist anyway) results in the situation we
are now.

On one  side you have   people working on   this project on their  _free
time_. 

On the other  side, LUGs needing it to  _sell it_ to users. 

The   first ones  look for  simple  solutions  to   their  problems, but
unfortunately, clearly to _their platform_ problems only.

But      users  want  more.   They    want    compatibility, they   want
reliability. Many of  this year changes have  cost lots of time to  many
people, not only to  the 4 or 5  of us. And there  is no  guarantee that
this will have ever an end the way we are working.

On a very related topic,   I sent a note to   the current DANTE  meeting
which I have attached. Don't know if someone will  read it there, but it
explains (very shortly)   why I think  both CTAN/Distributions  meetings
DANTE has organized  have felt to fulfil their  expectations (or mine at
least).  The   way described there  of doing   things could  change what
distributions are. I    expect  people on  this  list   to  already have
understood my point   of view on  this  topic. If  not it will  make  it
clearer.

Read it as my last contribution, for what it worth. And blame me for
what I did (or what I didn't).

Fabrice

What does it take to install/update a \LaTeX{} package today? Find the right
directory on CTAN. Find the right file(s) to download, in the best case an
archive. Uncompress it to some temporary folder. Process the \texttt{.ins}
and/or \texttt{.dtx} files. Install all the files under your TDS compliant texmf
tree, which can become a little bit clumsy: sometimes, you have fonts, metapost
files, etc. to dispatch into a dozen of different places. Do not forget to
rebuild your texmf database. And then, if you are lucky, you can work with your
new package. All this processing is at best boring, at worst a source of error.

What would it take to relieve users from this? I have often heard that it is
impossible. In fact it is not, and that doesn't require a lot. It is indeed
possible to automate \TeX{} package installation, at least for the vast majority
of \TeX{} packages. How is it possible?

First, I guess that by now everybody has heard about TDS compliant texmf
trees. The \TeX{} Directory Structure normalize file location. But its
requirements are not strong enough for automation. The TDS requirements have
been made with only one problem in mind: acceleration of file search into big
texmf trees. So basically, the TDS restricts the places where to look for
certain kind of files. For example, all \texttt{.sty} \LaTeX{} files have to be
located somewhere under \path|texmf/tex/latex/|.

If we want to automate package management, we have to comply with stronger
requirements. The TDS has to be augmented with rules identifying a unique places
for each package. Moreover, a connexion has to be made between the symbolic name
of the package and those places. Assume we register for a \texttt{foo} package
and this name has not yet been taken. Then a bunch of directories  are
automatically assigned to this package:
texmf/fonts/source/public/foo/
texmf/fonts/tfm/public/foo/
...
texmf/fonts/tfm/tex/foo/...
texmf/fonts/tfm/tex/latex/foo/
texmf/fonts/tfm/tex/context/foo/
...
texmf/doc/foo/
...
That means that all the `foo' files are located under one of these directories
and no `foo' file is located outside of them.

The exact rules are a little bit more complex, because given the existing state
of affairs, we have to consider a couple of different cases. The first obvious
case is the one of the format files themselves, like the base \LaTeX{}
files. Given that \LaTeX{} is a package, contributions can be provided. So the
base files have to be located into:
texmf/tex/latex/base/
texmf/tex/latex/config/
and not into texmf/tex/latex/ itself.

How does this help with automation? If we follow these stricter rules, we are
able to automatically construct the list of `foo' files given a reference texmf tree that
has the files. Therefore, we can create an archive of these files. Now on the
client side, we can archive or wipe out all of his current `foo' files, download
the newest archive and unpack it.

We can also run tools to ensure consistency on the client texmf tree: make
sure that no `foo' file appear under one of the `bar' directories for example. 

What would it take to CTAN to evolve towards this kind of automation? 

First, it
would require that authors register their package names. There have been a
couple of clashes in the past, like some `pl' package to typeset Prolog code,
and the `pl' package for Polish fonts.

Once unique names are ensured, it would require from authors that they upload
ready to use fragments of texmf tree. In the current situation, there are too
many different ways to install a package, with different instructions. It would
be much better to relieve the user from that and let the author upload what he
thinks is the right way to arrange the files into the texmf tree. Moreover, the
kind of consistency tools cited above could be run by the server on the package
to check that the 'enhance TDS' guidelines are respected.

Finally, it would require to have a web service infrastructure capable of
delivering the archives. The Graham Catalogue could be used to build a first
index to search among the packages. No need to look for complex indexing
methods. Then simple client tools could be developed
to list the installed packages, to look for a new package or for updates.

This way of doing things would change the structure of distributions. They could
be reduced to the simple list of binaries and specific files. That means you
could get a < 10Mb archive of TeXLive 2004 and run the package maintenance
client to download whatever packages you need. 

It is to be noted that these ideas of an enhanced TDS have been implemented for the texmf-dist tree
of TeXLive 2004, not without some reluctance from sceptical people. It is also
to be noted that Christian Schenk (MiKTeX author) has offered to develop the web
service infrastructure, but without any reply (to my knowledge). My guess is that he might well do
it by himself and  build a parallel and much more efficient way of downloading
packages.

So the question is: is that community getting old and dying or will it adapt to
more modern tools and methods? For me, the way to go is clear: why doing by hand
something that the machine can do for me?