lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Hi,

John Belmonte wrote:
> With help from Enrico Tassi, I've packaged Lua 5.1 (currently up to the
> "original" -rc release) for Debian GNU/Linux officially, and it has
> entered the distribution's unstable archive.

Good news! Here are some comments:

There is a deviation between standard Lua and Debian Lua about
the module installation paths. IMHO it would be helpful to
resolve this _now_ (i.e. before the release of Lua 5.1 final).

Lua 5.1 default: ${prefix}/lib/lua/5.1  ${prefix}/share/lua/5.1
Debian Lua 5.1:  ${prefix}/lib/lua5.1   ${prefix}/share/lua5.1

[Debian adds both /usr and /usr/local prefixes which is normal
for distribution packages and must not be done in standard Lua.]

Personally I don't care whether there's an intermediate slash or
not. But I would like to see _one_ standard. Either standard Lua
or Debian should be changed IMHO. It will needlessly complicate
support on the mailing list if there are two variations out
there. Module authors won't appreciate this either.

Proposal: The slash-less variant is simpler and matches e.g. the
Python conventions. This means standard Lua should be changed. If
this cannot be considered for the final release anymore, then
Debian Lua should be changed.


The use of libtool forces another deviation from standard Lua.
Here are the elements of Debian Lua's package.cpath:

./?.so
./liblua-?.so                       <-- !
/usr/local/lib/lua5.1/?.so
/usr/local/lib/lua5.1/liblua-?.so   <-- !
/usr/lib/lua5.1/?.so
/usr/lib/lua5.1/liblua-?.so         <-- !
/usr/lib/lua5.1/loadall.so

Installing a C module "foo" with libtool creates the following
files and symlinks in the install path:

liblua-foo.a
liblua-foo.la
liblua-foo.so -> liblua-foo.so.0.0.0
liblua-foo.so.0 -> liblua-foo.so.0.0.0
liblua-foo.so.0.0.0

[Note: The versioning is meaningless due to the way these shared
libraries are loaded. But it cannot be turned off in libtool.]

But standard Lua expects to find "foo.so". This means that Debian
originated modules won't run with standard Lua (even if you have
libtool to build and install them). This is unfortunate.

Maybe a compromise could be reached by requiring Debian
originated modules to install an additional symlink:
  foo.so -> liblua-foo.so
This way the modification of package.cpath can be avoided, too.
The install target in the example needs to be extended like this:
  cd $(RPATH); ln -sf liblua-foo.so foo.so

Module authors could then be given a standard Makefile template
which has a default target (build 'by hand', i.e. gcc -shared)
and a libtool target. The former is useful for systems without
GNU toolchains because it can be easily understood and modified.
A C module can be installed with both methods and can be run by
both standard Lua and Debian Lua. IMHO this is an important
property.


> [... "lua" executable ...] Also, it's been reported that use of position-
> independent code hinders the VM's performance.  For these reasons, and for
> consistency, both executables are statically linked.

This is appreciated. I'll notify the 'Great Computer Language
Shootout' maintainers asap when the final Debian package has been
released. You'll be able to tell the difference in the scores
that Lua gets on the shootout.

[Lua _is_ judged by others based on these (debatable) scores.
Good scores mean good PR.]

Bye,
     Mike