Bug 2181367 - Incorrect priority order of app sources
Summary: Incorrect priority order of app sources
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-software
Version: 38
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Milan Crha
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F38FinalBlocker F38FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2023-03-23 21:22 UTC by Daniel Rusek
Modified: 2023-03-27 13:49 UTC (History)
7 users (show)

Fixed In Version: gnome-software-44.0-2.fc38
Clone Of:
Environment:
Last Closed: 2023-03-26 00:20:30 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
screenshot from gnome software showing scribus (65.16 KB, image/jpeg)
2023-03-24 00:38 UTC, Geraldo Simião
no flags Details
screenshot from gnome software showing scrummVM (78.15 KB, image/jpeg)
2023-03-24 00:44 UTC, Geraldo Simião
no flags Details
screenshot from gnome software showing gimp (118.11 KB, image/jpeg)
2023-03-24 00:48 UTC, Geraldo Simião
no flags Details
screenshot from gnome software showing inkscape (89.15 KB, image/jpeg)
2023-03-24 01:09 UTC, Geraldo Simião
no flags Details
screenshot from gnome software showing gedit (51.65 KB, image/jpeg)
2023-03-24 01:10 UTC, Geraldo Simião
no flags Details
screenshot from gnome software showing gitg (63.73 KB, image/jpeg)
2023-03-24 01:13 UTC, Geraldo Simião
no flags Details

Description Daniel Rusek 2023-03-23 21:22:06 UTC
Description of problem:
Since Fedora 38, there is an unfiltered Flathub repo added as a part of the Third-Party Repositories. As a requirement for this change to be accepted by FESCo, it was decided that Fedora RPMs will have priority over Flathub Flatpaks (and Fedora Flatpaks will have priority over both Flathub Flatpaks and Fedora RPMs). However, this does not seem to be the case with Fedora 38 Beta - Flathub Flatpaks still seem to have priority over Fedora RPMs (only Fedora Flatpaks seem to have the correct priority). I have tried two different clean F38 Beta installations and it behaves the same on both of them. This should ideally be fixed before F38 Final.

Version-Release number of selected component (if applicable):
gnome-software-44.0-1.fc38.x86_64

How reproducible:
Every time.

Steps to Reproduce:
1. Install Fedora 38 Beta.
2. Enable Third-Party Repositories in GNOME Initial Setup.
3. Fully update the Fedora 38 system.
4. Open GNOME Software, search for example for "Xonotic" or "ScummVM" (or any other app that has both RPM and Flathub sources) and click the result.
5. See what source is selected by default on the app details page.

Actual results:
"Flathub" (dl.flathub.org) is selected by default.

Expected results:
"Fedora Linux" (fedoraproject.org) is selected by default.

Additional info:
https://fedoraproject.org/wiki/Changes/UnfilteredFlathub#Detailed_Description

"The unfiltered Flathub change has two parts:

1. Remove the allowlist from the Flatpak remote, so that when a user opts in, they gain access to all Flathub content and not just a small selection.
2. Adjust GNOME Software so that it uses the following priority order when deciding which package to offer by default:
- Fedora Flatpaks
- RPMs
- Flathub Flatpaks

This will mean that, when using the graphical software manager, Flathub Flatpaks will only be selected by default when there is no Fedora Flatpak or RPM."

Comment 1 Fedora Blocker Bugs Application 2023-03-23 21:30:27 UTC
Proposed as a Blocker and Freeze Exception for 38-final by Fedora user asciiwolf using the blocker tracking app because:

 Since Fedora 38, there is an unfiltered Flathub repo added as a part of the Third-Party Repositories. As a requirement for this change to be accepted by FESCo, it was decided that Fedora RPMs will have priority over Flathub Flatpaks (and Fedora Flatpaks will have priority over both Flathub Flatpaks and Fedora RPMs). However, this does not seem to be the case with Fedora 38 Beta - Flathub Flatpaks still seem to have priority over Fedora RPMs (only Fedora Flatpaks seem to have the correct priority).

Comment 2 Geraldo Simião 2023-03-24 00:38:28 UTC
Created attachment 1953286 [details]
screenshot from gnome software showing scribus

It seems this bug affects randomly because with scribus, rpm shows first, but with other softwares no.

Comment 3 Geraldo Simião 2023-03-24 00:44:49 UTC
Created attachment 1953288 [details]
screenshot from gnome software showing scrummVM

As said by the reporter, in this case flathub comes first.

Comment 4 Geraldo Simião 2023-03-24 00:48:32 UTC
Created attachment 1953289 [details]
screenshot from gnome software showing gimp

Here at gimp it shows
Fedora flatpaks first
RPM second
Flathub thrid

Comment 5 Geraldo Simião 2023-03-24 00:51:21 UTC
Either way, it seems the priority aproved by fesco is not being respected by gnome software everytime, only sometimes.

