[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] LuaBinaries
- From: Daniel Silverstone <dsilvers@...>
- Date: Fri, 01 Apr 2005 17:29:07 +0100
On Fri, 2005-04-01 at 18:18 +0200, Mike Pall wrote:
> A reverse dependency search shows that all of the packages need both.
> Splitting Lua up into 6 packages is maybe overdoing it a bit?
Perhaps it was.
> > > As Mike already commented, do we really need shared libraries outside
> > > Windows?
> > Yes, Very much so. I count seven programs other than Lua itself which
> > depend on liblua50 in Debian And another three or four which use
> > liblua40
> No. There is no intrinsic necessity. All of the referenced packages
> embed Lua and are at least an order of magnitude larger than Lua itself.
> Static linking would work just fine. Lua is not libc. Nobody is likely
> to run any of these packages in parallel or would even take notice.
Static linking loses the one bugfix catches all packages benefit of the
> If you really insist on making shared libraries (for whatever policy
> reason) -- ok, go ahead. But please, please do NOT link the main 'lua'
> standalone executable with it! As I explained, the performance of the
> Lua core VM suffers badly when compiled with -fPIC on x86.
> [Hey ... or make /usr/bin/perl link against libperl*.so. Sure would
> be a fair deal. Oh and it would save 1 MB (_one_ Megabyte!) on
> everyone's disk. Let's see the ensuing storm ...]
These days my packaging work on Lua is all but static. I would not be
against someone taking the packages over from me and re-doing them to be
better for Lua. I simply don't have any time to invest the effort to
correctly repackage them without risking damaging the installability or
buildability of the packages which depend on it.
Also such a transition is possibly best left for after Debian release
Ultimately I personally believe that the shared library form of Lua is
worthwhile for the bugfix potential. The zLib shared library is not that
big either and the benefits of it being a shared library severely
outweighed the performance issues when it had a security flaw. *BUT* as
I said above, I'm not utterly wedded to the packages and if someone else
feels they can do better by the community and better by Debian through
redoing the packaging work then I invite them to do so.
Daniel Silverstone http://www.digital-scurf.org/
PGP mail accepted and encouraged. Key Id: 2BC8 4016 2068 7895