Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#65280 - [electron] Add API version to provides or symlink binary

Attached to Project: Community Packages
Opened by Matthias Lisin (matthias.lisin) - Sunday, 26 January 2020, 20:56 GMT
Last edited by Christian Rebischke (Shibumi) - Saturday, 22 February 2020, 20:05 GMT
Task Type Feature Request
Category Packages
Status Assigned
Assigned To Nicola Squartini (tensor5)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 2
Private No

Details

Description:
When packaging electron apps you usually need a specific version of electron for it to work because very few work with the latest (7).
But sometimes it works with the latest. This means however that once the rolling package `electron` updates to the next major version the application might break.

Therefore I'd like to propose two changes:

1. Add `electron-api=$VERSION` to provides=() array so packagers can reliably install the required version regardless of the current pkgname in the official repos (`electron` now, `electron7` later).

Applies to all current electron packages: electron{,2,4,5,6}

2. Create a symlink for the rolling package `electron` to reliably call the proper executable. (ln -sr /usr/bin/electron /usr/bin/electron7).
So packagers can reliably call the executable from a wrapper script.

Only applies to package `electron`.
This task depends upon

Comment by Nicola Squartini (tensor5) - Wednesday, 10 June 2020, 01:18 GMT
What would be the difference in a package between requiring electron-api=7 vs electron7?
Comment by Matthias Lisin (matthias.lisin) - Wednesday, 10 June 2020, 11:30 GMT
if a project depends on `electron` (now version 10) and electron is later updated to version 11, the project silently breaks unless the depends are updated to `electron10` (assuming there will be a package).
this is the same as for jre-openjdk/jdk-openjdk which not only provides java-runtime=$VERSION but also the versioned name jre1x-openjdk.
Comment by Nicola Squartini (tensor5) - Thursday, 11 June 2020, 00:21 GMT
I'd like to hear some thoughts from the other electron* maintainers.
Comment by SpacingBat3 (SpacingBat3) - Sunday, 05 September 2021, 20:50 GMT
I would personally approve some changes like that, except `electron*` (not `electron` package itself!) packages should have the `provides=('electron={full_version}')` or `provides=('electron={major_version}')` for each, so if e.g. package requires the `electron` package of manjor version 13 and that's the version present in the `electron` package, it should then automatically switch to `electron13` package when `electron` updates to the next major version and there will be `electron13` package present in the repositories.

I believe `provides=(electron={major-version})` is already in `electron*` packages in Manjaro repositories.
Comment by janek (xeruf) - Tuesday, 12 April 2022, 10:05 GMT
This is also done for the AUR packages from electron13-bin onwards: https://aur.archlinux.org/packages?O=0&SeB=n&K=electron+bin&outdated=&SB=v&SO=a&PP=100&submit=Go
This package, for example, depends on electron<18, which is not provided by the official packages: https://aur.archlinux.org/packages/stretchly-git

Loading...