search

brimdata / zui

Zui is a powerful desktop application for exploring and working with data. The official front-end to the Zed lake.
https://www.brimdata.io/download/
Other
1.8k stars 132 forks source link

Distribution-agnostic packaging (Flatpak, AppImage, Snap) #685

Open mattnibs opened 4 years ago

mattnibs commented 4 years ago

A couple of users have expressed interest in a flatpak release of brim (see https://flatpak.org/). I had made some progress on this but ran into an issue with getting zeek to run. Flatpak uses OSTree which deduplicates redundant files by hard linking them from a single source. This caused an issue with zeek, which crashed while loading the baseline zeek scripts. https://github.com/zeek/zeek/issues/928 has been filed to fix this.

We've discussed internally some ways we could hack around this. The plan right is to wait for the fix to land in zeek before moving forward on this.

philrz commented 4 years ago

FYI, a fix has been merged for the Zeek issue https://github.com/zeek/zeek/issues/928 that was blocking progress on this one.

philrz commented 3 years ago

A community user also pointed out:

Another distro agnostic approach you might take is packing Brim in AppImage (https://appimage.org) or a snap (https://snapcraft.io/about).

Indeed, it seems appropriate for us to widen the scope of this issue to be about any/all of these approaches rather than specifically just Flatpak.

philrz commented 3 years ago

On the AppImage front, @mason-fish recently pointed out:

Here are some fast pointers for building an AppImage: https://www.electron.build/auto-update indicates how using appImage will allow us to get autoUpdates into our linux distros. Details on configuring it are here, https://www.electron.build/configuration/appimage and the config file to set this up in Brim is here, https://github.com/brimdata/brim/blob/d72086dcc9d473d50fa18ece7f32f3d818b43ea7/electron-builder.json#L41-L49

philrz commented 3 years ago

A community user on Slack recently voiced a recommendation for the AppImage approach. An excerpt:

I think an AppImage under "releases" should be suffice. Users can take that and derive flat/snap much easier then say a rpm/deb. So, yes, I do agree with just providing an AppImage as a download option under releases and you're done. Providing .deb / .rpm / AppImages will satisfy 90% of most linux users, and lets be honest, if you're doing packet analysis, you should be comfortable in linux enough to figure out how to get it the way you want it.

I'll mark this issue as an MVP1 target and perhaps try to take it up myself in that timeframe. Of course, if anyone from the community is watching this issue and manages to get it working before then, feel free to chime in with what you've got and I can work to incorporate it into our release process.