Hi, In one of the next releases I want to start distributing some lua files under <texmf>/luatex/lua/ The intentions is that lua modules that are part of the luatex lua distribution will go there, nothing else. These are files that can be reached via the Lua require() function using the default compile-time package.path. Lua scripts have their place under <texmf>/scripts/lua already, and macro package specific lua files should remain below <texmf>/tex/, to be found via kpse.find_file(). The immediate candidates for inclusion are: from lpeg, currently not distributed at all luatex/lua/re.lua from luasocket, currently compiled into the executable: luatex/lua/socket.lua luatex/lua/ltn12.lua luatex/lua/mime.lua luatex/lua/socket/http.lua luatex/lua/socket/url.lua luatex/lua/socket/tp.lua luatex/lua/socket/ftp.lua luatex/lua/socket/smtp.lua Some others may soon arise form the luatex core itself, for example for the mapping of node (sub)type numbers to strings. These ids are static for any particular version of the executable, but they are never actually used inside the engine, so it makes sense to split them off into a lua module that can be loaded on demand. One warning and one question. First the warning, for Hans in particular: make sure you start using require() for all of the external lua modules that are embedded in luatex. As soon as this new subsystem is in place, you can no longer use functions like socket.bind() without require-ing the module first! Second the question, and that is mostly for Martin: when luatex starts shipping more stuff than just a single executable, it begins to make sense to have an installation method. It could be nice to be able $ ./configure; make; make install at toplevel, instead of $ ./build.sh ; cp <bunch of whatever to wherever> ; ... To be able to that, the current build scripts have to be rewritten into a unified Makefile.in. The new, to-be-created configure script can be rather stupid and may not even have to be autoconf-generated. The aim is to get a predictable user interface, not automating the whole big build process. For example, if "make clean" would delete the build tree (if there was one), then the "--make" commandline switch would no longer be needed. Targets like "make cross" and "make native" could replace ./build.sh.linux and ./build.sh.cross, etc. Would you (or anyone else) be willing to work on that? Best wishes, Taco