Bug#812741: neovim: Please don't build-depend on luajit on unsupported architectures

[James McCoy]

On Tue, Feb 23, 2016 at 10:55:04AM +0100, John Paul Adrian Glaubitz wrote:
> On 02/23/2016 02:43 AM, James McCoy wrote:
> >> I still don't see what warrants the requirement of LuaJIT in a text
> >> editor which could not replaced by the regular Lua interpretor.
> > 
> > As I mentioned earlier, LuaC doesn't provide FFI which is something they
> > apparently want to use.  Also, one of the major purposes they're looking
> > at for using Lua(JIT) is translating VimL to Lua and then executing
> > that.  The thought is that using Lua itself instead of LuaJIT would make
> > that too slow.  Some more information on what has been under discussion
> > can be seen in <https://github.com/neovim/neovim/issues/801>.
> 
> Well, they could just always allow Lua as a fallback on architectures
> were LuaJIT is not available. Haskell's hslua does the same, why
> wouldn't NeoVIM be able to do that?

Because NeoVIM is using LuaJIT-specific functionality, as I've already
tried to explain. Haskell's hslua may just be using LuaJIT to have the
JIT when available and is able to fallback to plain Lua.  That doesn't
mean NeoVIM is.

> > Regardless, I don't see why you're having such a strong reaction to
> > this.  It's their design choice and just because it limits what
> > architectures they'll be able to run on it isn't reason enough to
> > consider this a bug.  There are plenty of applications in Debian which
> > don't run on all the supported architectures/kernels.
> 
> Yes, but that does not mean we should accept that in Debian. Debian
> specifically aims to provide a universal distribution which runs
> on a large number of different targets and everyone should therefore
> help to keep their own packages available on all targets.

So why aren't you campaigning to make LuaJIT available on all
architectures/kernels instead of rallying against a project that wants
to use some LuaJIT-specific functionality.  That would be more
beneficial for everyone.

> > Bram took extreme efforts to keep compatibility with arcane and mostly
> > unused computers/OSes and that's something the Neovim folks have decided
> > not to continue, for better or worse.
> 
> So, you would say that ARM64, PPC64EL (POWER8), S390X, MIPS64EL and
> SPARC64 [1] are all "arcane" and "mostly unused" architectures?

I was using it more as a comparison of goals rather than a reflection on
what Debian currently supports.  Up until recently, Vim was still
carrying code for Amiga, 16-bit Windows, etc.  NeoVIM dropped support
for a lot of legacy code and removed a lot of code where they could
instead leverage other libraries (like libuv).  This has meant a
reduction in supported platforms, but it has also meant less code that
has to be maintained by NeoVIM.

To answer your question, though, yes those are arcane/mostly unused for
the average desktop user.  That's part of being a Universal OS.  We
support a lot more than just what desktop users need.  That doesn't mean
everything has to work on all those architectures.

It's also not my job to make the software work on all the architectures
where it currently doesn't or to convince upstream that they need to
take on the extra burden of supporting architectures they're not
strictly interested in.

I've talked with upstream and will work on a patch to use Lua if LuaJIT
isn't available, with the caveat that not all testing will be able to
run where we have to fallback to Lua.  However, depending on the outcome
of the efforts I referenced earlier, this may not be a long term
solution.  It would be much better to get projects like LuaJIT and libuv
working on more platforms.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan at debian.org>