[Discussion] linux build about desktop HOT 16 CLOSED

Why not just use snap or flatpak?

from desktop.

Also flatpak

from desktop.

I think linux is really sucks in binary release.

from desktop.

Appimages for example can run on more distributions and doesn't need any runtime or root

from desktop.

It'd be also really cool to have a flatpak release.

That said, I understand that for a platform that it's not officially supported yet pretending 5 different packaging formats is a bit too much 😅

I think the only package that must be available is .AppImage, since it's the one that can work for basically anyone.

from desktop.

@gengjiawen

👍 on the distro list.

👎 on docker usage, unless someone is willing to put together guidance about setup and usage on their local machines.

From that link you mentioned is this advice, which is what we're doing currently:

You can use build servers — e.g. Travis to build macOS/Linux apps and AppVeyor to build Windows app.

I'd like to know more about what "auto-update" in AppImage means, and whether it's easy to do with Electron apps. I guess there has to be some sort of infrastructure to support that.

from desktop.

I'd like to know more about what "auto-update" in Appimages means [...]

@probonopd might have the answer

from desktop.

@Huluti
Those two not so popular within my experence.

@shiftkey
For the docker part, I think it's easy and time-saving. I will give it an example when I have time.
For AppImage update, I think electron builder support this with electron-updater

from desktop.

Regarding AppImageUpdate, please check out https://github.com/AppImage/AppImageUpdate. (But be aware that electron-builder has implemented their own updater mechanism instead for reasons of consistency with Windows.)

from desktop.

@shiftkey
For docker build, I create an example, plz refer to https://github.com/gengjiawen/electron-devdocs/blob/master/build_linux.sh.
Aftter build, you can see the binary in build folder

-rw-r--r--  1 root root 36845136 Jan 23 07:57 electron-devdocs_0.9.10_amd64.deb
-rw-r--r--  1 root root 75038720 Jan 23 07:56 electron-devdocs_0.9.10_amd64.snap
-rw-r--r--  1 root root 54027440 Jan 23 07:57 electron-devdocs-0.9.10.apk
-rwxr-xr-x  1 root root 54935303 Jan 23 07:54 electron-devdocs-0.9.10-x86_64.AppImage*
-rw-r--r--  1 root root 53745964 Jan 23 07:57 electron-devdocs-0.9.10.x86_64.rpm
drwxr-xr-x  2 root root     4096 Jan 23 07:43 icons/
-rw-r--r--  1 root root      400 Jan 23 07:57 latest-linux.yml
drwxr-xr-x  4 root root     4096 Jan 23 07:54 linux-unpacked/

from desktop.

Deb, rpm, and appimage should cover all users so no need to waste time in managing more package types.

from desktop.

Most Linux distro package type are

1. Deb
2. Rpm

But I'm not sure for "Run on all Linux":

1. Snap
2. Appimage

from desktop.

I think we can give docker a try, since it can build many format linux supported, see linux part in this page https://www.electron.build/multi-platform-build. Docker, in many way, make everyone's life easier.

I did make a decent attempt at this and got close, but my hybrid "mount the repository in the Docker image" had some issues when the Docker container generated the installers - they were created by root, so the default user wasn't able to remove them without a sudo.

The branch is here, if someone would like to help figure out that headache: linux...shiftkey:docker-experiment

from desktop.

Any build log you can share ?

from desktop.

Any build log you can share ?

Not really, but you can see this recent Travis build for an example of the script doing a CI build: https://travis-ci.org/shiftkey/desktop/builds/414215247

from desktop.

I'm going to close this out because I currently have this setup, which is relatively painless:

• Travis will now test packaging on each successful build in this fork
• when pushing a tag to this fork, Travis creates a draft release in this repository
• when the build passes, I just add the release notes and then hit publish

I'm using Docker because that's the recommended setup for publishing Snap packages, but I'm still using Trusty for building native modules to avoid GLIBC issues with native modules on older distros.

from desktop.