Menu

#510 Provide AppStream metadata

NextRelease
pending-accepted
nobody
None
5
2026-04-07
2024-10-13
No

When an application like Fuse is packaged it is up to each distribution to provide things like a description of the software, screenshots, links to the home page, bug tracker, and so on.

AppStream is a cross-distro metadata specification that allows software projects to provide information about themselves. This makes it easier to create user-friendly app centers which show consistent and distribution-independent information about installed and available packages. AppStream is used by applications like GNOME Software and KDE Discover and is also used by other packaging systems like Flatpak, Snap or AppImage.

Flatpak uses AppStream to provide the information that you see in flathub.org, in the case of Fuse this is the URL:

https://flathub.org/apps/net.sourceforge.fuse_emulator.Fuse

That AppStream metatada was however added by me to the Flathub repository when I uploaded Fuse there. The recommended thing to do (and this is the reason why I'm writing this) is to put the AppStream metadata directly in the upstream repository, as this is meant for applications to describe themselves and have control of that information.

The metadata itself is just an XML file so adding it to the Fuse repo is only two lines in a Makefile.am. The other implications are:

  • It is recommended that the AppStream file is updated with every new release of Fuse to include a brief list of changes. This should not be as detailed as our ChangeLog file and it should only contain a couple of lines listing the most important changes. Example: for Fuse 1.6.0 I added "New 4X scalers", "Added TTX2000S emulation" and "Several UI fixes and improvements". You can see that in the Flathub link I pasted above.

  • In AppStream every app is expected to have an ID that uses the reverse-DNS format. In the case of Fuse that is net.sourceforge.fuse_emulator.Fuse

  • That ID should be reflected in the name of the .desktop file and its icon, so fuse.desktop would become net.sourceforge.fuse_emulator.Fuse.desktop and fuse.png would become net.sourceforge.fuse_emulator.Fuse.png. This has no user-visible changes so everything will keep working the same as before.

And I think that's it.

Discussion

  • Alberto Garcia

    Alberto Garcia - 2024-10-13

    Here is the patch.

     
    • Fredrick Meunier

      Hi Berto,
      I don't think this patch is quite complete? (at least when I apply it with patch I don't get all the files mentioned and renames done). Could you make a fork with your changes?

       
  • Fredrick Meunier

    • status: open --> pending-accepted
    • Group: future --> NextRelease
     
    • Alberto Garcia

      Alberto Garcia - 2026-03-31

      Thanks! Remember that from now on we should add the release notes to the data/net.sourceforge.fuse_emulator.Fuse.metainfo.xml file, see the <release date="2026-03-24" version="1.7.0"> tag for an example. The list of items in the description are the ones that will appear in places like Flathub and such.

       

      Last edit: Alberto Garcia 2026-03-31
      • Fredrick Meunier

        TBH it would be helpful if the release process is less manual and multi-step and more automated. If it could have a script to generate it from Changelog that would be very helpful.

         
        • Alberto Garcia

          Alberto Garcia - 2026-04-04

          That should be easy to do, the appstream file only needs the changelog entries.

          What's your usual workflow when you make releases? Because the actual ChangeLog file is very verbose and you need to select what things to highlight for the release notes.

           
          • Fredrick Meunier

            Traditionally, just try to review all commits since the last release for the project, write scripts to update dates and version numbers and so on. Frankly it has not been sustainable.

            The last release I used a coding agent to help do all that which helps, but in general lowering the amount of work required to do the task is vital to minimise the toil of just doing releases.

             
            • Alberto Garcia

              Alberto Garcia - 2026-04-06

              Regardless of the tools that we may use to automate the work, I can help with the next releases if you want. Like that I can also have a better overview of what actually needs to be done.

               

Log in to post a comment.

MongoDB Logo MongoDB