[luatex] latest 'fixes' don't fix....again.

[Robin Fairbairns]

Ulrike Fischer <luatex at nililand.de> wrote:

> Am Fri, 10 May 2013 18:15:51 +0200 schrieb Philipp Gesang:
> 
> >> I made some tests this afternoon. I pulled from the various github
> >> sites lualibs, luatexbase, luaotfload, fontspec. After blacklisting
> >> some fonts I could create a fontname database with texlua
> >> luaotfload-tool.lua. 
> >> 
> >> But using the fonts failed: At first luaoftload-database use load()
> >> where older lua-versions need loadstring(). And if I correct this
> >> problem I get messages about "invalid field id 9". 
> > 
> > That indicates an outdated luatex. Depending on what you do you
> > get the same error with e.g. the binary from TL 2012.
> 
> Well "outdated" is a bit harsh. After all it is the version which is
> also used by a current texlive 2012. 

outdated with respect to the testing environment, i suppose.

> And the luatex sites claims (or - as the text is quite old - perhaps
> better "claimed") that only major updates (x.x0 versions) "are
> stable enough to be used for production work". 

one man's minor update is another's game breaker; i wouldn't criticise
the luatex team, here.

> Until a few days an update of the binary would have been highly
> problematic as a lot of packages didn't work with the newer luatex.
> So imho it is not a bad idea to keep a stable system for some time. 
> 
> (But it would be useful to have a newer version for tests parallel
> to the stable system).

there seemed to me to be a coherent structure, of a tex live "testing"
repository against which "interested experts" could perform
experiments.  this seems to have gone rather severely off the rails, for
a number of reasons ... not least that the ctan team has been merrily
updating luatex-related packages on the archive, as they were supplied
to us.  i don't know what would have been best, but it's clearly an item
for discussion of "next time".

so, the process needs to be rethought for another year.  for now, i
would claim that those involved should try to make the best of a bad
job; proposals for a better process for next year would be useful, but
we can surely now take the failures of process "as read", and plough on
with the actual work the testing version is there for.

robin