Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
mattnibs opened this issue Apr 25, 2020 · 4 comments
Open

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

mattnibs opened this issue Apr 25, 2020 · 4 comments

Comments

@mattnibs
Copy link
Contributor

mattnibs commented Apr 25, 2020

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. zeek/zeek#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
Copy link
Contributor

philrz commented Jul 8, 2020

FYI, a fix has been merged for the Zeek issue zeek/zeek#928 that was blocking progress on this one.

@philrz
Copy link
Contributor

philrz commented Jan 18, 2021

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 philrz changed the title Flatpak release Distribution-agnostic packaging (Flatpak, AppImage, Snap) Jan 18, 2021
@philrz
Copy link
Contributor

philrz commented Jun 22, 2021

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
Copy link
Contributor

philrz commented Jul 19, 2021

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.

@philrz philrz added this to the Data MVP1 milestone Jul 19, 2021
@philrz philrz removed this from the ETL Lake milestone Oct 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants