Today, for once, I want to write about something else than just weekly reviews: how to ensure your application shows up in the Software Centers.
openSUSE currently ships two ‘Software Centers’. These programs make installing/removing of *applications* – things the USER actually cares for, easier. They both use the paradigm of ‘application stores’, that many users are well used to. (for reference, the two SCs currently are ‘KDE Discover’ and ‘GNOME Software’; they both use the same underlying technology * metadata, called AppStream).
Every now and then, some packagers reach out and ask why their application does not show up. There can be several reasons, but I want to try to explain the most common ones, that are likely to solve your issue > 90%.
NOTE: I will based the blog on example packages that have failures at the time of writing this post. This will obviously not valid for a long time and you won’t be able to ‘just reproduce’ what is written here. In order to reproduce the issues, you need to install the package “appstream-glib”.
The two most common issues are:
1) Packaging errors: the ‘icon’ file can’t be found
2) Metadata errors : The appdata file is invalid
Category 1 – packaging error
(I used openSUSE:Factory/python3-veusz)
Get the current binaries from OBS in order to reproduce the issue and inspect the packages
$> osc getbinaries openSUSE:Factory python3-veusz standard x86_64
$> appstream-builder --packages-dir=binaries --include-failed --verbose
The interesting part in the log file is:
<vetos>
<veto>Has no Icon</veto>
</vetos>
While inspecting the rpm (easiest: unrpm veusz3.rpm) we can find that the .desktop file references an icon named ‘veusz3’, but this icon is actually not part of the veusz3.rpm package. As such, the builder is arguably right and there is no corresponding icon in this package (the icon is shipped in python3-veusz, which in turn is a dependency to veusz3, which is why on installed systems the issue does not surface).
Solution: put the icon where it belongs. Note: it must be a FILE inside /usr/share/icons/hicolor/ and NOT a symlink pointing somewhere outside this tree. This is due to the way the builder extracts files: only known directories are extracted to avoid issues with huge rpms.
Category 2 – Invalid metadata
(I used openSUSE:Factory/wxMaxima)
Same thing, we start getting the built rpms in order to analyze them:
$> osc getbinaries openSUSE:Factory wxMaxima standard x86_64
$> appstream-builder --packages-dir=binaries --include-failed --verbose
The issue seen in the log is not really different to before:
<vetos>
<veto>Has no Icon</veto>
</vetos>
Once you understand how the information is gathered, you will see that the resulting error makes sense, even though it’s not always very helpful.
A bit of background then: For an application to show up in the Software Center, they need to be described in an AppData file. This file is part of the package and in case of wxMaxima is called /usr/share/appdata/wxmaxima.appdata.xml. The appdata.xml references the .desktop file that is used to launch the application:
Solution: Fix the metadata. The .desktop file referenced in the .appdata file must exist. In plus, the NAME of the .appdata.xml and .desktop file should be aligned, so use the same NAME. This is not strictly nescessary by the AppData standard, but many tools rely on this (so also libzypp)
Conclusion
Those are the two most common issues why applications don’t show up in a Software Center. The Tumbleweed distribution produces a list of packages that had been veto’ed for inclusion. It is updated with every snapshot release and can be found at http://download.opensuse.org/tumbleweed/repo/oss/suse/setup/descr/appdata-failed.xml.gz and a decoded version can be found at http://gs-stats.leuenberger.net/appdata-failed.html