|Summary:||[NEW PORT] lang/lua54: Powerful, efficient, lightweight, embeddable scripting language|
|Product:||Ports & Packages||Reporter:||Russell Haley <russ.haley>|
|Component:||Individual Port(s)||Assignee:||freebsd-ports-bugs mailing list <ports-bugs>|
|Status:||Closed Not Enough Information|
|Severity:||Affects Only Me||CC:||andrew, dbn, jbeich, mat, portmgr|
Description Russell Haley 2018-07-14 23:00:10 UTC
Hello, We have been working on a new port for lua 5.4 - which is still in a beta phase (work2). I'd like to request an exp-run to see what happens. The last exp-run for Lua that I am aware of was done with 5.3.3 last year. The report is in bug 220281. The patch for Lua 5.4 is in review here: https://reviews.freebsd.org/D14709 To apply the patch create a lua54 directory under ports/lang/.
Comment 1 Antoine Brodin 2018-07-15 07:03:56 UTC
In my opinion the solution for lua is flavors. An exp-run is not needed for 1 new port.
Comment 2 andrew 2018-07-15 12:49:34 UTC
(In reply to Antoine Brodin from comment #1) You're suggesting that ports that use Lua should all be changed to use flavors to specify the Lua version (which obviously involves a bunch of changes to Uses/lua.mk and the existing ports)? Right now what happens is that some ports are using PKGNAMEPREFIX directly, so that for example lua-lpeg installs as lua53-lpeg or lua54-lpeg depending on Lua version. (Many) others just use whatever the default lua version is.
Comment 3 Russell Haley 2018-07-15 14:41:27 UTC
Hi Antoine, There are 15 failing ports in the prior run that (as you noted in the bug report) cause 70 others to fail. While your opinion may be very valid, I have a week off of work and I was hoping to patch as many of the broken ports as I can and I'm not inclined to take on flavors at the moment. If I *can't* get a exp-run for 5.3.5 or 5.4 this week then the likely-hood of this problem ever betting fixed drops pretty close to nil. Further, if is not a requirement of the ports system, I'm not sure why Lua needs to be forced into this pattern? I know that the mono port doesn't used flavors, does php or phython use flavors? Thanks for your help Antoine!
Comment 4 Russell Haley 2018-07-15 19:11:26 UTC
Hi Antoine, I've been ruminating and have concluded that I could not agree to look into flavors without an exploratory run first. Let me further my request: I remember looking into the "indirection package" that was on Debian Jessie and thought it a good idea. My assumption at the time was that the ports system was a better place to handle dependencies because well, that's where it was done on FreeBSD. As well, there are other members of the Lua community looking into "Unix" standardization and I was notified as the maintainer of Lua on FreeBSD. I'm all for making Lua better on FreeBSD, which is why I became the port maintainer for 5.3 and want the maintainer-ship for 5.4. If you - as representing the ports team - feel so strongly about fixing Lua then I would like to work towards the solution you think is best. Therefore in the mindset of pushing Lua forward to a better solution, I would like to request an exp-run so that I can empirically catalogue the build failures and triage the situation. As evidence of my intent, please see the notes I left in the prior exp-run. I ran out of time last year. This year I've made fixing Lua on FreeBSD my primary goal and I am hoping that my current opportunity doesn't slip away. I look forward to working together with the ports team to improve FreeBSD in any way I can, but I really need that exp-run first. :) Sincerely, Russell Haley
Comment 5 andrew 2018-07-15 22:52:38 UTC
Having looked at the way that php and python use flavors, I think they are a bad fit for Lua-using applications, though they may be a useful way to handle Lua modules (which are currently doing simple PKGNAMEPREFIX stuff without using the flavor system). (Notably, lua is very small compared to php or python, 1.2MB code + 400kB docs compared to something like 67MB for python2; this makes installing multiple versions much less of an issue.) Russell, what exactly are you expecting here? Adding a 5.4 port won't affect any other port build unless Uses/lua.mk is updated to include 5.4 as an allowed version or the default version.
Comment 6 Russell Haley 2018-07-16 02:00:44 UTC
(In reply to andrew from comment #5) I'm sorry, I thought bumping the default value was the purpose of an exp-run. It hadn't occurred to me I wasn't specific about that. Yes, I was hoping to have the default Lua version bumped to 5.4 to record the fallout. The same as was done with bug 220281 (for Lua 5.3). In terms of managing Lua packages, I had briefly discussed with jbeich the possibility of using LuaRocks. With the imminent release of LuaRocks 3.0, I was hoping to potentially leverage that.
Comment 7 Russell Haley 2018-08-02 04:34:56 UTC
Hi, Andrew has added a patch to Uses/lua.mk that incorporates flavors and 5.4 support. https://reviews.freebsd.org/D16494
Comment 8 Russell Haley 2018-11-02 05:11:51 UTC
Hi, Is anything happening with this?
Comment 9 Kubilay Kocak 2018-11-02 05:41:30 UTC
(In reply to Russell Haley from comment #8) This bug adds a new port, but does not extent USES=lua (the framework) to (make it possible to) use it. The review in comment 7 extends USES=lua, including adding 54 support in the framework, but does not add a lua54 port. Both reviews are in the 'needs review' state. Perhaps this could land before the framework changes. Perhaps they could be combined (so its less confusing to review isolated changes). Either way there's nothing I can see that can happen in this bugzilla issue until the reviews take their course and are ultimately 'accepted'.
Comment 10 Russell Haley 2019-01-29 06:19:11 UTC
Closing bug. Lua 5.4 still seems to be a ways off.