Comment 6 Geraldo Simião 2023-03-24 01:09:05 UTC
Created attachment 1953291 [details]
screenshot from gnome software showing inkscape

Here the preference is Fedora flatpak => RPM =>flathub

BTW this is the version of gnome-software
gnome-software-44.0-1.fc38.x86_64

Comment 7 Geraldo Simião 2023-03-24 01:10:45 UTC
Created attachment 1953292 [details]
screenshot from gnome software showing gedit

With gedit the RPM is marked as default, fedora flatpak and flathub cames second and third.

Comment 8 Geraldo Simião 2023-03-24 01:13:08 UTC
Created attachment 1953293 [details]
screenshot from gnome software showing gitg

With gitg fedora flatpak is default, RPM and flathub came after.

Comment 9 Geraldo Simião 2023-03-24 01:29:23 UTC
Obs: I didn't check all the versions of the programs searched to see if it was selected using version number as a guide or not.

Comment 10 Milan Crha 2023-03-24 05:43:43 UTC
Thanks for a bug report. I'm not sure the screenshots were necessary, the problem is understandable even without them.

This needs a change on the packaging side, I'm on it.

As a proof of concept, you can run from a terminal:

   $ gsettings set org.gnome.software packaging-format-preference "['flatpak:fedora', 'rpm']"

This expects that the Fedora's flatpaks are provided from a `fedora` remote, which seems to be true for newly installed Fedora 38.

By the way, the order in the source selector popup does not matter, the idea is to preselect the proper source when an uninstalled app's details are viewed.

Comment 11 Fedora Update System 2023-03-24 07:09:37 UTC
FEDORA-2023-49b5dec107 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-49b5dec107

Comment 12 Kalev Lember 2023-03-24 07:20:22 UTC
> This expects that the Fedora's flatpaks are provided from a `fedora` remote, which seems to be true for newly installed Fedora 38.

They can also be from "fedora-testing" remote - that remote is pre-installed, but disabled by default.

Comment 13 Milan Crha 2023-03-24 11:16:10 UTC
(In reply to Kalev Lember from comment #12)
> They can also be from "fedora-testing" remote - that remote is
> pre-installed, but disabled by default.

Aha, hmm, do you want to promote those apps? I think it's like Updates Testing, right? Those might not be preferred over stable updates, no? I've no problem to add it, I only want to be sure it's desired.

Comment 14 Kalev Lember 2023-03-24 12:44:48 UTC
Yep, it's similar to rpm updates-testing, which is already included in the priority order here ('rpm'). I think packages from updates-testing are actually even preferred over packages from regular updates because they usually have higher version numbers (but the user needs to enable updates-testing first for this to happen).

As for the fedora-testing flatpak remote, similarly, I think it makes sense to promote it if the user has opted in for them (which they do by enabling fedora-testing, similar to how they have to enable updates-testing). It doesn't really matter for most users because fedora-testing is disabled by default, but if someone enables it manually I think it just makes for a slightly nicer experience.

I have no idea which one should come first though - fedora or fedora-flatpak :)

Comment 15 Daniel Rusek 2023-03-24 17:46:33 UTC
(In reply to Kalev Lember from comment #14)
> I have no idea which one should come first though - fedora or fedora-flatpak
> :)

Fedora Flatpaks should be first, see: https://fedoraproject.org/wiki/Changes/UnfilteredFlathub#Detailed_Description

Comment 16 Kalev Lember 2023-03-24 17:49:35 UTC
Yes, sorry, I typoed there. I wanted to say "I have no idea which one should come first though - fedora or fedora-testing". Both of these are Fedora Flatpaks remotes.

Comment 17 Geraldo Simião 2023-03-24 19:17:47 UTC
(In reply to Fedora Update System from comment #11)
> FEDORA-2023-49b5dec107 has been submitted as an update to Fedora 38.
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-49b5dec107

Fix confirmed at my VM

Comment 18 Fedora Update System 2023-03-25 02:44:28 UTC
FEDORA-2023-49b5dec107 has been pushed to the Fedora 38 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-49b5dec107

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 19 Fedora Update System 2023-03-26 00:20:30 UTC
FEDORA-2023-49b5dec107 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 20 Milan Crha 2023-03-27 06:49:16 UTC
Okay, I added 'flatpak:fedora-testing' into the packaging-format-preference, before the 'flatpak:fedora'. I'm not going to create an update with it, it can wait for the 44.1 from my point of view.

Comment 21 Kalev Lember 2023-03-27 07:00:20 UTC
Excellent, thanks!

Comment 22 Milan Crha 2023-03-27 13:49:32 UTC
(In reply to Milan Crha from comment #10)
> By the way, the order in the source selector popup does not matter, the idea
> is to preselect the proper source when an uninstalled app's details are
> viewed.

I opened [1] to make the order respect the packaging format preference. The code was there, the alternative apps were sorted by it, but then the list box re-sorted them by name.

[1] https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/1666


Note You need to log in before you can comment on or make changes to this bug.