Use new metainfo path #441
Conversation
The old path will not be supported by the upcoming AppStream 1.0 release, and the new path is well supported. Fixes #252
mwleeds
force-pushed
the
use-new-metainfo-path
branch
from
998ac43
to
1ae14fa
Compare
Read metainfo files from both share/appdata and share/metainfo to support new and old versions of flatpak-builder (flatpak/flatpak-builder#441) but only export to the new path. Fixes #4599
Read metainfo files from both share/appdata and share/metainfo to support new and old versions of flatpak-builder (flatpak/flatpak-builder#441) but only export to the new path. Fixes #4599
Read metainfo files from both share/appdata and share/metainfo to support new and old versions of flatpak-builder (flatpak/flatpak-builder#441) but only export to the new path. Fixes #4599
|
I merged flatpak/flatpak#4600, so apps installing to appdata will end up being exported to metainfo in the end. It also means that the build installing in metainfo will work, but only with newer (unreleased) versions of flatpak, so at the very least we should not merge this until that is widely available. In fact, I wonder it we need to merge it at all, as the end result will be the same anyway (files in metainfo). |
|
I guess one reason to merge this eventually is that we want the final name to match the source name as the comment says in |
|
@alexlarsson can you poke at this again? It's been a year and a half since the flatpak PR was merged, and it appears that the relevant Flatpak versions are available such that it can be assumed that the metainfo files are handled properly everywhere. |
|
Is there any update about this? Flatpak apps on Flathub still seem to have their AppStream metadata exported into the "appdata" directory with *.appdata.xml as their suffix. |
|
Is this now obsoleted by libappstream migration? |
Export to
share/metainforather thanshare/appdataas discussed in #252 and flatpak/flatpak#4600Fixes #252