Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

search: Don't strip .desktop suffix overzealously #4536

Merged
merged 2 commits into from
Nov 15, 2021

Conversation

mwleeds
Copy link
Collaborator

@mwleeds mwleeds commented Nov 2, 2021

This commit changes the search command to properly output the app ID for
IDs that end in .desktop, e.g. to print org.telegram.desktop rather than
org.telegram.

Fixes #4535

This commit changes the search command to properly output the app ID for
IDs that end in .desktop, e.g. to print org.telegram.desktop rather than
org.telegram.

Fixes #4535
@smcv
Copy link
Collaborator

smcv commented Nov 2, 2021

I wonder whether repositories like Flathub should be automatically injecting

<bundle type="flatpak">org.telegram.desktop</bundle>

or

<bundle type="flatpak">app/org.telegram.desktop//stable</bundle>

into the collection metadata, so that we have an unambiguous way to map from entries in the collection metadata to Flatpak refs?

@smcv
Copy link
Collaborator

smcv commented Nov 2, 2021

Huh, looks like they already do. Perhaps Flatpak should be reading those, instead of the <id>, since they're a lot less ambiguous?

@mwleeds
Copy link
Collaborator Author

mwleeds commented Nov 2, 2021

Huh, looks like they already do. Perhaps Flatpak should be reading those, instead of the <id>, since they're a lot less ambiguous?

Yeah that would be more robust, and it looks we already use it elsewhere. But I guess we'd still have to check the <id> as a fallback, since that is required by the appstream spec and <bundle> is not.

@mwleeds
Copy link
Collaborator Author

mwleeds commented Nov 5, 2021

I'll change this to use <bundle>. I also notice that #4426 will probably make this obsolete but still worth getting this in since there's no guarantee the libappstream port will be in before the next release.

The <bundle> element in the appstream data unambiguously provides the
full four-part flatpak ref, so use it to determine the app ID. But fall
back to using the <id> element, since that is required to be present.
@mwleeds
Copy link
Collaborator Author

mwleeds commented Nov 5, 2021

Still seems to work as expected with the <bundle> changes

@mwleeds
Copy link
Collaborator Author

mwleeds commented Nov 10, 2021

I added a patch to the #4426 branch which ensures we don't run into this issue there. Since the code here is only relevant for appstream-glib we can close this PR if #4426 is merged.

@alexlarsson alexlarsson merged commit 39de0ef into master Nov 15, 2021
@mwleeds mwleeds deleted the search-show-full-app-id branch February 27, 2022 21:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug]: flatpak search lists results with some invalid app ids ("Names must contain at least 2 periods")
3 participants