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 Toolybird (Toolybird) - Sunday, 21 August 2022, 22:00 GMT
Task Type Feature Request
Category Packages
Status Closed
Assigned To Bruno Pagani (ArchangeGabriel)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
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

Closed by  Toolybird (Toolybird)
Sunday, 21 August 2022, 22:00 GMT
Reason for closing:  Fixed
Additional comments about closing:  Reporter says "Both cases are resolved, therefore requesting closure. Thank you."
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
Comment by Bruno Pagani (ArchangeGabriel) - Saturday, 20 August 2022, 21:06 GMT
So the electron package does provides the electronXX package matching its version currently. Unless I missed something this solves the case for the initial request, although it hits https://bugs.archlinux.org/task/74324.

Now regarding the last point (providing electron==XX), it might actually be a good idea and solve the aforementioned bug, but as stated in this one I don’t actually know about this.

Loading...