FS#73382 - [signal-desktop] use system electron instead of bundling it yourself
Attached to Project:
Community Packages
Opened by Mynacol (mynacol) - Monday, 17 January 2022, 00:29 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:08 GMT
Opened by Mynacol (mynacol) - Monday, 17 January 2022, 00:29 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:08 GMT
|
Details
Description:
Although signal-desktop is an electron application, it does not depend on electron. Instead, it bundles its own version. To improve reusage of programs and libraries, signal-desktop should depend on the fitting system electron version, currently 16, therefore `electron16`. As a side note, I noticed that the file tree of this package contains `app.asar` and `app.asar.unpacked/` (under `/usr/lib/signal-desktop/resources/`), hinting at duplicate data. And I believe `resources.pak` is not needed either. After a short visit, I would kindly ask the maintainer of this package to review the package guidelines for electron applications again, https://wiki.archlinux.org/title/Electron_package_guidelines With these changes I believe we can easily reduce the package size from ~320MB to ~120MB. Additional info: * package version: signal-desktop 5-28.0-1 Maybe see the `Required-By` tag on the arch package website for electron to get some ideas how other maintainers package their electron applications. |
This task depends upon
Closed by Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:08 GMT
Reason for closing: Moved
Additional comments about closing: https://gitlab.archlinux.org/archlinux/p ackaging/packages/signal-desktop/issues/ 3
Saturday, 25 November 2023, 20:08 GMT
Reason for closing: Moved
Additional comments about closing: https://gitlab.archlinux.org/archlinux/p ackaging/packages/signal-desktop/issues/ 3
I am not quite happy with the result, maybe you can improve upon it.
The main idea is that we only package the `app.asar`, but then `preload.js` is missing. That file has to be essentially `preload.bundle.js`, else other JS dependencies are missing. So I just symlinked that file after extraction of the asar (after electron-builder just packaged it...).
The next problem is the configuration. The default build process seems to include the development config which connects to the staging servers. So I include the production config in the "default" one (just using `production.json` is missing some parameters, namely `enableCI`). Then I disable automatic updates.
The build is running since some days on my computer. The client unfortunately has some other issues, which were partly fixed with version 5.29.1.
There was also a very obscure bug reported upstream that turned out to be Arch Linux specific, caused by me changing the electron version used: https://github.com/signalapp/Signal-Desktop/issues/2117
https://bugs.archlinux.org/task/65973
https://bugs.archlinux.org/task/65972
https://github.com/signalapp/Signal-Desktop/issues/4021
https://bbs.archlinux.org/viewtopic.php?id=253388
https://bugs.archlinux.org/task/65723
https://bugs.archlinux.org/task/65975
https://bugs.archlinux.org/task/67214
https://github.com/signalapp/Signal-Desktop/issues/4394
https://bugs.archlinux.org/task/65722
https://bugs.archlinux.org/task/67222
https://bugs.archlinux.org/task/67217
https://bugs.archlinux.org/task/67218
These stopped since we started using bundled electron.
The experience for me was a bit the contrary. If I don't use the system electron, signal won't use native wayland (through the `.config/electron-flags.conf` mechanism) and would fail to open firefox if I click on a link in a message.
I can't remember any major issue with my patches, especially in connection with electron version updates, and especially in the last months. So if you are willing to test this once more, I attached the current patch (avoiding the config patching by setting `NODE_ENV=production`, I wish I would've found that earlier).
I assume electron applications are running with XWayland by default for now, until Chromium enables it by default.
The case for electron cmdline flags in a standard configuration file remains, making it easy for me to e.g. enforce wayland usage or disable GPU acceleration. And it saves storage space, as outlined above.
```
$ electron --resources-path=/usr/lib/signal-desktop/resources /usr/lib/signal-desktop/resources/app.asar
```