Re: [gentoo-dev] lua upgrade plan

[William Hubbs]

On Sat, Jul 01, 2017 at 01:16:02PM +0500, Azamat Hackimov wrote:
> 2017-06-30 22:16 GMT+05:00 William Hubbs <williamh@g.o>:
>
> > All,
> >
> > Upstream does not support liblua as a shared library, and they do not
> > support installing multiple versions of lua onto a system. After
> > conferring with the other lua maintainer, the decision has been made to
> > remove this custom support from our lua package as well. This has been
> > talked about many times upstream.
>
>
> Lua devs very "hostile" to Linux distributers. I don't see why we should do
> as they want to do.
> They not have open vcs to simply see what they changes in new release, they
> don't accepts
> patches for system integration. They didn't even elementary easy-to-use
> build system. Just
> look to another distributives, they all do versioned and shared libraries
> of Lua 5.{1,2,3}. Fedora
> devs did custom Autotools-based buildsystem, Debian - provided pkg-config
> files. There also
> exists excellent LuaDist framework - still outdated, yes, but we can take
> from them CMake
> buildsystem to provide better integration into Gentoo enviroment. You have
> so many options
> but you still want to follow unwelcome Lua rules.

It is Gentoo's policy to stay as close to upstream as possible. However,
there are a couple of things that I can say about lua from what I've
seen so far.


> > They do not want it, and using liblua as a shared library causes
> > performance issues.
> >
>
> Why, we live in XXI century, where this argument came from? What about
> security, did you
> forgot about it? How do you planning to do backward compatibility with old
> lua5.1 libraries
> and projects? They definitely have breakage since lua 5.2 and 5.3 not
> compatible with each
> other. Why Lua can't have same eclass as multislotted Python or Ruby? Lua
> ecosystem not
> so big, about 500 packages so why there no even little efforts to make Lua
> support in Gentoo
> better?

Portage has improved handling security issues like the ones with static
libraries a lot from what I understand by making --with-bdeps y the
default setting most of the time.

The lua build system seems to have a way to tell it to support
older things, there is a LUA_COMPAT_ALL compile flag. We'll have to see
what that does when it hits ~arch.

See this article for why using liblua as a shared library is not
recommended.

http://article.gmane.org/gmane.comp.lang.lua.general/18519

Yes, it talks about the interpretor, but it goes further and really
discourages even making a shared library available.

>
> --
> From Siberia with Love!

William