Re: 5.1 beta problem linking luac against .so

[Klaus Ripke <paul-lua@...>]

On Thu, Nov 24, 2005 at 11:55:06PM +0100, Enrico Tassi wrote:
> I completely agree about your performance and disk-space considerations.
> _but_ Debian has some "standards"...
who are they to set "standards" how software is supposed to work?
everybody has their "standards", one more broken than the other.

> If you will need lua in applications that are not CPU-bound you should
> prefer the .so, and this is because huge systems like Debian have to
> consider maintainibility (read: updates should be easy).
IMHO this is a gross misconception.
>From practice, running a couple of dozen boxes using various
linux distros, *BSDs and others I know many admins which
rather stick with their known problems then introduce new ones.

> I know LUA is a really
> stable software and patches are not so frequent... but I still think that 
> we should prefer the easy-to-maintain way.
Easy to maintain?
Like just redirecting liblua.so.5 from liblua.so.5.0 to liblua.so.5.1?
In accordance with all those "standards" about major and minor and x,
but blowing up just plain everything.

> If you want all the CPU cicles you can have you can link lua statically
> just changing the linker command line arguments, not a big problem. 
for an "apt get" updating any number of binaries
is even less a problem. actually no problem at all.

> Currently on Debian there are few packages depending on liblua50, but I
> hope they will grow:
> 
>   xmoto
> ...
It's great if they are depending on liblua50,
so nothing is going to happen there.
However, any binary somehow dynamically linked to "Lua 5"
will blow up with 5.1, as lua major version numbers do not
imply API compatibility, at least not on link level
(as much is done by macros).
And that's the opposite of maintainability:
if you can not upgrade a library because it's likely to break something.

This versioning policy may be considered "bad style"
by Debian packagers, and actually I consider a
major-version-linkage-upwards-compatibility-policy
an interesting idea, and would not mind the next thing
being labeled Lua 6.
Yet, it's the packager's job to develop an overall
coherent distribution, not the Lua author's task
(considering all those platforms, many without
a concept of major, minor or patchlevel versions).

After all, as far as distributions are concerned,
they can easily re-compile hundreds of binaries for any new
lib version and any admin can just as easily update
hundreds of binaries with a single "apt" or "rpm"
or whatever command, wasting less bandwidth than one
single Firefox update.

OTOH, I'd really hate to see my app blow up just because
of some "update" and so I will always link it statically.
Using dietlibc or similar, it's not only self-contained
and much faster, it's even smaller.



cheers