appcenter
appcenter copied to clipboard
elementary
Difficult to differentiate packages from different Backends
@mmstick mentioned this issue in #992
Below is an example of the results you get searching for Wireshark with the flathub remote enabled. In this case, the results are duplicated because the application ID was changed by the flathub packaging process and AppCenter can't match them. Currently we only show a dropdown on the application page if AppCenter can find multiple sources for a given app ID.
However, in cases where an ID doesn't match or there's an application that's solely from one source, there's no way of identifying whether a package is a deb or a flatpak.
Raising this issue to prompt some discussion to see if we can or want to improve this.
The application ID is meant to be unique, if one source change it, it is really wrong
Application IDs are allowed to change, however. Some sources may be shipping older versions of the metadata. The debian packages are inevitably doing so.
I have to disagree, the documentation is clear:
Note that the value of this tag must be unique across all distributions and software deployment platforms. In case it is not unique, distributors are expected to reject the conflicting components from inclusion into their metadata and notify the upstream projects about this issue.
Debian's not going to "reject" a package that they've already published. I doubt they will update all of their packages with old metadata at this point, either. I'm not sure how the appcenter could reject packages, or that it even should, either. So the question is how you handle those changes, or if there even is a way to handle it at all.
Many projects have changed their application IDs before, as seen in this example. In the beginning, many of them started out with app IDs that referred to the name of the desktop file that it's based on, and have since switch to using a RDNN-based application ID.
However, even RDNN IDs are bound to change over time. Domain names change, projects move, companies merge, and projects change their names. If we were basing application IDs on UUIDs, then you could say that they are unique and unchanging, but that's not what was standardized on.
With flatpak repositories, it is easier to ensure that everyone has the latest version of metadata. But if you rely on debian repositories it gets a bit trickier if you aren't willing to repackage all the debian packages with updated appstream data.
Isn't this also what the "provides" tag is supposed to help deduplicate? But I agree with @tintou here, there is a spec and we aren't really responsible for apps changing their IDs or otherwise shipping garbage metadata.
A large reason behind using RDNN in the first place is that they should not change in the metadata. This is exactly how other app stores like Google Play handle it as well; they're immutable.
Google has control over the Google Play store, however. They can impose rules on their repositories that we can't. There's inevitably going to be more than one repository source for packages. You can only control the repositories you maintain.
Application developers will, and have, changed their application IDs. Even changes to RDNNs have occured when project development shifts from one domain to another (ie: from com.github.Application to com.gitlab.Application, or from com.gitlab.Application to org.Organization.Application.
It would be reasonable for an application to change its ID as long as the version with the new ID has a <provides> tag in the metadata that indicates it's the same application as the old ID. I haven't written the code in AppCenter to handle this yet. But, it wouldn't help in this Wireshark case as neither version has this tag.
However, I worry that this discussion has gotten away from the point of the issue. It may have been my fault for including an example of an application where the ID can't be matched.
The point I was raising with the issue was:
Can we or do we want to show the origin of a package (flatpak/deb) in the list view or anywhere if there is only one source for it?
Forgetting the ID matching issue, it's possible that we have an application that's only provided as a Flatpak and not a deb or vice versa. In this case, there is absolutely no indication in the list view or the app info page of where this package is coming from.
I don't think that we want to tell the user about technical things but we might have a banner in the application view telling that the application isn't safe as it's not in a container (which might also be linked to #1012)
However, there's no guarantee that a flatpak is actually contained. Many of them are not confined (and have actually been used to distribute malware :grimacing:)
I dunno, it kind of seems like this is the risk users take when they mess with software sources. We can't really be responsible for developer mistakes in repos we don't curate.
@Oymate we enforce that curated apps have proper RDNN IDs. All instances of duplicated apps here are for non-curated apps.
I am also struggling with this issue. When there is more than one (or more) sources available there is zero labelling about where the source is from, either in the list (search results) on the detail view.
The source information is effectively nowhere, which makes it difficult to understand what I'm getting,
Two suggestions:
- When searching / or browsing for an app in list view, show the source of the app next to each entry
- When viewing details, show source next to version.
@cassidyjames Maybe also compare app name?
That's extremely unreliable because so many apps have generic names. The standardized FreeDesktop solution to this exact problem is application IDs.
Would also be helpful to see the application version number and backend source (flatpak/ubuntu repos) displayed in the search results. Currently I have to click each app and scroll down to the bottom to find the version, and it's not obvious to less technical users what the software source is, however maybe this should remain abstracted from non-power users.
I am also struggling with this issue. When there is more than one (or more) sources available there is zero labelling about where the source is from, either in the list (search results) on the detail view.
This! It's not very user friendly when you can't tell which source is the app installed from. Every time I have to go to terminal and try apt list | grep .. and flatpak list | grep ... Also, when I want to install new app I want to know if its flatpak or not, because in most cases (there are exceptions) I want flatpak or I don't install it...
