Effectively (or officially, depending on interpretation) EOLed, halfway between the de-facto-standard 5.1 and possibly-still-supported 5.3, no packages in the tree which could not use one of the two instead of 5.2. USE=lua_single_target_lua5-2, USE=lua_targets_lua5-2 and dev-lang/lua:5.2 masked. In 30 days the package will be removed, and both Lua eclasses and the profiles will cease to treat the targets as supported. Removal from LUA_COMPAT to follow at the discretion of package maintainers.
Please reconsider. Removing 5.2 effectively pushes users of the following packages to install 5.1. dev-games/openscenegraph dev-games/openscenegraph-openmw app-misc/worker games-rpg/sumwars media-video/vlc net-analyzer/wireshark net-p2p/eiskaltdcpp www-client/elinks x11-wm/notion Following packages support 5.2 or luajit. This again pushes those, who don't use luajit to install 5.1. dev-libs/efl media-video/mpv net-im/swift www-apps/cgit 5.1 is not a «de-facto standard», but an EOL, way more than 5.2. Only reason of it being so widespread is Mike Pall's refusal to fully support 5.2 and further versions in luajit. For those who don't need luajit, moving to 5.1 is a setback in many ways — for example, it lacks bitops, goto, hexadecimal escapes in strings, and many more. Furthermore, it's way slower and memory-hungry, as it lacks multiple optimizations, put to production in 5.2.
(In reply to Quote from comment #1) > Please reconsider. I am sorry but at this point it's either "remove 5.2" or "remove both 5.1 and 5.2" - and at least option 1 doesn't require us to actually drop any packages. Not to mention that in addition to all the previously mentioned reasons, 5.2 is by far the messiest dev-lang/lua slot to as far as packaging is concerned, > > Removing 5.2 effectively pushes users of the following packages to install > 5.1. > > dev-games/openscenegraph > dev-games/openscenegraph-openmw > app-misc/worker > games-rpg/sumwars > media-video/vlc > net-analyzer/wireshark > net-p2p/eiskaltdcpp > www-client/elinks > x11-wm/notion > > Following packages support 5.2 or luajit. This again pushes those, who don't > use luajit to install 5.1. > > dev-libs/efl > media-video/mpv > net-im/swift > www-apps/cgit > > 5.1 is not a «de-facto standard», but an EOL, way more than 5.2. If you look at the number of packages implementing lua_targets_lua5-1/lua_single_target_lua5-1 (there is a handy tool for that at packages.gentoo.org) and compare them with those for lua5-{2,3,4}, you will see that it is by far the most commonly supported implementation of the four - and that's not even counting packages explicitly requiring luajit. Sounds very much like a de-facto standard to me... And we know these numbers to fairly accurately depict upstream compatibility because during last year's migration to slotted Lua we have quite carefully checked this. > Only reason > of it being so widespread is Mike Pall's refusal to fully support 5.2 and > further versions in luajit. Oookay, let me stop you right here: 1. Even your own numbers do not support that claim - you have mentioned 9 packages supporting lua5-1 or lua5-1 but only 4 supporting lua5-1, lua5-2 or luajit. Ditto USE-flag statistics on p.g.o. 2. If LuaJIT sticking with 5.1 is enough to stop the whole ecosystem from moving on to newer APIs it must be SO much better than PUC implementations of Lua, no? Or the problem here lies elsewhere. 3. Seeing as LuaJIT is pretty much a one-man project of Mike Pall, it is entirely up to Mike Pall to decide which versions of the Lua API to support - or indeed whether to continue working on this project at all. 4. LuaJIT is Open Source so anyone wishing to port it to a newer Lua API is very much welcome to do so. Yet even the OpenResty not-a-fork, the most active one out there as far as I know, doesn't attempt to do so... Could it be because writing a JIT compiler for a new API is in fact hard? 5. We have in fact got quite a few packages in the tree which support both PUC Lua 5.3+ and LuaJIT - or indeed both older and newer versions of PUC Lua. In other words, it's not that LuaJIT actually PREVENTS anyone from using newer Lua - if they are interested in having their code keep up with Lua API/ABI changes. In fact, I would very much encourage you to direct your dissatisfaction with the current state of affairs towards making the 13 packages you have mentioned compatible with Lua 5.4 or 5.3! Even if you cannot get their respective upstreams to merge your work, we'll be happy to include them in Gentoo - subject to the usual review process, of course. > For those who don't need luajit, moving to 5.1 is a setback in many ways — > for example, it lacks bitops, goto, hexadecimal escapes in strings, and many > more. These things apply to people writing their own Lua code - and such people are very much welcome to use 5.3 or 5.4, which aren't going away from Gentoo any time soon.
...but given they haven't even added themselves to this bug's Cc list, I don't have high hopes.
Implementation tagged as historical in eclasses, targets dropped, dev-lang/lua:5.2 removed. All of this happened over 2 hours ago and since CI still hasn't complained, I think it's safe to assume everything has been done correctly.
