Lua within Debian

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

Lua within Debian

Daniel Silverstone
[include "apology for long message relevant to only small subset of lua users"]

Hi,

Over the past few weeks I have been putting a /lot/ of thought into how Lua
should be packaged for Debian GNU/Linux and GNU/Hurd systems.

Through those weeks, there has also been a large discussion about how
standard libraries for lua should be packaged, and how one should arrange a
standard for dynamically loading extensions to the lua interpreter also.

I am therefore designing a system for Debian, which will, in the spirit of
Debian, be free (as in speech).

http://lua.digital-scurf.org/ has a few more details.

I hope to have packages /and/ policy ready in a few weeks at most.

The policy first-draft is also on the above site (as a text version) and as
such I am anxious that people provide feedback to me as to how they would
like to see this whole thing handled.

I am aware that whatever my final decision, not everyone will be happy, but
unfortunately this is a decision which needs to be made and stuck to, in
order to allow Debian to have a good Lua infrastructure for the years ahead.

Please, if you are interested, visit that site and email me comments and
ideas. I can only get it right if the interested parties help me do so.

Regards,

Daniel

-- 
Daniel Silverstone                               http://www.digital-scurf.org/
Hostmaster, Webmaster, and Chief Code Wibbler          Digital-Scurf Unlimited
GPG Public key available from keyring.debian.org               KeyId: 20687895
Rubber bands have snappy endings!

Attachment: pgp2gtKbZv5Ni.pgp
Description: PGP signature

Reply | Threaded
Open this post in threaded view
|

Re: Lua within Debian

Daniel Silverstone
On Sun, Feb 03, 2002 at 11:47:07PM +0000, Daniel Silverstone wrote:
> http://lua.digital-scurf.org/ has a few more details.
> I hope to have packages /and/ policy ready in a few weeks at most.

Today I have uploaded an initial set of lua 4.0 packages to

http://lua.digital-scurf.org/packages/

they are the plain lua 4.0 system (with shared library support for liblua
and liblualib) -- No require, no loadlib, nothing fancy.

This is the vanilla "lua" which debian will carry.

Comments and ideas for these packages should be emailed to me as soon as
possible please.

I'll be starting on the dllua40 packages tomorrow night -- these will have a
loadlib of sorts and will be the default lua interpreter for debian.

Again, comments and ideas please email me soon..

I need to get this done because there are debian maintainers who want to use
lua who can't until I get all this sorted.

Many thanks in advance for the large amount of help I am expecting the
community will want to offer.

Daniel

-- 
Daniel Silverstone                               http://www.digital-scurf.org/
Hostmaster, Webmaster, and Chief Code Wibbler          Digital-Scurf Unlimited
GPG Public key available from keyring.debian.org               KeyId: 20687895
Girls are better looking in snowstorms.
		-- Archie Goodwin

Attachment: pgpxXx74CVBG6.pgp
Description: PGP signature

Reply | Threaded
Open this post in threaded view
|

Re: Lua within Debian

Jay Carlson
On Mon, 11 Feb 2002, Daniel Silverstone wrote:

> On Sun, Feb 03, 2002 at 11:47:07PM +0000, Daniel Silverstone wrote:
> > http://lua.digital-scurf.org/ has a few more details.
> > I hope to have packages /and/ policy ready in a few weeks at most.
> 
> Today I have uploaded an initial set of lua 4.0 packages to
> 
> http://lua.digital-scurf.org/packages/
> 
> they are the plain lua 4.0 system (with shared library support for liblua
> and liblualib) -- No require, no loadlib, nothing fancy.
> 
> This is the vanilla "lua" which debian will carry.
> 
> Comments and ideas for these packages should be emailed to me as soon as
> possible please.

Moving the most flame-generating point first, for the non-Debian
members of the list :-)

I noticed you didn't expose lua_loadbuffer as an external symbol in
the shared library.  If you don't, other people may have to maintain
liblua-plus-loadbuffer40.deb, which will be a copy of liblua40.deb with
the sole difference being the name and extern status of two symbols---no
change in code...

OK, off to more Debian-y issues.

I'm not sure it makes sense to split into liblua40 and liblualib40.  I
think on size considerations it isn't worth it---on sparc (pretty
bloaty), liblualib40.so is all of 50k. Most apps I know of link to
both liblua and liblualib...

Missing /usr/share/doc/lua40/README.  Or should that be
/usr/share/doc/liblua40/README?

I've put a doc-base control file at the bottom of this message that
you may want to add as debian/lua40-doc.doc-base.

The patch effectively copies lua/test/* into lua/.  I think this is a
bad idea; aside from the pure bug of nuking lua/README, it bloats the
patch.

/usr/share/doc/lua40/examples has broken lua and luac symlinks.

I think _GNU_SOURCE is overkill; _POSIX_C_SOURCE=2 is good enough to
bring in popen().

dpkg-source: warning: file debian/lua40.prerm has no final newline (either original or modified version)
dpkg-source: warning: file debian/lua40.postinst has no final newline (either original or modified version)


> I'll be starting on the dllua40 packages tomorrow night -- these will have a
> loadlib of sorts and will be the default lua interpreter for debian.

OK.  Expect more comments then---that's a lot more controversial :-)

> Again, comments and ideas please email me soon..

I was meaning to comment on the debian policy but it was really too
abstract for me to get a handle on.  I think with concrete packages in
place, I'll be able to understand better what your policies mean.

Jay

---- snip lua40-doc.doc-base ----
Document: lua40-doc
Title: Lua 4.0 Reference Manual
Author: L. H. de Figueiredo, R. Ierusalimschy,
Abstract: Lua is an extension programming language designed to support
 general procedural programming with data description
 facilities.  This manual describes version 4.0 of the language and implementation,
 including the C API.
Section: Apps/Programming

Format: HTML
Index: /usr/share/doc/lua40-doc/manual/index.html
Files: /usr/share/doc/lua40-doc/manual/*.html
---- snip lua40-doc.doc-base ----


Reply | Threaded
Open this post in threaded view
|

Re: Lua within Debian

Daniel Silverstone
On Mon, Feb 11, 2002 at 04:44:37PM -0600, [hidden email] wrote:
> Moving the most flame-generating point first, for the non-Debian
> members of the list :-)

Makes sense :)

> I noticed you didn't expose lua_loadbuffer as an external symbol in
> the shared library.  If you don't, other people may have to maintain
> liblua-plus-loadbuffer40.deb, which will be a copy of liblua40.deb with
> the sole difference being the name and extern status of two symbols---no
> change in code...

Hmm, oookay, I suppose I can do that.

> I'm not sure it makes sense to split into liblua40 and liblualib40.  I
> think on size considerations it isn't worth it---on sparc (pretty
> bloaty), liblualib40.so is all of 50k. Most apps I know of link to
> both liblua and liblualib...

When I was discussing this with other Debian people it was recommended that
they be split out into separate packages -- particularly since links-lua
uses liblua but not liblualib I believe.

> Missing /usr/share/doc/lua40/README.  Or should that be
> /usr/share/doc/liblua40/README?

Oops -- my bad.

> I've put a doc-base control file at the bottom of this message that
> you may want to add as debian/lua40-doc.doc-base.

Thanks -- I've added this although my knackered brain can't remember what
exactly this does or why :)

> The patch effectively copies lua/test/* into lua/.  I think this is a
> bad idea; aside from the pure bug of nuking lua/README, it bloats the
> patch.

I have /no/ idea how that happened :( (I've fixed it though)

> /usr/share/doc/lua40/examples has broken lua and luac symlinks.

Will fix that

> I think _GNU_SOURCE is overkill; _POSIX_C_SOURCE=2 is good enough to
> bring in popen().

Defining _GNU_SOURCE was a fix to allow it to compile on Hurd-i386 as
provided to me by a hurd developer -- I don't think it harms things to be
defined.

> dpkg-source: warning: file debian/lua40.prerm has no final newline (either original or modified version)
> dpkg-source: warning: file debian/lua40.postinst has no final newline (either original or modified version)

That'll teach me to trust vi :)

> > I'll be starting on the dllua40 packages tomorrow night -- these will have a
> > loadlib of sorts and will be the default lua interpreter for debian.
> OK.  Expect more comments then---that's a lot more controversial :-)

Indeed -- Fortunately things have been constructive so far.

> > Again, comments and ideas please email me soon..
> I was meaning to comment on the debian policy but it was really too
> abstract for me to get a handle on.  I think with concrete packages in
> place, I'll be able to understand better what your policies mean.

Yeah -- the policy is a little hard to get /MY/ head around right now, but I
made a start at least :)

> ---- snip lua40-doc.doc-base ----
[snip]
> ---- snip lua40-doc.doc-base ----

Thanks for that -- I'll fold them in right now....

Uploaded the lot as -2 stuff.

http://lua.digital-scurf.org/packages/lua_4.0/4.0-2/

(I restructed that to allow history)

Again, comments gratefully received.

Thanks

Dan

-- 
Daniel Silverstone                               http://www.digital-scurf.org/
Hostmaster, Webmaster, and Chief Code Wibbler          Digital-Scurf Unlimited
GPG Public key available from keyring.debian.org               KeyId: 20687895
On a clear disk you can seek forever.
		-- P. Denning

Attachment: pgpwe42MRkeNE.pgp
Description: PGP signature

Reply | Threaded
Open this post in threaded view
|

Re: Lua within Debian

Daniel Silverstone
On Mon, Feb 11, 2002 at 11:20:28PM +0000, Daniel Silverstone wrote:
> > I noticed you didn't expose lua_loadbuffer as an external symbol in
> > the shared library.  If you don't, other people may have to maintain
> > liblua-plus-loadbuffer40.deb, which will be a copy of liblua40.deb with
> > the sole difference being the name and extern status of two symbols---no
> > change in code...
> Hmm, oookay, I suppose I can do that.

Unfortunately I've gone blank on where to do this.

do I rename parse_buffer in ldo.c ?

Bah -- I could read the archives but I think sleep is best for me now.

Dan

-- 
Daniel Silverstone                               http://www.digital-scurf.org/
Hostmaster, Webmaster, and Chief Code Wibbler          Digital-Scurf Unlimited
GPG Public key available from keyring.debian.org               KeyId: 20687895
A visit to a strange place will bring fresh work.

Attachment: pgpU0MNXmPCA_.pgp
Description: PGP signature

Reply | Threaded
Open this post in threaded view
|

Re: Lua within Debian

Daniel Silverstone
In reply to this post by Daniel Silverstone
On Mon, Feb 11, 2002 at 09:45:46PM -0200, Luiz Henrique de Figueiredo wrote:
> > > I noticed you didn't expose lua_loadbuffer as an external symbol in
> > > the shared library.
> 
> Lua 4.0 officially has no lua_loadbuffer and friends.
> *Please*, package the official Lua 4.0 code. You may want to add the patch
> as a separate thing, of course. Thanks.

Hmm, I can either package it in the "Debian version" of lua 4.0 or else I
could provide an "alternative" liblua package.

My current favourite is to make the symbol exposed but guard the definition
of it in lua.h with something like

#ifdef DEBIAN_LOADBUFFER
....
#endif

How does that sit with people?

-- 
Daniel Silverstone                               http://www.digital-scurf.org/
Hostmaster, Webmaster, and Chief Code Wibbler          Digital-Scurf Unlimited
GPG Public key available from keyring.debian.org               KeyId: 20687895
Brain fried -- Core dumped

Reply | Threaded
Open this post in threaded view
|

Re: Lua within Debian

Jay Carlson

On Monday, February 11, 2002, at 06:57 PM, Daniel Silverstone wrote:

On Mon, Feb 11, 2002 at 09:45:46PM -0200, Luiz Henrique de Figueiredo wrote:
I noticed you didn't expose lua_loadbuffer as an external symbol in
the shared library.

Lua 4.0 officially has no lua_loadbuffer and friends.
*Please*, package the official Lua 4.0 code. You may want to add the patch
as a separate thing, of course. Thanks.

Hmm, I can either package it in the "Debian version" of lua 4.0 or else I
could provide an "alternative" liblua package.

My current favourite is to make the symbol exposed but guard the definition
of it in lua.h with something like

#ifdef DEBIAN_LOADBUFFER
....
#endif

How does that sit with people?

The only other thought I have is to NOT change their names, but just remove the static flag. That way, liblua.so is not exporting anything new in the public lua_foo namespace.

The alias lua_loadbuffer could then be applied either through a #define or a function exported in another library. Or maybe better yet, we throw it in the Debian namespace like dllua_loadbuffer.

In any case, the goal is to make sure developers using this function understand that it is not a standard function. If Debian users were building from source, we could just tell them to apply a patch to the pristine sources, but they use binaries, and there are significant benefits to maintainers, developers, and end-users in not shipping two conflicting versions of a shared library when the differences are so small.

(BTW, Debian regularly ships heavily patched versions of other interpreters. tk8.0 through tk8.2 ship not only with a full set of internals include files, but also with the "plus" patch applied, which exports significant user-visible functionality.)

Jay