Ravenports / ravenadm

Administration tool for Ravenports
http://www.ravenports.com
ISC License
17 stars 3 forks source link

switch lua, perl oldest versions for latest. #23

Closed jrmarino closed 4 years ago

jrmarino commented 4 years ago

Update floating default if necessary.

jrmarino commented 4 years ago

don't forget to update autoselect-perl at the same time.

kraileth commented 4 years ago

Any chance to not drop Lua 5.2? It's still the standard version on FreeBSD and there are modules that aren't compatible with newer versions. I think lua-sysctl is one such candidate - and it's one port that I actually have in use.

jrmarino commented 4 years ago

we can drop lua53 instead...

jrmarino commented 4 years ago

and really - the "proper" approach here is to talk to lua-sysctl (and others?) authors and see if there can be an update. Lua52 is now 2 releases behind.

kraileth commented 4 years ago

I fear that Lua is a pretty heterogeneous ecosystem with some projects deliberately targeting older releases that they decided to stick with. Don't know about FreeBSD's plans, but since that sysctl module is tied to that OS (and DragonFly), I don't know if the author would be willing to make it work with 5.3 and now 5.4 if 5.2 is going to stay the default for the FPC. Would probably be easier if e.g. 5.2 was an official LTS version or something... But meh.

From the RP perspective we have two Lua ports that don't build with both 5.2 and 5.3: lua-sysctl which requires the former and lua-ada which seems to require the latter. So I guess dropping 5.3 instead wouldn't make a lot of sense either (except if lua-ada is 5.4-ready). But even then there are probably many more modules out there that will require 5.3.

I guess contacting the author won't hurt in any case.

jrmarino commented 4 years ago

that's was going to be my comment -- doesn't hurt to ask and then at least we know. And sticking with 5.2 and ignoring future releases isn't really forward thinking. The only justification for it that I see is "I am not developing this s/w anymore" and then we are in abandonware territory.

jrmarino commented 4 years ago

to be clear -- I had a temporary waiver for python to have 3 variants, but I didn't want to carry more than 2 for all the other langs. And we are driving to 2 for python as well.

kraileth commented 4 years ago

Notified the author, let's see what happens. Yes, I'd also like to avoid having three versions in parallel. It might be ok as a temporary solution, but for Python we all knew that there was a fixed date when Py2 would die and support for it could be cut back more and more after that date. For Lua 5.2 I don't have any idea as to when would be a good time to get rid of a third variant if it was to be introduced.

kraileth commented 4 years ago

Lua-sysctl is not abandonware, I got an answer already. It is as I had feared: The module is maintained by a single developer who does not have the resources to support more than the current FreeBSD release branch with the default Lua version. The latter still being 5.2, I guess that I'm out of luck.

In fact FreeBSD still ships 5.1 as well and probably won't be too keen on making the switch... Maybe a typical Lua problem: Since it's so often used as an embedded language, many projects choose one branch and stick with it for a very long time. :disappointed:

jrmarino commented 4 years ago

well, that sounds like BS. The module is written. Is lua53 really so much different from lua52 that it takes "resources" to support. come on ...

kraileth commented 4 years ago

The "resources" were my wording. He just replied that he currently didn't have the time to support / test it with other Lua versions. Don't know how much the language has changed. But obviously it's enough that some modules need to be re-worked (I've seen it quite some time on modules that changes had to be made to support 5.3).

jrmarino commented 4 years ago

If memory serves, the only impact to changing the lua default is that it changes the value of ":lua_default" I don't believe that's used much anyway. Your ports have variants which define which lua to use. So we'd leave lua52 in place. The ports that build with lua53 and lua54 would have lua52 variant dropped and replaced with lua54. The ones that can't change won't, I guess.

we just have to search for ":lua_default" is see what could be impacted. And there's only an impact is lua52 is the default. If it's lua53, we'd leave that as the default for now.

Sorry for talking in conditions. I didn't look anything up yet.

kraileth commented 4 years ago

Just to be sure I understand it correctly: You'd keep the Lua 5.2 interpreter and that single port (or maybe multiple ports if we come across more modules that are 5.2-only and would be desirable to have) in RP? That would be a great solution - especially as it means that 5.2 is still supported by the infrastructure even if there are no binary packages anymore for most of the modules. That way I could simply build any missing ones from unkindness if I find that I need any (working together with lua-sysctl).

BTW: Forgot to tell you that the developer of said module also wrote that he'll keep the issue open. The "help wanted" label was added to it. So if anybody else finds the time to make adjustments for 5.3 he's likely going to merge them. Or FreeBSD will eventually switch the default version (we have 5.3 in base on -CURRENT, so maybe with the release of 13.0 or something...). We'll see.

jrmarino commented 4 years ago

yes. There's no reason to remove lua52. Lua isn't really set up like PHP, Perl, Python, Ruby where's there's a "default" version. I mean, it is set up that way, but it's not really implemented. Partially because lua ports aren't generated like those others are. All we really need to do is update the lua ports that will build with lua54.

jrmarino commented 4 years ago

autoselect-perl updated internally -- will be committed with ravenadm update.