On Sat, Jul 01, 2017 at 01:16:02PM +0500, Azamat Hackimov wrote:
> 2017-06-30 22:16 GMT+05:00 William Hubbs <willi...@gentoo.org>:
>
> > 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
signature.asc
Description: Digital signature
