Description
I'm creating this issue to try and centralize discussion on the topic, as it's become spread across a bunch of issues and PRs in multiple repos.
Current state of affairs
First, a summary of the situation as best I understand it:
- Aegisub 3.2.2 uses LuaJIT with 5.2 compatibility enabled when running automation scripts
- Over the past decade, many scripts have been written that all assume LuaJIT with 5.2 compat as the Lua engine
- This is not a theoretical concern; most scripts are explicitly or implicitly dependent on 5.2-specific features or LuaJIT FFI
- The most important 5.2 feature is probably the
__ipairsmetatable entry- Many of the built-in scripts rely on 5.2, via
ipairs(subs), and many third party scripts have copied this pattern
- Many of the built-in scripts rely on 5.2, via
- DependencyControl (henceforth DepCtrl) depends on FFI to function, as well as 5.2 compat, and many of the most useful automation scripts assume DepCtrl is present
- Outside of the AUR, to my knowledge no Linux distro ships DepCtrl, and how it interacts with system packaging is an unsolved problem
- The most important 5.2 feature is probably the
- These scripts, for all practical purposes, will not be rewritten
- This is not a theoretical concern; most scripts are explicitly or implicitly dependent on 5.2-specific features or LuaJIT FFI
- Many Linux distros do not compile system LuaJIT with 5.2 compatibility and have patched 3.2.2 to remove the check
- I'm unclear as to the particulars of why distros will not use a separate build for Aegisub; some clarity here would be helpful
- This means automation scripts are almost all broken, which has resulted in bugs filed against Debian and Aegisub over the years
- Aegisub 3.4.0 includes a build rewrite to Meson, which preserves the LuaJIT compatibility check
- If a suitable LuaJIT version is not found, it builds against upstream as a subproject with a custom wrap
- Multiple distros are looking to get 3.4.0 packaged but this issue is potentially a blocker
Current *nix distro status (to be updated)
Note: anything that says 3.3.x is probably based on the wangqr fork
- Arch: 3.4.0 with the LuaJIT subproject
- Debian: stable ships 3.2.2 with many patches, maintainer is looking to get 3.4.0 into unstable
- OpenSUSE: 3.3.3
- Fedora: Unknown
- Ubuntu: 3.2.2
- NixOS: ships 3.3.3
Competing priorities
In deciding how to handle this, I have a few different concerns:
- Making it as easy as reasonably possible for distros to package Aegisub
- Not shipping known-broken builds of Aegisub
- Not supporting known-broken builds of Aegisub
- Preserving, to the degree possible, functionality of the existing automation script ecosystem
- Not making it impossible to rely more heavily on DepCtrl in the future
- Not having issues opened against Aegisub due to distro patches
Possible paths forward
There is no perfect solution here, but a few options that have been brought up:
- Remove the 5.2 compatibility check on Linux
- Remove the LuaJIT check on Linux and support building against vanilla Lua 5.2
- Update all automation scripts to work with non-5.2 LuaJIT
- Disable automation scripts on Linux if a suitable LuaJIT isn't available
- Ship an AppImage/Flatpak and forget about distros (this isn't meant to be rude; it was someone's suggestion!)
- Try to make https://github.com/lunarmodules/lua-compat-5.3 work and update scripts accordingly
- Add a polyfill for
__ipairsspecifically and pray it doesn't break too many scripts
My view
This view is my own, not representative of arch1t3cht or anyone else
Any proposal that requires updating all automation scripts is dead in the water. There are god-knows how many scripts written in other communities, and even for the main TypesettingTools ones I'm functionally the only person who can commit changes, and I simply don't have the time or energy to put them all through the probably significant necessary rewrites. The only interesting subset of that, to me, is getting rid of DepCtrl's FFI usage by offering the functionality in Aegisub itself, especially now that at least on Windows we already have to bundle curl for the update checker.
My inclination is to say we should add a flag to allow building against either LuaJIT without the 5.2 flag or vanilla 5.2 (I haven't thought through which I prefer) on Linux, but disable user automation scripts if this is done, with the dropdown offering a dialog explaining why they are disabled. Hopefully, most distros will either offer a compatible system LuaJIT or use the subproject (Arch being an example here). In addition, we should build an AppImage or a Flatpak with full automation functionality on CI. I don't know much about the tradeoffs between the formats, so I'd love input on that front as well.
This preserves the current state of affairs (automation scripts are almost all broken on Debian) but makes clearer to the user what's going on, and makes the program easier for distros to package. This satisfies priorities 1, 3, 4, and 6. Unfortunately, it means we'd be shipping a build that is missing a large feature, even if we're clear as to why. It also more or less punts on the DepCtrl issue, but given the uncertain status of the sqlite rewrite I'm inclined to say that's okay for now and we can reassess when that becomes relevant.
I'm eager to hear other perspectives before I sit down with arch1t3cht and try to reach a decision on how to move forward here (and cut 3.4.1). I'll update this issue as relevant info about the current state comes in.