Re: [gentoo-dev] lua upgrade plan
On Mon, Jul 03, 2017 at 03:12:00AM +0700, Vadim A. Misbakh-Soloviov wrote: > By the way, it will also brake some proprietary games, that distributes via > steam, humble, gog and so on. > > Some of them depends on shared lua and doesn't bundle it (instead, their > installer calls apt (since they're doing games for ubuntu), but since we have > no apt, we (gamerlay/games team) just writing proper DEPENDs, unpacking the > content, and installing it. > > So, if shared lua will be dropped, we will either have a bunch of broken > games > or used to create some kludgy "lua-shared" custom ebuild, which is worse way > of doing the things. Are these games in the tree? I don't see anything related to steam or humble. William signature.asc Description: Digital signature
Re: [gentoo-dev] lua upgrade plan
On 02/07/17 21:12, Vadim A. Misbakh-Soloviov wrote: > By the way, it will also brake some proprietary games, that distributes via > steam, humble, gog and so on. > > Some of them depends on shared lua and doesn't bundle it (instead, their > installer calls apt (since they're doing games for ubuntu), but since we have > no apt, we (gamerlay/games team) just writing proper DEPENDs, unpacking the > content, and installing it. > > So, if shared lua will be dropped, we will either have a bunch of broken > games > or used to create some kludgy "lua-shared" custom ebuild, which is worse way > of doing the things. > > So, I'm voting for status quo. > > A custom games-lua eclass ... ?! *runs from mgorny et al * signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] lua upgrade plan
By the way, it will also brake some proprietary games, that distributes via steam, humble, gog and so on. Some of them depends on shared lua and doesn't bundle it (instead, their installer calls apt (since they're doing games for ubuntu), but since we have no apt, we (gamerlay/games team) just writing proper DEPENDs, unpacking the content, and installing it. So, if shared lua will be dropped, we will either have a bunch of broken games or used to create some kludgy "lua-shared" custom ebuild, which is worse way of doing the things. So, I'm voting for status quo.
Re: [gentoo-dev] lua upgrade plan
On Sat, Jul 01, 2017 at 01:16:02PM +0500, Azamat Hackimov wrote:
> 2017-06-30 22:16 GMT+05:00 William Hubbs :
>
> > 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
Re: [gentoo-dev] lua upgrade plan
> excellent LuaDist I'd not say it is excellent :( I'd rather say "NIH-syndromed" > 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? Well... Actually, it does. In Lua overlay. But mgorny (?) had a bunch of critics about it, so I just keeping it in Lua overlay and not proposing it to the gentoo repo anymore (I just have not enough time to rewrite it in the way it will pass mgorny's review :).
Re: [gentoo-dev] lua upgrade plan
2017-06-30 22:16 GMT+05:00 William Hubbs :
> 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.
> 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?
--
>From Siberia with Love!
[gentoo-dev] lua upgrade plan
All, lua has been behind in Gentoo for a while, but I have time now to start working on fixing that this coming week, so consider this a heads-up that things are going to start happening with regards to dev-lang/lua and its dependencies. 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. They do not want it, and using liblua as a shared library causes performance issues. Since that support never came out of p.mask, I will be removing it this weekend or Monday at the latest and committing the next version of lua to ~arch. Once we get the tree fixed, I will address the lua overlay, preferably we can address it by migrating things there to the tree. I will be around most of the time next week, so I will be able to follow up on issues. Thanks, William signature.asc Description: Digital signature
