Arch Linux User Repository

We’ll be using a new code signing key starting with release 4.41 to verify Slack for Linux package signatures. Please see https://slack.com/help/articles/115004809166-Verify-Slack-for-Linux--beta--package-signatures for more details.

I guess next update will need some changes.

@peter.lyonskehl

I think @carsme, the package's author, uses a conservative and controlled approach by bumping electronNN dependency only after verifying this package works against it.

In your scenario, if a new version of the electron is being rolled out in the Arch Linux repo, and it breaks this package, he needs to retroactively downgrade the electron dependency to the previous working version and issue a new update with pkgrel bump. So there will be a time window, in which hundreds of his users have the broken app, which they intend to use day-to-day for real-life work.

Sorry if this question is Manjaro-specific. (On Manjaro) "extra" repository has "electron" 1:32-1 "meta package", which currently installs "electron32" 32.1.0-1 (again, from "extra" repository).

Could this "slack-electron" use "electron", instead of hard-coding the version (until there are any incompatibilities)?

Seems that download URL changed? I've just bumped the version on my end and I had to also change the download URL to different format. I guess since it's considered stable version and not beta?

I see your point @alerque, but I believe most of the time plain latest "electron" is just fine. The app will run with no issues. And pinning the electron version brings other problems, like when the app still uses a pretty old version of electron which has been already dropped from the Arch repos. And if you want it, you'll have to grab it from AUR, sometime by building it. So if latest "electron" works flawlessly, why not using it, rather than waiting for the dependency to get too old.

Now if latest "electron" doesn't work anymore, then yes, there's no option but pinning to the latest one that works fine, or if possible the one the app was built against.

That's just my $0.02... But there's the option to attempt to always match the electron version used to build the app, but this in my mind is not needed, not always at least...

@je-vv I think you miss-understood me. I didn't say that it bundled electron, I sadi that it was compiled against a specific version of electron. The dependency on this package was electron which was bogus because the ASAR file installed here will not run under just any-old version of Electron. Some versions may work, others will not, and pinning it to the one it was built against is best. Hence the dependency here got update to electron29. I understand how the system Electron stuff works just a bit: I'm the Arch maintainer for all Electron versions. I reported the electron as bogus because I started getting bug reports on that package that it was breaking this one, when in fact it was this package that had an incorrect dependency.

@alerque, not true, first the app.asar from slack is bein executed with the system electron (provided by Arch, or derivative distro), you can take a look at slack.sh. Moreover, if you take a look at the PKGBUILD (or you do pacman -Ql slack-electron) you'll notice the electron that comes from the deb slack package is not copied over.

slack-electron is different than slack-desktop in the sense that it uses the system electron provided by the distro, and not the inner electron coming with the original deb package.

The electron dependency in this package is bogus. Its a binary app compiled by upstream against a specific version of Electron, it is not expected to run using any/current version of Electron only the one is was built for.

The only thing is that we need to keep an eye on each following slack release, to see when slack stops disabling sreen sharing. To avoid doing the substitution from the entire app.asr. Greetings !