Linux Flatpak packaging help & advice

[franute]

Hi there,
As a linux user I'm trying to move all my apps to flatpak, one of those is Neovim (which I'm still in the process of learning), but I found that I need ripgrep for Telescope to work properly, so I thought I might try to package it (working branch can be found here).

I guess I should start by asking, would this be ok? I won't need to change anything in the original source code, it can be used as is.

Now, let me explain quickly the specifics of flatpak packaging:

The way flatpaks are supposed to be packaged is by using exact versions for sources and dependencies and retrieve them using flatpak's framework (which can use git or I guess wget), so dependencies can't be downloaded automatically as part of the build process. This I've found some people smarter than me have have created a utility to extract dependencies from Cargo.lock and translate it into a file flatpak can understand and pre-download all the dependencies into a specific folder.

After that, the only change that I had to make to the original source was to add an override in '.cargo/config.toml' to direct requests to crates-io to a local folder. These lines:

[source.crates-io]
replace-with = "vendored-sources"

[source.vendored-sources]
directory = "cargo/vendor"

And that's pretty much it really, after that I can just run cargo build --release and copy the resulting files to the right folders.

Now, I have a couple of questions about the build process:

• Regarding dependencies, because this is only going to build for linux, would it be ok to ignore the winapi* dependencies completely?
• I don't know about the additional features (pcre2 and simd-accel) whether I should enable them or not. Simd-accel I have the feeling after reading the main README that some of the features that might be useful for the search are already enabled automatically and I probably don't need/want to enable this. PCRE2 I'm not that sure, could somebody explain the benefits of enabling it or not?

And I guess that's pretty much it. Any comments, suggestions or proposals are welcome.
Thanks in advance!

[BurntSushi]

1. If you're only building for Linux and you have a way to ignore the Windows-only dependencies that works, then that sounds fine to me.
2. For simd-accel, I'd skip it personally. I believe the only thing it speeds up these days is UTF-16 transcoding, and that only applies when searching UTF-16. This is somewhat rare on Linux. All of the search related SIMD optimizations get enabled automatically. The only reason the UTF-16 transcoding doesn't is because the author of encoding_rs chooses not to. (And we don't need to get into the reasons there. I don't agree with the decision personally, but there are $reasons.) As for pcre2, that's really up to you as the packager. It's optional for precisely the cases where you either specifically don't want PCRE2 or building it is a pain for one reason or another. Otherwise, if it isn't an issue, then I would try to build with the pcre2 feature enabled. The purpose of PCRE2 is that it provides a regex engine with "fancy" features like look-around and backreferences. Some users find that functionality useful, and it's not available in the default engine.

And no, you don't need to ask for permission. I don't think any packager has asked if it's okay to package ripgrep. :-) That is customary and culturally appropriate in the Linux world. One nice thing though is that when you get it setup, you could submit a PR to ripgrep adding installation instructions for flatpak.

[franute]

Thanks a lot! I'll skip the simd-accel then and include pcre2 because it looks like it didn't cause any troubles (at least in with some light testing). Once it gets approved I'll for sure try and add installation instructions. The only problem is that the way to distribute it will be tied to Neovim's flatpak, but I guess as long as it's clearly explained it should be ok, should it?

[BurntSushi]

the way to distribute it will be tied to Neovim's flatpak

I don't know exactly what that means. Does it mean that you can't install ripgrep separately from neovim? If so, yes, that is quite weird. I wouldn't put that in the README because it would violate users expectations that came looking to install ripgrep (same only ripgrep).

[BurntSushi]

To clarify here, it's totally cool to make ripgrep bundled with neovim in a single flatpak. That's absolutely fine. I just mean to say that it wouldn't be something I'd promote as a standard way of installing ripgrep if it meant that you couldn't do it without also installing neovim.

[franute]

Sorry, it's been a rough week and haven't had time to reply.

Does it mean that you can't install ripgrep separately from neovim?

Correct. Flatpaks are mainly thought as a way to distribute GUI apps and even though you can distribute a command line app basically launching a terminal and running the app automatically there, it would be pointless because (afaik) you can't use an app's runtime inside another one. In those cases where a GUI app has optional dependencies on command line tools there's 2 options:

• go ahead and package it all together
• create what's called a tool (this is what I've done), but as I mentioned it is basically a plugin for a specific app. In this case the ripgrep I've packaged is just an addon for the Neovim package, it can't be used on its own or installed and shared with other apps because the namespace with these tools is quite strict.

To clarify here, it's totally cool to make ripgrep bundled with neovim in a single flatpak. That's absolutely fine. I just mean to say that it wouldn't be something I'd promote as a standard way of installing ripgrep if it meant that you couldn't do it without also installing neovim.

Agree. That's why I mentioned it in the first place. I wouldn't have it documented in the main repository because as you said this is more kind of a hack we're forced to do because of flatpak's distribution model.