Re: Packaging Lua libraries

[Jay Carlson <nop@...>]

On Wed, 31 Mar 2004, Jamie Webb wrote:

> On Wednesday 31 March 2004 14:18, Andre Nathan wrote:
> > On Wed, 2004-03-31 at 09:37, Tuomo Valkonen wrote:
> > > The FHS also says of /usr/share:
> > >
> > > "It is recommended that application-specific, architecture-independent
> > > directories be placed here. Such directories include groff, perl,
> > > ghostscript, texmf, and kbd (Linux) or syscons (BSD). They may,
> > > however, be placed in /usr/lib for backwards compatibility, at the
> > > distributor's discretion. "        ^^^^^^^^^^^^^^^^^^^^^^^
> >
> > Well, I don't know. It is explicitly a recommendation, not a rule, and
> > /usr/lib is being used for every other language.
> >
> > Note also that not every UNIX system follows the FHS. Not even all Linux
> > distributions follow the FHS. So, I believe it will not be possible to
> > provide a "one size fits all" solution, we'd have to go with the most
> > common path (backwards-compatible, at least with other languages :)
>
> Other languages have a legacy. Lua doesn't (in this context at least). What
> purpose could 'backward compatibility' with other languages possibly serve?
> The Lua approach thus far has explicity been to do things the best way rather
> than the backward-compatible way, and that means using the FHS on systems
> (such as Debian) where policy dictates it.

Obviously .so files need to live in /usr/lib somewhere.  If we think
people are going to build their own custom interpreters that don't
dynamically load with loadlib, the extensions probably need to start
with "lib" so people can link them in when they build their
executables.  Version numbering would be good too.

The stub .lua loaders are arguably architecture-dependent---you could
have different naming conventions or directory paths from platform to
platform. (Think multiarch, like SGI n32/n64, or i386/x86-64.)

The rest, pure Lua, *can* live in /usr/share, and my bias is to do so.

Jay