Electron - No Stretch Repo

[PC-Admin]

• I have searched open and closed issues for duplicates

---

Bug description

There is a Xenial repository for Ubuntu 16.04 but not a Stretch repo for Debian 9.

The Xenial version does run on Debian but it would be nice if we could have a stretch repo as well.

Steps to reproduce

None.

Platform info

Operating System: Debian 9
Signal version: 1.0.23

[Dyras]

Personally I think they should use Snaps since those can be used by all distros and are super easy to install and update.

[hpaantee]

I'm not even sure there is a way to add a version to stretch, as after the release only security updates and patches get into the repo. There would be the possibility of backports maybe though. But as @Dyras already said, snaps would be way easier. And besides, new updates to Signal-Desktop can be distributed way faster.

[christianfl]

Backports would be possible. As an alternative to Snaps I recommend Flatpak. However, I really appreciate a possibilty to install the new Signal Desktop electron build on Debian 9 without using a third party repository.

[exploide]

The sole existence of the Ubuntu repository is not only a problem for Debian users, but also for users of all other distributions, like Fedora in my case. OWS always aimed for reliable update mechanisms, like the Play Store on Android or the Chrome Webstore, which is a reasonable decision for a security focused application.

Now, Signal-Desktop becomes a stand-alone application, and the update issue needs to be solved again. I'm wondering if providing Linux repositories for all distributions will scale. Maybe not. Using the distribution independent Flatpak could be a proper solution. Though, I haven't evaluated this thoroughly, yet. Alternatively, Signal could implement it's own update mechanism, but this would introduce additional complexity, and might lead to permission problems when installed system-wide but run with user privileges.

I'm curious which way Signal will take...

PS: maybe "[Electron] Distribution independent update mechanism" is a suitable, more generalized title for this issue

[sevagh]

Why not release tarballs? Is it security-related? I use Fedora.

[scottnonnenberg]

A large part of it is simple effort vs. reward. We use electron-builder, which builds .deb files for us, then paid the cost of learning how to use aptly. And that covered a lot of our users.

So the question is: what should our next step be? What will cover a lot of users for a reasonable amount of effort?

BTW, does anyone have any numbers on the usage numbers for various linux distributions?

[christianfl]

You could have a look at the chart on https://distrowatch.com/ . It is hard to find usage numbers because most of the linux distributions do not track the users.

I think releasing a snap or flatpak could be the way to go. They are independant of the distribution and not so difficult to package.

[legoktm]

A large part of it is simple effort vs. reward. We use electron-builder, which builds .deb files for us, then paid the cost of learning how to use aptly. And that covered a lot of our users.

From my quick look so far, it appears to only cover Ubuntu Xenial users? It doesn't cover users on Debian Stretch, Ubuntu Artful, Fedora, etc.

So the question is: what should our next step be? What will cover a lot of users for a reasonable amount of effort?

The ideal situation would be to work with the different Linux distribution communities and to get them to package and maintain the software. I'm not sure how reasonable that is given the dependency upon Electron.

Others have suggested flatpack/snaps which should be relatively portable across distributions. There's also OBS (https://build.opensuse.org/), Ubuntu PPAs, and Fedora's copr.

[bungabunga]

@scottnonnenberg i think to cover as many linux users as possible it's worth to check snap/flatpack packages. they also better deal with dependencies.

[exploide]

electron-builder seems to allow additional target formats, e.g. rpm. If self-hosted repositories remain an option for OWS, this would be the next reasonable format beside the existing deb repository. If we consider the first few entries of the Page Hit Ranking table from distrowatch: deb is suitable for Mint, Debian, and Ubuntu. openSuse and Fedora both use the rpm format, so such a repository would be beneficial. Third option could be something for Arch derivatives like Arch Linux itself, Manjaro and Antergos. But I'm not familiar with their package format. Usually, they seem to build their stuff in AUR. :P This would work for a lot of Linux users, but not for all. :/ The packaging ecosystem is very divers.

