What happens in Discover in when an app is available from multiple sources–say, Flathub as well as your distro’s packages?
As long as both versions of the app provide the same AppStream ID, Discover will show a single entry and let you choose which one you want to install, like this:
But if any of the available versions use a different AppStream ID, they’ll show up separately:
Uuurgh, how awful. Which GIMP is the real GIMP? And why do they all have different names?! Flathub uses org.gimp.GIMP as the AppStream ID, while The GIMP developers provide gimp.desktop for distros to use as the AppStream ID. And the Snap version provides no AppStream ID, sadly.
So we need the GIMP developers to change their AppStream ID to the same one that Flathub uses (which actually follows the AppStream spec). I submitted a patch to fix it that was recently accepted, so this should be resolved with the next GIMP release. That will unify the first two, but the third–which comes from Snap–won’t get rolled up into it until Snap uses AppStream IDs. The Snap folks are on the case, but it’s still a work in progress.
But adopting AppStream only work as long as developers are populating their AppStream files with valid IDs! An AppStream ID is supposed to look like com.myurl.NameOfMyApp, not NameOfMyApp.desktop or com.myurl.NameOfMyApp.desktop. Flathub gets this right, but a lot of app developers themselves get it wrong, and it’s up to us to help them, and make sure the AppStream IDs in their files match those on Flathub.
I’ve started to submit patches for apps that unify their AppStream IDs:
- Blender: Fix AppStream ID and add release information
- Inkscape: Fix AppStream IDand add release information
- GIMP: Fix AppStream ID (done) and add release information
- Endless Sky: Fix AppStream ID and add release information (done)
- Hexchat: Fix AppStream ID (done)
- Telegram add release information and use AppStream Data in Ubuntu packaging
- Transmission: Fix AppStream ID
- Lollypop: Add release information
- VLC: Fix AppStream ID (done)
- Pitivi: Fix AppStream ID and add release information
- FileZilla: Fix AppStream ID (done, but need to redo–see discussion here)
- Shutter: Fix AppStream ID (done, but need to redo for the same reason as FileZilla)
- 0 A.D.: Fix AppStream ID
- Audacity: Fix AppStream ID (done)
What can I do to help?
See all those patches I submitted? You can do the same! If you use any apps that have AppStream IDs in their distro packaging that are incorrect and different from what’s in Flathub, then submit a patch to fix it! Keep in mind the following guidelines:
- Dashes/hyphens must be replaced with underscores: com.shutter-project.shutter is wrong and should be com.shutter_project.shutter
- Leading digits in the app name are not allowed: com.wildfiregames.0ad is wrong and should be com.wildfiregames._0ad
- If the AppStream ID used for Flathub is wrong, don’t replicate that wrongness with your patches; encourage developers to use correct AppStream IDs and file a bug for the app on Flathub, like this one.
For extra credit, you can also submit patches that add information, too. This will make the app’s version string show up in Discover:
And here’s the properly formatted information in HexChat’s AppStream file that provides it: https://github.com/hexchat/hexchat/blob/master/data/misc/io.github.Hexchat.appdata.xml.in#L29
I know this isn’t the most immediately rewarding work, but it’s super important to make Flatpak (and later Snap) work properly in a mixed environment where you also have distro packages available. If you want the world to be Snappier or more Flatpacked, this is probably the easiest way to make it happen if you’re not a programmer or a packager. If you need a hand, you can email firstname.lastname@example.org or check out the #flatpak IRC channel on freenode.org.
As always, if you find this work useful or valuable, please consider becoming a KDE contributor or donating to KDE! But do consider submitting patches for Apps that have sparse or incorrect AppStream data. You’ll be doing your part to pull Linux software distribution into the future.release
10 thoughts on “How you can help drive Flatpak adoption”
Thanks for this blog post. It gives a easy understandable insight of the benefits and inner workings of AppStream files. And it is written in an encouraging way.
If the AppStream ID is used for deduplication, what will happen when Snap begins supporting it? If a app is packaged as both snap and flatpak, which format will the user get when he press install? Or maybe the multiple formats will be shown on the application page, just not when search is used or by navigating the categories? Not that it matter that much, but I’m curious how it works.
Like your writing style, you make it very easy to understand how to contribute! Hopefully many will help out.
Thanks, I’m glad you find these posts interesting and useful!
Discover lets you choose a default source on the Settings page, which determines which version is shown by default when an App is available from multiple sources (distro packaging, Flatpak, Snap…). The user can change the default, or selectively change the source on a per-app basis.
Once Snap supports Appstream, everything gets better because Snaps will get listed in the source chooser UI on the app page instead of in the browse and search lists.
“If you want the world to be Snappier or more Flatpacked”
But I don’t. I’m quite happy using a normal package manager for my software.
LikeLiked by 1 person
Then you don’t have to use them! Distro packaging isn’t going away anytime soon. That said, Flatpaks and Snaps can be managed using CLI tools just like distro packages can, if that’s your preference.
That’s even better than what I thought. Thanks for the explanation!