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

build-finish: Export appstream metainfo into a single directory #4350

Merged
merged 2 commits into from Nov 15, 2021

Conversation

agx
Copy link
Contributor

@agx agx commented Jul 26, 2021

build-finish: Export appstream metainfo into a single directory

This is similar to what is done for desktop files and allows
applications like desktop or mobile shell to use a flatpak's metainfo to retrieve e.g. required
input controllers or the supported screen sizes. Similar to what can be
done for non-flatpak'ed apps by looking at /usr/share/{metainfo,appdata}.

This information is e.g. useful for desktop and mobile shells to figure out if an
application is currently usable (does meed the current input and screen
requirements) and hence where it should be placed in a menu.

Since flatpak moves the metadata from metainfo/ to appdata/ during build
we only need to export files from that single directory.

agx added 2 commits August 3, 2021 15:02
This is similar to what is done for desktop files and allows
applications to use a flatpak's metainfo to retrieve e.g.  required
input controllers or the supported screen sizes. Similar to what can be
done for non-flatpak'ed apps by looking at
/usr/share/{metainfo,appdata}.

Since flatpak moves the metadata from metainfo/ to appdata/ during build
we only need to export files from that single directory.

Signed-off-by: Guido Günther <agx@sigxcpu.org>
Signed-off-by: Guido Günther <agx@sigxcpu.org>
@mwleeds
Copy link
Collaborator

mwleeds commented Nov 9, 2021

I think this makes sense. I guess it's mostly fine for app centers to fetch AppStream data from the Flatpak remotes, but system components may want appdata that definitely correspends to the installed version of an app, and is more reliably available, which is accomplished via exports that happen at app install time.

We put the /var/lib/flatpak/exports/share directory, and corresponding ones for other installations, in the XDG_DATA_DIRS environment variable. So is it correct to add this appdata subdirectory? Will all the consumers of $XDG_DATA_DIRS handle it properly?

@agx
Copy link
Contributor Author

agx commented Nov 9, 2021

We put the /var/lib/flatpak/exports/share directory, and corresponding ones for other installations, in the XDG_DATA_DIRS environment variable. So is it correct to add this appdata subdirectory? Will all the consumers of $XDG_DATA_DIRS handle it properly?

@mwleeds I haven't seen anything bad happen yet and not putting it there is likely not much of an option since we want things like e.g. appstream to find it (and also the $HOME/.lcoal/share/flatpak/exports/share one)

@alexlarsson
Copy link
Member

This makes sense to me too.

@ximion
Copy link
Contributor

ximion commented Nov 21, 2021

@alexlarsson Is it possible to change the directory default to share/metainfo? The share/appdata directory is deprecated for ages, and AppStream will completely remove support for it with the 1.0 release (and some newer code doesn't even read it anymore today already).

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.

None yet

5 participants