Packaging Signal for the official distribution's repositories would be a clean way but comes with a bunch of drawbacks. The required effort, given the number of distributions and their guidelines is huge, updates would need to be delivered quickly (something some distos won't) and having Electron as a dependency is currently a deal-breaker since several distributions have trouble packaging Electron (and Atom) and hesitate.

Mechanisms like Flatpak (and to be fair I also mention snap) are intended to solve exactly these problems of distributing hard to package software to users with various Linux distributions. This solution would probably work for all distributions supporting the respective mechanism. I think it is worth considering, but someone would need to figure out if things like npm dependencies, updates, etc. work well.

(Tarballs were also mentioned: Would be a nice addition for some really exotic systems, but are generally not nice when it comes to user-friendliness and updates. Beside this, the git repo might be sufficient for those.)

PS: I just discovered that Electron-based Signal Desktop is now publicly announced on the website including the apt repository. So extending this with an rpm repository is probably the simplest step forward. Successfully using Flatpak would rather obsolete the apt/deb repository. Maybe still a good option to think about for the future.

Other issues covering the same topics about Flatpak #1639 and rpm #1630 start to appear..

[padraic7a]

Snap or Flatpak do sound like the way to go. Bang for buck it looks like snaps have a wider reach - just based on the fact that Ubuntu has more than the lion's share of the Linux desktop 'market'.

One feature of snaps which might be useful is that they can be built from github using Travis CI. https://docs.snapcraft.io/build-snaps/ci-integration

It also seems that Ubuntu are putting a lot of effort into helping people snap their applications: https://forum.snapcraft.io/

[scottnonnenberg]

One very, very important scenario we have is around updates. apt makes that really easy. I've heard that packages like snap and flatpack don't have any tools to help with updates. Is that true?

[aruhier]

I did not test it, but gnome-software and kde appstore both support flatpak: flatpak/flatpak#859

[padraic7a]

As far as I understand snap allows you to push updates. I think that's the default behavior in fact.

I'm basing this on a forum post where someone is trying to disable that behaviour https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707/4

That said I'm not very knowledgeable about this - snapcraft.io might be the place to go.

[exploide]

Flatpak has a flatpak update command. Would be comparable to apt update I think. Probably the GUI integration mentioned by @Anthony25 use this under the hood (haven't looked at it).

Do not want to trigger a Flatpak vs Snap fight here, but I noticed in other projects that people polarize around this decision. There are several articles on the Internet, explaining differences, trying to compare. My impression is that Flatpak is leading, but others like @padraic7a probably disagree :D In the end, it is up to OWS devs to decide which way to go.

[FeuRenard]

I am on Fedora and use Spotify as a Flatpak. It gets updates via GNOME Software.
Here is a high-level blog post on GNOME Software's flatpak capabilities:
https://blogs.gnome.org/hughsie/2016/07/05/flatpak-and-gnome-software/
It seems like you could create and maintain a flatpak repository just like you do for apt now.

[charlesjt]

Snap or Flatpak do sound like the way to go. Bang for buck it looks like snaps have a wider reach - just based on the fact that Ubuntu has more than the lion's share of the Linux desktop 'market'.

@padraic7a That sounds logical, but in practice the scenario is something different. There are several distributions derived from Ubuntu that will support both future distribution systems officially and others such as Linux Mint that opted only for Flatpak.

Also in practice the universality of Snap is always in doubt, since it has problems in distributions that dont use AppArmor, you still have to have an Ubuntu account to use your software store (centralized distribution system), there are only runtimes for the Gnome desktop environment and snapd maintenance is outdated or without full support in many distributions.

[harmancode]

I used to use Chrome app on my debian 9 system. Now it is gone and I see a snap file installed, waiting for me to reconfigure/resync it but it shows no information regarding its source, so I cannot trust it.

By the way, could you please consider adding information on Signal's download page for linux that only Ubuntu Xenial is currently supported, if this is the case?

[scottnonnenberg]

@DX486 artful is supported now - we'll get those install instructions updated.