[ANN] Lua 5.1 Debian package

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

[ANN] Lua 5.1 Debian package

John Belmonte
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.  For users of Sarge (the
last stable Debian release), a backport is also available.  Note that
this package is a work in progress and won't become part of a stable
Debian release until the end of 2006 or later.

    http://packages.qa.debian.org/l/lua5.1.html

    http://backports.org/package.php?search=lua5.1

The package includes some propaganda, and it may cause controversy in
the domain where the Lua tires meet the road.  As a matter of disclosure
to people who don't use Debian, I've attached the package README and
have posted the package's examples as plain files at
<http://memebeam.org/john/debian/lua5.1/examples/>.  These minimal
examples include the recommended way to build binary Lua modules, etc.

While doing this packaging work I've come to appreciate libtool, and I
have to say I think it's not given the attention it deserves in the
list's discussions on both building Lua itself and building Lua apps and
binary modules.  It takes care of static and dynamic builds in one shot,
 hides the differences between Unix platforms well, and is trivial to
use.  While it doesn't cover every user out there, it does likely cover
95% of those using Unix (including Cygwin on Windows and Darwin on Mac).
 Even in the case of higher level build solutions (i.e. those
encompassing Windows OS's), I'd expect that they would employ libtool
when it's available for the target.

I could probably make a similar argument for the pkg-config tool.

--John


lua5.1 for Debian
=================

This is packaging for Debian of the 5.1 series of the Lua programming
language.  For package development see <http://pkg-lua.alioth.debian.org/>.

Binary package index:

    * lua5.1 - command line tools (i.e. interpreter and bytecode compiler)
    * lua5.1-doc - documentation, including manual and examples
    * liblua5.1-0-dev - development libraries
    * liblua5.1-0 - runtime libraries


II. Propaganda
==============

Best practices
--------------
See "./examples/debian/" in the lua5.1-doc package for some tips and best
practices for using the Lua library in your app, building binary modules,
etc.


III. Rationale
==============

Packaging philosophy
--------------------
The packaging philosophy adopted is to avoid changes to upstream source as
much as possible.


Need to maintain old Lua releases
---------------------------------
While the Lua authors attempt to keep changes to the language and standard
libraries backwards compatible, the C API often changes significantly between
versions (e.g. from the 5.0 series to 5.1).  Applications in which Lua is
embedded often become bound to a certain version of Lua indefinitely.  For
these reasons, and in contrast to other interpreted languages which have more
of a stand-alone focus, it's important to maintain old Lua library releases
as long as they are in use by relevant applications.


Naming convention (lua5.1 vs. lua51)
------------------------------------
The naming convention prior to the lua5.1 package, specifically the lack of
delimiters in the version portion, lacked foresight.  The reason is that if
the version ever has more than one digit per component, the terser name will
be ambiguous.  Even if this will never be a problem in practice (will 61.1
clash with 6.11?), lua12.3 seems more friendly than lua123.


Library SONAME
--------------
As explained, each series of Lua (e.g. 5.0, 5.1) is treated as a completely
separate library.  Within a series, Libtool versioning is followed.  For
example, the first release of Lua 5.1 (5.1.0) will have a soname
"liblua5.1.so.0".  Let's say that 5.1.1 is later released, and it is binary
compatible with the previous version.  In that case, the soname will stay
the same, and existing applications do not need to relink.

Note that in this convention, along with the naming of interpreters, etc.,
as described previously, there has been a conscious compromise in the
granularity of the versions that may be specified.  That is, the
minor version number is considered significant in that it may break
compatibility, but not significant in calling out a version of Lua to
interpret a file, maintaining parallel versions for development, etc.


Package binaries: static vs. dynamic linking
--------------------------------------------
There are two executables in this source package: "lua" and "luac".  Due to
luac's use of internal symbols in the Lua core, at present it cannot be
dynamically linked.  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.


IV. For packagers
=================

Package testing
---------------
Final testing should be done in a clean environment (e.g. via pbuilder).
Important tests:
    * package build
    * install of each binary package without the others installed
    * with all packages installed:
        * run "make" in examples/debian/


Unfinished business
-------------------
TODO: document module paths
TODO: include soname number in source package name (on next increment).  May
    want to split library and command line tools into separate source packages.
ISSUE: want way to avoid hard-coding package and path names in
    lua5.1.postinst, etc.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1 Debian package

Mike Pall-41
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
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1 Debian package

Roberto Ierusalimschy
> 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
> ...
> Proposal: The slash-less variant is simpler and matches e.g. the
> Python conventions.

Is there an agreement? Should we change that?

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1 Debian package

Tomas-14
In reply to this post by Mike Pall-41
  Hi John and Mike,

> 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
...

> 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.
  I agree with you except in that last proposal because
the convention adopted by standard Lua was discussed in this list
some time ago and it is being used by more than a year with success.
The argument that it "is simpler and matches e.g. the Python conventions"
seems weak.
  Anyway I agree that it would be better to adopt _one_
standard.

  Regards,
  Tomas
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1 Debian package

Alex Queiroz
Hallo,

On 1/27/06, Tomas <[hidden email]> wrote:
>         I agree with you except in that last proposal because
> the convention adopted by standard Lua was discussed in this list
> some time ago and it is being used by more than a year with success.
> The argument that it "is simpler and matches e.g. the Python conventions"
> seems weak.

     Python: /usr/lib/python2.4
     TCL: /usr/lib/tcl8.4
     Ruby: /usr/lib/ruby/1.8

     So certainly there is room for both proposals. Is Lua gonna pair
with Python/TCL or with Ruby (Debian-wise)?

--
-alex
http://www.ventonegro.org/
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1 Debian package

David Haley
In reply to this post by Mike Pall-41
On this day of 1-27-2006 3:57 AM, Mike Pall saw fit to scribe:

> 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.
>>    
> [...]
> 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
>
> [...]
>
> 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.
>  

For what it's worth, I also prefer the slash-less variant. My argument
is that when I have multiple versions of Lua installed, I can have
${prefix}/lib/{lua5.1, lua5.0, lua4, etc.} - and have a single symlink
${prefix}/lib/lua pointing to the "current" Lua libs. But if modules
were to be installed into ${prefix}/lib/lua/5.1, they would go into the
wrong place if my symlink pointed elsewhere (say, to my 5.0 installation.)

I don't know if this argument has any general validity whatsoever. It's
probably rather specific to how I set things up (which might be a dumb
way anyhow - I'm kind of new at laying out files on a *nix system). But,
it's just my two cents' worth... And in fact, if you have feedback
regarding this way of laying things out in the first place, please give
it! :-)

- David

--
~David-Haley
http://david.the-haleys.org


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1 Debian package

Alex Queiroz
Hallo,

On 1/27/06, David Haley <[hidden email]> wrote:
>
> For what it's worth, I also prefer the slash-less variant. My argument
> is that when I have multiple versions of Lua installed, I can have
> ${prefix}/lib/{lua5.1, lua5.0, lua4, etc.} - and have a single symlink
> ${prefix}/lib/lua pointing to the "current" Lua libs. But if modules
> were to be installed into ${prefix}/lib/lua/5.1, they would go into the
> wrong place if my symlink pointed elsewhere (say, to my 5.0 installation.)
>

     The idea is to allow several Lua versions to coexist peacefully
in the same system. So, the currently running Lua interpreter must be
able to find the proper dynamic modules without resorting to symlinks
to the current version in use. That's why the version component must
be part of the Lua search path.

--
-alex
http://www.ventonegro.org/
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1 Debian package

Roberto Ierusalimschy
In reply to this post by Tomas-14
>         I agree with you except in that last proposal because
> the convention adopted by standard Lua was discussed in this list
> some time ago and it is being used by more than a year with success.

Tomas is right about that. Those paths were lengthly discussed in
this list, and I don't think the technology has changed since then.
I see no reason to restart that discussion.

As this was already discussed (and agreed!) on the list, I wouldn't say
that we need "_one_ standard". I would say that we already have one
standard, and Debian should follow it.

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1 Debian package

Mike Pall-41
In reply to this post by Alex Queiroz
Hi,

Alex Queiroz wrote:
>      Python: /usr/lib/python2.4
>      TCL: /usr/lib/tcl8.4
>      Ruby: /usr/lib/ruby/1.8

A few more (from Gentoo, but I guess this is distro independent):

Perl:      /usr/lib/perl5/5.8.7
GCC:       /usr/lib/gcc-lib/i686-pc-linux-gnu/4.1.0
Qt:        /usr/qt/4
Ethereal:  /usr/lib/ethereal/plugins/0.10.14
Gimp:      /usr/lib/gimp/2.3
Openmotif: /usr/lib/openmotif-2.2
pppd:      /usr/lib/pppd/2.4.3

There is ample precedent for either variant, but no standard in
sight. The variant with a slash seems to be more popular. I don't
know any purely technical reason for choosing either. So it's a
matter of policy left to the upstream package maintainers.

Roberto Ierusalimschy wrote:
> Is there an agreement? Should we change that?

Let's wait what John has to say about his rationale for the
change.

Bye,
     Mike
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1 Debian package

Luiz Henrique de Figueiredo
In reply to this post by John Belmonte
> While doing this packaging work I've come to appreciate libtool, and I
> have to say I think it's not given the attention it deserves in the
> list's discussions on both building Lua itself and building Lua apps and
> binary modules.

We certainly do not want to rely on libtool for building Lua. Moreover,
we do not encourage building Lua (the library) as a .so... We do
encourage building lua (the interpreter) statically and exporting the
Lua API so that dynamic libs work fine with it.

> I could probably make a similar argument for the pkg-config tool.

Lua 5.1 does include etc/lua,pc. Feedback on this is appreciated.
--lhf
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1 Debian package

John Belmonte
Luiz wrote:
>>While doing this packaging work I've come to appreciate libtool, and I
>>have to say I think it's not given the attention it deserves in the
>>list's discussions on both building Lua itself and building Lua apps and
>>binary modules.
>
> We certainly do not want to rely on libtool for building Lua. Moreover,
> we do not encourage building Lua (the library) as a .so... We do
> encourage building lua (the interpreter) statically and exporting the
> Lua API so that dynamic libs work fine with it.

Sorry for the misunderstanding, I wasn't suggesting that the Lua build
rely solely on libtool.  It may be worth considering as a make target
given the coverage it offers.

You cleared up your position on the Lua library as an .so in another
posting, but I thought I should note the importance of .so's in the
workings of a Unix distribution.   Unless libraries are dynamically
linked, when a serious bug or security issue in a library comes up,
every package relying on it (perhaps hundreds) must be rebuilt for every
target architecture (12 in the case of Debian) and redistributed to
users.  That wouldn't scale too well.

>>I could probably make a similar argument for the pkg-config tool.
>
> Lua 5.1 does include etc/lua,pc. Feedback on this is appreciated.

Please consider the following addition to lua.pc so that software
installing Lua modules has an alternative to hard coding the module paths.

  # Install paths for Lua modules, relative to the install root.  For
  # example, if a package wants to install Lua source modules to the
  # /usr/local tree, it should use this path:
  #    /usr/local/`pkg-config lua --variable=module_dir`
  module_dir=share/lua/5.1
  binary_module_dir=lib/lua/5.1


--John
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1 Debian package

John Belmonte
In reply to this post by Mike Pall-41
Mike Pall wrote:

> 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.

I think it would be best to separate the use of the "lib" prefix naming
convention from whether libtool is used or not.  If you take a generic
approach to creating a Lua library/module, you'll find that you can't
assume whether users will link it to their app statically or load it via
require (they might even link to it dynamically via the link line rather
than require).  In the static case, clearly "foo.a" isn't going to work
too well because you can't use "-lfoo" on the link line, and since it
will pollute the /usr/lib namespace if "lua" doesn't appear in the name.
 So if you buy that the static library should start with lib and have
"lua" in the name somewhere, and that the .a and .so should be named
consistently to each other, and resolve the constraints of the Lua
dynamic loading system, the logical result is "liblua-foo.{a,so}".

--John
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1 Debian package

John Belmonte
In reply to this post by John Belmonte
I've updated the Debian package to the latest -rc source and restored
the module paths to the "lua/5.1" form.  Attached is some new text in
the README regarding module paths.

--John

Module paths
------------
Upstream's package.path and package.cpath consist of paths under /usr/local.
Corresponding paths under /usr are required to support Lua modules which will
be packaged for Debian.  These have been added except in the case of /usr/lib
in package.path.  Debian policy is clear that architecture-independent files
(i.e. .lua modules) be placed under /usr/share, while binary files (i.e. module
.so's) be under /usr/lib.  This implies that Lua's package.path should not
contain references to /usr/lib.  Since /usr/local is not under Debian
management, upstream's original paths were left intact.

The implication for Lua modules packaged for Debian is that the correct module
paths must be used at install time.  Instead of hard coding these paths, use
of the "module_dir" and "binary_module_dir" info made available through
pkg-config is recommended.  For example, in a makefile:

  PREFIX = /usr
  MODULE_PATH = $(PREFIX)/$(shell pkg-config lua5.1 --variable=module_dir)
  BIN_MODULE_PATH = $(PREFIX)/$(shell pkg-config lua5.1 --variable=binary_module_dir)

For those concerned about either pkg-config or these variables not being
available everywhere, it is trivial to fall back to a hard coded path.

Another addition to upstream's module paths is the "liblua-?.so" variations in
package.cpath.  These allow binary modules following libtool naming convention
to be loaded without any noticeable difference to users of the module.  In
other words, module "foo" can be loaded with "require 'foo'" regardless of
whether the binary was named according to libtool convention or not.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1 Debian package

Antonio Scuri
In reply to this post by John Belmonte
At 01:18 27/1/2006, John Belmonte wrote:
>Naming convention (lua5.1 vs. lua51)
>------------------------------------
>The naming convention prior to the lua5.1 package, specifically the lack of
>delimiters in the version portion, lacked foresight.  The reason is that if
>the version ever has more than one digit per component, the terser name will
>be ambiguous.  Even if this will never be a problem in practice (will 61.1
>clash with 6.11?), lua12.3 seems more friendly than lua123.

   This is something that we can do in LuaBinaries, so we can
maintain compatibility between LuaBinaries and the Debian package.


>Library SONAME
>--------------
>As explained, each series of Lua (e.g. 5.0, 5.1) is treated as a completely
>separate library.  Within a series, Libtool versioning is followed.  For
>example, the first release of Lua 5.1 (5.1.0) will have a soname
>"liblua5.1.so.0".  Let's say that 5.1.1 is later released, and it is binary
>compatible with the previous version.  In that case, the soname will stay
>the same, and existing applications do not need to relink.
>Note that in this convention, along with the naming of interpreters, etc.,
>as described previously, there has been a conscious compromise in the
>granularity of the versions that may be specified.  That is, the
>minor version number is considered significant in that it may break
>compatibility, but not significant in calling out a version of Lua to
>interpret a file, maintaining parallel versions for development, etc.

   This is complicated for us. We do not use libtool, and library
names are simply "lua<version>.lib" (in Windows) or
"liblua<version>.so/.a" (in UNIX). And in UNIX everything can be
solved with a file system link.

   I checked Pyhon, Perl and TCL, and the SONAMEs are very different,
but version numbers are indeed used with periods in the library name,
like in "5.1".

   We were using <version> as "51", but it seems to be reasonable to
change to "5.1". Any comments?

   Are there other Lua packages? Can we all converge to a common
standard for names?

Thanks,
scuri

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1 Debian package

Adrian Perez-2
In reply to this post by John Belmonte
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


El 01/02/2006, a las 16:21, Antonio Scuri escribió:

> At 01:18 27/1/2006, John Belmonte wrote:
>
>> Library SONAME
>> --------------
>> [...]
>
> [...]
>
> Are there other Lua packages? Can we all converge to a common  
> standard for names?

I have been using Gentoo lately (both Portage under MacOS X and under  
Linux). Current Gentoo ebuilds for Lua are named like «lua-5.1», but  
that's only the (irrelevant) name of the ebuild. Installed libraries  
are named «liblua.5.1.so» with two symlinks named «liblua.5.so» and  
«liblua.so» pointing to the library. I think there would be no  
problem at all in using «liblua5.1.so» -- people maintaining ebuilds  
won't complain if someone asks them to drop the leading dot, AFAIK.

P.S: This is my first mail to lua-l after a long time without  
writing, but I've been reading from time to time. I'm still alive,  
but busy with University work.

- --
Adrián Pérez
«A day without laugh is a lost day.» -- Woody Allen


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFD4NqNghBwwjayrGQRAnVaAJ9cZryLCB87VmbIJDmfnET67Fj/HACePbQD
RYpSQ1LdiGsfaUm0hDxm9D8=
=D8AL
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.1 Debian package

John Belmonte
In reply to this post by John Belmonte
Antonio Scuri wrote:

> At 01:18 27/1/2006, John Belmonte wrote:
>
>> Naming convention (lua5.1 vs. lua51)
>> ------------------------------------ The naming convention prior to
>> the lua5.1 package, specifically the lack of delimiters in the
>> version portion, lacked foresight.  The reason is that if the
>> version ever has more than one digit per component, the terser name
>> will be ambiguous.  Even if this will never be a problem in
>> practice (will 61.1 clash with 6.11?), lua12.3 seems more friendly
>> than lua123.
>
>
> This is something that we can do in LuaBinaries, so we can maintain
> compatibility between LuaBinaries and the Debian package.
>
>
>> Library SONAME -------------- As explained, each series of Lua
>> (e.g. 5.0, 5.1) is treated as a completely separate library.
>> Within a series, Libtool versioning is followed.  For example, the
>> first release of Lua 5.1 (5.1.0) will have a soname
>> "liblua5.1.so.0".  Let's say that 5.1.1 is later released, and it
>> is binary compatible with the previous version.  In that case, the
>> soname will stay the same, and existing applications do not need to
>> relink. Note that in this convention, along with the naming of
>> interpreters, etc., as described previously, there has been a
>> conscious compromise in the granularity of the versions that may be
>> specified.  That is, the minor version number is considered
>> significant in that it may break compatibility, but not significant
>> in calling out a version of Lua to interpret a file, maintaining
>> parallel versions for development, etc.
>
>
> This is complicated for us. We do not use libtool, and library names
> are simply "lua<version>.lib" (in Windows) or "liblua<version>.so/.a"
>  (in UNIX). And in UNIX everything can be solved with a file system
> link.

In the liblua5.1-0-dev package:
  /usr/lib/liblua5.1.a
  /usr/lib/liblua5.1.so  (symlink)

so I don't think this is incompatible with what you say.  Note, however,
that the .so with the soname number ("liblua5.1.so.0") should be used
rather than the symlink above.  If you link against the symlink, and
there is a binary incompatibility in the 5.1.1 release (e.g. C API
signature change) you could get a run-time error in packages built
against the old release.  (To my knowledge, there is no promise from the
Lua authors regarding C API compatibility in a minor release.)  These
are the kind of issues that large Unix distributions have to be
concerned with.

> We were using <version> as "51", but it seems to be reasonable to
> change to "5.1". Any comments?

Note that the "Naming convention (lua5.1 vs. lua51)" rationale above
applies to all Lua related filenames, not just the command line interpreter.

--John
Reply | Threaded
Open this post in threaded view
|

Is Lua 5.1.1 your next executable?? (Re: [ANN] Lua 5.1 Debian package)

Asko Kauppi

Wait a minute.

There now seems to be consensus on also LuaBinaries moving to  
"lua5.1" naming instead of "lua51", is there?

Technically, I don't mind, but is there really any benefit for this?  
If the Lua authors would warrant, as is the case with Lua 5.0.2, that  
any 5.1.x version is ABI and API compatible with 5.1, there's  
basically no issue.

Personally, I'd favor having lua51 for anything Lua 5.1.x series will  
bring. Am I the only one seeing Things How They Now Stand as being  
rather good?  Which I do.

Worried.. just a bit.
-asko



John Belmonte kirjoitti 7.2.2006 kello 4.01:

> Antonio Scuri wrote:
>> At 01:18 27/1/2006, John Belmonte wrote:
>>
>>> Naming convention (lua5.1 vs. lua51)
>>> ------------------------------------ The naming convention prior to
>>> the lua5.1 package, specifically the lack of delimiters in the
>>> version portion, lacked foresight.  The reason is that if the
>>> version ever has more than one digit per component, the terser name
>>> will be ambiguous.  Even if this will never be a problem in
>>> practice (will 61.1 clash with 6.11?), lua12.3 seems more friendly
>>> than lua123.
>>
>>
>> This is something that we can do in LuaBinaries, so we can maintain
>> compatibility between LuaBinaries and the Debian package.
>>
>>
>>> Library SONAME -------------- As explained, each series of Lua
>>> (e.g. 5.0, 5.1) is treated as a completely separate library.
>>> Within a series, Libtool versioning is followed.  For example, the
>>> first release of Lua 5.1 (5.1.0) will have a soname
>>> "liblua5.1.so.0".  Let's say that 5.1.1 is later released, and it
>>> is binary compatible with the previous version.  In that case, the
>>> soname will stay the same, and existing applications do not need to
>>> relink. Note that in this convention, along with the naming of
>>> interpreters, etc., as described previously, there has been a
>>> conscious compromise in the granularity of the versions that may be
>>> specified.  That is, the minor version number is considered
>>> significant in that it may break compatibility, but not significant
>>> in calling out a version of Lua to interpret a file, maintaining
>>> parallel versions for development, etc.
>>
>>
>> This is complicated for us. We do not use libtool, and library names
>> are simply "lua<version>.lib" (in Windows) or "liblua<version>.so/.a"
>>  (in UNIX). And in UNIX everything can be solved with a file system
>> link.
>
> In the liblua5.1-0-dev package:
>   /usr/lib/liblua5.1.a
>   /usr/lib/liblua5.1.so  (symlink)
>
> so I don't think this is incompatible with what you say.  Note,  
> however,
> that the .so with the soname number ("liblua5.1.so.0") should be used
> rather than the symlink above.  If you link against the symlink, and
> there is a binary incompatibility in the 5.1.1 release (e.g. C API
> signature change) you could get a run-time error in packages built
> against the old release.  (To my knowledge, there is no promise  
> from the
> Lua authors regarding C API compatibility in a minor release.)  These
> are the kind of issues that large Unix distributions have to be
> concerned with.
>
>> We were using <version> as "51", but it seems to be reasonable to
>> change to "5.1". Any comments?
>
> Note that the "Naming convention (lua5.1 vs. lua51)" rationale above
> applies to all Lua related filenames, not just the command line  
> interpreter.
>
> --John

Reply | Threaded
Open this post in threaded view
|

Re: Is Lua 5.1.1 your next executable?? (Re: [ANN] Lua 5.1 Debian package)

Roberto Ierusalimschy
> If the Lua authors would warrant, as is the case with Lua 5.0.2, that  
> any 5.1.x version is ABI and API compatible with 5.1, there's  
> basically no issue.

We do warrant that. All previous X.X.x versions of Lua were only
bug-removing versions of X.X, and they will continue to be. Actually,
we do not like the use of the name "5.0.2" as a version, as it is (or
should be), for all practicall purposes, identical to 5.0. (I mean,
if you are discussing bugs or need to refer to specific lines of code
in the source, then it is ok to say that you are using 5.0.x. But
otherwise, people should use 5.0 as the "generic" name for 5.0.x.)

(The reference manual of those versions is always the same, except for
occasional grammatical and spelling corrections.)

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: Is Lua 5.1.1 your next executable?? (Re: [ANN] Lua 5.1 Debian package)

John Belmonte
In reply to this post by Asko Kauppi
Asko Kauppi wrote:

>
> Wait a minute.
>
> There now seems to be consensus on also LuaBinaries moving to  "lua5.1"
> naming instead of "lua51", is there?
>
> Technically, I don't mind, but is there really any benefit for this?  
> If the Lua authors would warrant, as is the case with Lua 5.0.2, that
> any 5.1.x version is ABI and API compatible with 5.1, there's  basically
> no issue.
>
> Personally, I'd favor having lua51 for anything Lua 5.1.x series will
> bring. Am I the only one seeing Things How They Now Stand as being
> rather good?  Which I do.

Hi Asko,

I think you are misreading what I wrote as far as the Debian packages.
Any files in the 5.1.x series will have "5.1" in the name.  There will
never be "5.1.1" in a file name.  The rationale for "5.1" vs. "51" is
not based on the existence of minor versions.  I tried to make this
clear in the README, but maybe the text needs more work.

--John