shiftkey / desktop

Fork of GitHub Desktop to support various Linux distributions

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Discussion] linux build

gengjiawen opened this issue ยท comments

How many official distro should we support ?

I think it should be AppImage, deb and rpm. Keep too many maybe a tedious job.

Easy way to build linux distro

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.

Auto update

Turn on auto-update for AppImage, this will be much convenient.

Why not just use snap or flatpak?

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

@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.

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

@probonopd might have the answer

@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

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.)

@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/

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.

I think linux is really sucks in binary release.

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

Most Linux distro package type are

  1. Deb
  2. Rpm

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

  1. Snap
  2. Appimage

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

Any build log you can share ?

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

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.