Mailing List Archive

[RFC] Dropping dev-lang/lua:5.2
Dear everyone,

As many (if not most) of you know, the Lua ecosystem is somewhat awkward
owing to the facts that on the one hand dev-lang/lua upstream has never
officially declared end of life on older versions, and on the other
dev-lang/luajit has never moved beyond 5.1 with their API support.
Still, this doesn't mean WE have to support all branches in
perpetuity... Between 5.1 being effectively here to stay due to LuaJIT
and 5.4 still being relatively new (meaning it cannot feasibly replace
5.3 at this point), I would like to start by getting rid of 5.2 first.

Having just had a look on p.g.o. at the list of packages utilising the
relevant USE_EXPAND flags (as well as at net-proxy/haproxy, which
*still* hasn't been ported to Lua eclasses), it looks like it would in
fact be quite easy to do - among both single- and multi-impl Lua
revdeps, there are none which only support 5.2.

PS. Another benefit here would be that we wouldn't have to deal with
internal interpreter weirdness demonstrated by
https://bugs.gentoo.org/768048 which upstream have long since fixed in
5.3+ but my experiments suggest would be non-trivial to address in 5.2
without risking serious breakage.

WDYT?

--
Marecki
Re: [RFC] Dropping dev-lang/lua:5.2 [ In reply to ]
On Fri, Jul 09, 2021 at 11:36:21AM +0100, Marek Szuba wrote:
> Dear everyone,
>
> As many (if not most) of you know, the Lua ecosystem is somewhat awkward
> owing to the facts that on the one hand dev-lang/lua upstream has never
> officially declared end of life on older versions, and on the other
> dev-lang/luajit has never moved beyond 5.1 with their API support.
> Still, this doesn't mean WE have to support all branches in
> perpetuity... Between 5.1 being effectively here to stay due to LuaJIT
> and 5.4 still being relatively new (meaning it cannot feasibly replace
> 5.3 at this point), I would like to start by getting rid of 5.2 first.

Actually upstream does say when they will stop supporting each version
[1].

5.1 can go because luajit would cover it, but 5.2 is also a candidate.

William

[1] http://www.lua.org/versions.html
Re: [RFC] Dropping dev-lang/lua:5.2 [ In reply to ]
On 2021-07-09 15:35, William Hubbs wrote:

>> As many (if not most) of you know, the Lua ecosystem is somewhat awkward
>> owing to the facts that on the one hand dev-lang/lua upstream has never
>> officially declared end of life on older versions,
>
> Actually upstream does say when they will stop supporting each version
> [1].

Um, where? Because I've looked at this page before, I've looked at it
again just now and I all can see there is that there will be no further
releases of Lua versions up to and including 5.2, and that there will
*probably* be no more 5.3 releases. No official End of Life statements,
no EOL timeline, and 5.3 is apparently both dead and alive at the same
time - which is fine for cats but not so for software.

> 5.1 can go because luajit would cover it

Alas, not quite.

One, we've got quite a few packages in the tree which currently declare
compatibility with lua5-1 but not luajitt. This could probably be
addressed quite easily, the worst I have seen so far after substituting
luajit for lua5-1 is some memory leaks, but it will take some time and
effort to test all such packages.

Two, more importantly, making LuaJIT the only available implementation
of the 5.1 API would severely cripple Lua support on alpha, hppa, ia64,
riscv, s390 and sparc (which have all got keywords on dev-lang/lua:5.1
but are not supported by LuaJIT at all) as well as force arm64 and
ppc64le users to use a 2.1-beta version. This I am afraid might be the
deal breaker, as I honestly cannot imagine Gentoo suddenly implementing
support for all those arches.

--
Marecki
Re: [RFC] Dropping dev-lang/lua:5.2 [ In reply to ]
On Fri, Jul 09, 2021 at 04:49:59PM +0100, Marek Szuba wrote:
> On 2021-07-09 15:35, William Hubbs wrote:
>
> >> As many (if not most) of you know, the Lua ecosystem is somewhat awkward
> >> owing to the facts that on the one hand dev-lang/lua upstream has never
> >> officially declared end of life on older versions,
> >
> > Actually upstream does say when they will stop supporting each version
> > [1].
>
> Um, where? Because I've looked at this page before, I've looked at it
> again just now and I all can see there is that there will be no further
> releases of Lua versions up to and including 5.2, and that there will
> *probably* be no more 5.3 releases. No official End of Life statements,
> no EOL timeline, and 5.3 is apparently both dead and alive at the same
> time - which is fine for cats but not so for software.

I guess it is a matter of interpretation then, "there will be no further
releases" means end of life, to me anyway.

I do agree that we aren't sure about 5.3, but "there will be no further
releases" is pretty clear to me.
Older than lua 5.3 is dead.

> > 5.1 can go because luajit would cover it
>
> Alas, not quite.
>
> One, we've got quite a few packages in the tree which currently declare
> compatibility with lua5-1 but not luajitt. This could probably be
> addressed quite easily, the worst I have seen so far after substituting
> luajit for lua5-1 is some memory leaks, but it will take some time and
> effort to test all such packages.
>
> Two, more importantly, making LuaJIT the only available implementation
> of the 5.1 API would severely cripple Lua support on alpha, hppa, ia64,
> riscv, s390 and sparc (which have all got keywords on dev-lang/lua:5.1
> but are not supported by LuaJIT at all) as well as force arm64 and
> ppc64le users to use a 2.1-beta version. This I am afraid might be the
> deal breaker, as I honestly cannot imagine Gentoo suddenly implementing
> support for all those arches.

Some of the arches you listed are not stable, so I don't think we have
to worry about those arches (see arches.desc). If the arch isn't stable,
we can't guarantee anything.

There is activity in luajit upstream, so hopefully they will do a new
release that supports the newer lua versions. I do agree that it is
problematic that they only support lua 5.1.

William
Re: [RFC] Dropping dev-lang/lua:5.2 [ In reply to ]
On 2021-07-09 17:34, William Hubbs wrote:

>>> Actually upstream does say when they will stop supporting each version
>>> [1].
>>
>> Um, where? Because I've looked at this page before, I've looked at it
>> again just now and I all can see there is that there will be no further
>> releases of Lua versions up to and including 5.2, and that there will
>> *probably* be no more 5.3 releases. No official End of Life statements,
>> no EOL timeline, and 5.3 is apparently both dead and alive at the same
>> time - which is fine for cats but not so for software.
>
> I guess it is a matter of interpretation then, "there will be no further
> releases" means end of life, to me anyway.

Okay, in that case everyone who interprets this as Lua 5.1 having
officially been EOLed can substitute the relevant part of the first
sentence of my RFC with "the Lua ecosystem is a bloody nightmare because
new versions regularly introduce API incompatibilities and a lot of
application developers have never bothered to update their Lua code for
anything newer than 5.1 in spite of <dev-lang/lua-5.3 having been EOLed,
in part because dev-lang/luajit having never reached compatibility with
even the 5.2 API".

Not that it changes any of my conclusions, IMHO.

>> Two, more importantly, making LuaJIT the only available implementation
>> of the 5.1 API would severely cripple Lua support on alpha, hppa, ia64,
>> riscv, s390 and sparc (which have all got keywords on dev-lang/lua:5.1
>> but are not supported by LuaJIT at all) as well as force arm64 and
>> ppc64le users to use a 2.1-beta version. This I am afraid might be the
>> deal breaker, as I honestly cannot imagine Gentoo suddenly implementing
>> support for all those arches.
>
> Some of the arches you listed are not stable, so I don't think we have
> to worry about those arches (see arches.desc). If the arch isn't stable,
> we can't guarantee anything.

I am pretty sure that the ~arch status does NOT give us the right to
de-keyword packages en masse.

> There is activity in luajit upstream, so hopefully they will do a new
> release that supports the newer lua versions. I do agree that it is
> problematic that they only support lua 5.1.

I really do hope Mike Pall (i.e. LuaJIT upstream) will eventually
release stable 2.1 - but between how long it has been since the latest
beta and that he responds with something between impatience and
hostility to any requests for a new release, LuaJIT has to me been
looking more and more like one of those artisanal projects (not
necessarily software ones) whose creators chip at them in perpetuity
without ever reaching the state worthy of being considered finished.

--
Marecki