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!