1 |
2017-06-30 22:16 GMT+05:00 William Hubbs <williamh@g.o>: |
2 |
|
3 |
> All, |
4 |
> |
5 |
> Upstream does not support liblua as a shared library, and they do not |
6 |
> support installing multiple versions of lua onto a system. After |
7 |
> conferring with the other lua maintainer, the decision has been made to |
8 |
> remove this custom support from our lua package as well. This has been |
9 |
> talked about many times upstream. |
10 |
|
11 |
|
12 |
Lua devs very "hostile" to Linux distributers. I don't see why we should do |
13 |
as they want to do. |
14 |
They not have open vcs to simply see what they changes in new release, they |
15 |
don't accepts |
16 |
patches for system integration. They didn't even elementary easy-to-use |
17 |
build system. Just |
18 |
look to another distributives, they all do versioned and shared libraries |
19 |
of Lua 5.{1,2,3}. Fedora |
20 |
devs did custom Autotools-based buildsystem, Debian - provided pkg-config |
21 |
files. There also |
22 |
exists excellent LuaDist framework - still outdated, yes, but we can take |
23 |
from them CMake |
24 |
buildsystem to provide better integration into Gentoo enviroment. You have |
25 |
so many options |
26 |
but you still want to follow unwelcome Lua rules. |
27 |
|
28 |
|
29 |
> They do not want it, and using liblua as a shared library causes |
30 |
> performance issues. |
31 |
> |
32 |
|
33 |
Why, we live in XXI century, where this argument came from? What about |
34 |
security, did you |
35 |
forgot about it? How do you planning to do backward compatibility with old |
36 |
lua5.1 libraries |
37 |
and projects? They definitely have breakage since lua 5.2 and 5.3 not |
38 |
compatible with each |
39 |
other. Why Lua can't have same eclass as multislotted Python or Ruby? Lua |
40 |
ecosystem not |
41 |
so big, about 500 packages so why there no even little efforts to make Lua |
42 |
support in Gentoo |
43 |
better? |
44 |
|
45 |
-- |
46 |
From Siberia with Love! |