[2019-03-23 16:23:27] William Hubbs:
> The first thing is liblua as a shared library. If you are using lua
> internally in a program, upstream strongly recommends not linking it
> this way; it is supposed to be statically linked into the executable.
> Because of this, and because of the amount of custom patching we do to
> maintain liblua as a shared library, I plan to stop creating the shared
> library.
Pretty sure removing the shared version of liblua will cause a large
amount of patching to be done in a lot of software that may not support
static linking out of the box.
> I'm a bit undecided still about slotting lua. I'm sure we
> need subslots so we can force rebuilds when new lua releases enter the
> tree. However, I'm still unsure whether we need slots. I don't know of
> many things in the tree that are locked to a specific version
> of lua (there is only one package based on an irc conversation I
> had this week).
> Does anyone have any thoughts? Are there more packages in the tree that
> are locked to a specific version of lua?
There should be slotting of lua, for example in the few programs that
I know will need it:
- app-editors/vis::{lua,lanodanOverlay}: Requires >=lua-5.2
does not support luajit (incomplete 5.2 compatibility)
- media-video/mpv: requires lua:5.2 or luajit
doesn’t seems to plan supporting 5.3[1]
Also the lua overlay, which I would highly recommend using as a base
has a slotted version of lua, instead of extending SLOT="0".
1: https://github.com/mpv-player/mpv/wiki/FAQ#Why_does_mpv_not_support_Lua_53
