I am packaging some scientific software for distribution from the upstream website. I have understood the majority of the Fedora Packaging Guidelines and included both appdata and metainfo XML files in the RPM using macros (copied to %{buildroot}%{_metainfodir}, and %files lists those as hardcoded paths to /usr/share/metainfo/rDNS.[appdata/metainfo].xml).
Why does GNOME Software not display the source screenshot images, nor the metainfo included in the RPM?
The metainfo files are not what gnome-software reads. These are used by libappstream to generate the metadata for Gnome Software etc. Each repository needs to generate these and provide the metadata in a separate package:
You can refer to the rpmfusion package to create one for your repository. In the script that RPMFusion uses, the appstream-builder bit is important:
Note that you can also include the generated files in the “release” package for your repo, but that means bumping it each time you regenerate the data, which is why both Fedora and RPMFusion provide it in dedicated packages.
Thank you, that gives me plenty of information to work with.
Summarizing to check what I’ve understood:
Interesting, I learn more every day.
Yes, I believe that is the case. Here are some references I found:
Probably best to see how RPMFusion do it and replicate that.
That’s interesting. I have read another article by hughsie, 3rd Party Fedora Repositories and AppStream.
I have successfully built the software for CentOS Stream, Fedora Workstation 31-33, and EPEL 8 with COPR. The steps taken to include metadata in a COPR repository are supposed to be automatic; unfortunately, metadata.xml appears to be unprocessed for distribution with the repository.
The Free Desktop specifications state that appdata.xml should not be used anymore, and instead metadata.xml. I have both for my project, and I’m building on COPR again using only appdata.xml to see if that makes a difference to GNOME Software. I do see the COPR repository enabled in Gnome Software, but there are no results when searching for the application and it must be installed using DNF.
Reading the RPMFusion information, it appears that AppStream Builder needs to be ran against the packages manually, regardless, and resulting files placed into the /usr/share/app-info sub-directories for Gnome Software to read. I’m confused as to why that is, when the metadata is shipped with the packages directly, and why instead the metadata has to be installed from the repository, as would a package, before installing packages.
The COPR information in hughsie’s article makes me believe that when a repository is enabled on a system any metadata for packages available through that repository should be installed to the app-info directories, but that is not the case.
Yes, this is what I know. Packages include the metainfo/appdata files because there’s no other place for them to go really—but as far as I know, the information for gnome software has to be extracted manually from these files. Hughsie does periodic updates to the fedora appstream data also.
I wasn’t aware that COPR does this automatically. I’ve never done it there. Best to ask for help on their channels if things aren’t working as expected. For koji, I think it was discussed, but given that it requires extracting all packages in the repo which then need to be processsed, it was decided that the additional load was not worth adding to koji. So it is manually generated from time to time.
Also, I wouldn’t confuse repository metadata with appstream metadata. They’re not the same thing. Repository metadata does not have to include info on appstream data, since a repository does not necessarily need to provide appstream data.
I wouldn’t confuse repository metadata with appstream metadata. They’re not the same thing. Repository metadata does not have to include info on appstream data, since a repository does not necessarily need to provide appstream data.
Ah, yes indeed.
I’ll see what the COPR community can tell me, but for now at least the application is available.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.