Need help with the snap for Neovide

snap
1

I have been trying to get the snap for Neovide to work and mostly succeeded. The version can be found here in my branch. But there are still quite many problems. We do have one existing snap on the Snap Store, but that does not work, and is not up to date with the latest Neovide version either. Here are the problems I have found so far.

  1. The first problem is that as far as I can see, we will need classic confinement. Neovide needs to be able to both launch new instances of Neovim, including ones with custom file paths, and communicate with existing instances over various communication channels. As an application, I think we satisfy both the IDE and terminal emulator requirements, so hopefully it will be possible. If not then it’s better to stop here before solving the rest of the problems.

  2. The current snap on the store is owned by an individual in the Neovide organization, but that should not be the case. So, we need an ownership change. Furthermore, if possible, we would like to outsource most of the maintenance and testing to snapcrafters. Otherwise the testing and maintenance would be a bit too much for the small Neovide organisation. So if the ownership could be transferred there immediately, it would be ideal.

The rest of the problems have much in common with the Alacritty Snap, which in itself has many problems, and there’s a proposal to remove it completely https://forum.snapcraft.io/t/proposal-to-remove-alacritty/32574. I believe those problems are solvable, and that we can find commons solutions that works for both projects. So that’s another reason for doing this in co-operation with the snapcrafters.

  1. Most crates in the rust Linux ecosystem uses dlopen to load the dynamic libraries. This itself can be split into two problems. But here’s the first one. Two of those projects were not using sonames for loading the dynamic libraries, which causes the classically confined snap to load the libraries from the host rather than the snap. The first one for xkbcommon-dl is fixed here by my PR https://github.com/rust-windowing/xkbcommon-dl/pull/16, but the second one for wayland-rs is still open https://github.com/Smithay/wayland-rs/pull/636. But there might be more.

  2. The dlopen should not really be needed, at least not when running inside the snap, since all the required dynamic libraries should always be available. Only the wayland-rs project has the option to use pkg_conf for statically linking. Unfortunately the support is unusable for Neovide, since glutin forces dlopen https://github.com/rust-windowing/glutin/blob/fdab7ca325e681b8fe74d8b571422dfe87271189/glutin/Cargo.toml#L49. And the other crates does not support it at all. The ideal thing to do would be to get the whole echo system updated to support that. Then the core22, linter would also work as it is supposed to, and problems would be much easier to detect and fix. Currently I have to launch Neovide in both Wayland and X11 and use /proc/<pid>/maps to check that the libraries are loaded from where they are supposed to. But this is unmaintainable in the long run.

  3. The copypasta crate used by both Neovide and Alacritty indirectly uses smithay-clipboard https://github.com/Smithay/smithay-clipboard/issues/44, which does not use wayland-rs 0.30.x. So all the wayland libraries gets included twice, and even if the problem in 3. is fixed for the latest version, it still won’t work, since wayland-rs==0.29 loads unversioned .so file.

  4. The problem with not patching parts of mesa. I only leave the dri folder out in my snap as opposed to most of the Mesa in the Alacritty snap. It seems to work, but it makes me very worried, and I think we need a better global solution for this.

I believe that all these problems are solvable, but it takes a bit bigger community effort to get the whole rust ecosystem fixed. So I would be very happy to get some help with all of this.

Sorry for the links, but it only allowed me two make two real links.