From: William Hubbs <williamh@gentoo.org>
To: Azamat Hackimov <azamat.hackimov@gmail.com>
Cc: gentoo-dev@lists.gentoo.org, rafaelmartins@gentoo.org
Subject: Re: [gentoo-dev] lua upgrade plan
Date: Sat, 1 Jul 2017 11:53:59 -0500 [thread overview]
Message-ID: <20170701165359.GB13095@linux1.home> (raw)
In-Reply-To: <CAFqVybqM2LoJ9PpqsR_bYRsmqn5jfpO9qqafHDvX5peAd4miGg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2678 bytes --]
On Sat, Jul 01, 2017 at 01:16:02PM +0500, Azamat Hackimov wrote:
> 2017-06-30 22:16 GMT+05:00 William Hubbs <williamh@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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2017-07-01 16:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-30 17:16 [gentoo-dev] lua upgrade plan William Hubbs
2017-07-01 8:16 ` Azamat Hackimov
2017-07-01 12:18 ` Vadim A. Misbakh-Soloviov
2017-07-01 16:53 ` William Hubbs [this message]
2017-07-02 3:55 ` [gentoo-dev] " Duncan
2017-07-02 15:30 ` William Hubbs
2017-07-03 1:43 ` Duncan
2017-07-03 3:32 ` Andrew Savchenko
2017-07-03 12:08 ` Martin Vaeth
2017-07-02 20:12 ` [gentoo-dev] " Vadim A. Misbakh-Soloviov
2017-07-02 20:14 ` M. J. Everitt
2017-07-03 14:41 ` William Hubbs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170701165359.GB13095@linux1.home \
--to=williamh@gentoo.org \
--cc=azamat.hackimov@gmail.com \
--cc=gentoo-dev@lists.gentoo.org \
--cc=rafaelmartins@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox