FS#75513 - [electron] Package breakage on every major new electron version
Attached to Project:
Community Packages
Opened by Arvid Norlander (VorpalGun) - Thursday, 04 August 2022, 15:58 GMT
Last edited by Bruno Pagani (ArchangeGabriel) - Saturday, 06 August 2022, 11:34 GMT
Opened by Arvid Norlander (VorpalGun) - Thursday, 04 August 2022, 15:58 GMT
Last edited by Bruno Pagani (ArchangeGabriel) - Saturday, 06 August 2022, 11:34 GMT
|
Details
Description:
When running pacman -Syu today I got the following output: looking for conflicting packages... error: failed to prepare transaction (could not satisfy dependencies) :: installing electron (20.0.0-1) breaks dependency 'electron19' required by element-desktop After some digging this was easy enough to fix (pacman -S --asdeps electron19, letting it replace the electron package). However as far as I can tell this same issue will be repeated on every new electron version (21 next time) if you continue using "electron" as the name for the most recent version. Would it not make more sense to package each electron version as electronNN (electron20, electron21) and have an empty meta package "electron" that depends on the latest one. That way: * Users who only care about electron as a dependency of something they use will have everything just work. * Users who want the latest electron (presumably for development?) will get their version easily too. Someone on #archlinux mentioned that this would lead to versions accumulating over time. I disagree: this is happening already for users of the first category as those pieces of software upgrade to newer versions. As long as electronNN is installed as a dependency pacman -Qtd will show the old versions and allow easy cleaning. This is no different than any other library or runtime that has multiple major versions packaged side by side (gtk3, gtk4, qt5, qt6 etc) At no point is the latest version of those packaged as just "gtk" or "qt". As an alternative, every time a new major electron version is packaged, a news item about needing manual upgrade could be posted on archlinux.org. However I think changing the packaging would be a cleaner solution. Additional info: * package version(s): electron 20.0.0-1, electron19 19.0.10-1 * config and/or log files etc: Not applicable * link to upstream bug report, if any: Downstream packaging issue, so not applicable Steps to reproduce: 1. Ensure a sync database and system state from before 2022-08-04 (Y-M-D). 2. Install element-desktop (or something else depending on the latest electron package without a version suffix). 2. Update to a sync database state after 2022-08-04 (Y-M-D). 2. Upgrade to the new major release of electron where the old version of electron is moved to electron19 3. Observe pacman failing to resolve dependencies. |
This task depends upon
Closed by Bruno Pagani (ArchangeGabriel)
Saturday, 06 August 2022, 11:34 GMT
Reason for closing: Duplicate
Additional comments about closing: FS#74324 .
Saturday, 06 August 2022, 11:34 GMT
Reason for closing: Duplicate
Additional comments about closing:
You don't have a new Qt or Gtk major version every 2 months. And it is not possible for a package to work with a new Qt/Gtk version without rebuilding it (actually, without porting the code). So yes, it is quite different.
Sure, it changes more often. And based on there being electron versions going back to 12 in the arch linux repos and packages still depending on those, I assume there is porting involved (at least sometimes) for electron too. (I'm not a a js developer so I'm not speaking with any authority here, I prefer C, C++, python, erlang and haskell (with plans to get into rust too).)
It may not be the same thing, but it is very similar. And for the sake of the argument in the bug report of a better way to handle it, it doesn't matter how often it changes like this. The argument as a whole still stands. The current state of affair is a sub-optimal experience, and a relatively small tweak would result in a better user experience for the common use case of a user who installed something with electron as a dependency.
FS#75484FS#74324FS#74324. I had forgotten about it (short memory…). This should still be fixed in pacman eventually, but in the mean time I’ll add a note in the electron PKGBUILD.