[Linux] Add AppStream metadata

[probonopd]

By (optionally) adding AppStream metadata to AppImages, deb, and rpm files, applications could present themself more richly in app centers (e.g., GNOME Software, KDE Discover), AppImageHub, and app stores.

https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#sect-Quickstart-DesktopApps

Important: Please be sure to check that the metainfo file passes appstreamcli validation.

[probonopd]

Hello @develar it looks like there is increasing demand for this, do you think it could be implemented anytime soon?

[ghisvail]

I second this. AppStream metadata should be forwarded upstream to avoid duplication of effort between packaging solutions. Without proper support in electron-builder however, it's difficult to motivate upstream projects to accept this file.

[GitSquared]

I've been willing to see this happening for so long i might end up adding a few bucks as bounty on this one. Please, we need this.

necroposting

[probonopd]

In the meantime, can that single file be added using extraResources or extraFiles?

https://github.com/electron-userland/electron-builder/wiki/Options

[softworkz]

I can't understand why this hasn't been implemented. For Ubuntu/Gnome, it's essential to have an appsStream file in the package - otherwise the app doesn't show up in "Software", so you need to uninstall from the command line. Also, and the app information shown is minimal,

It's been a painful path to get this working properly. I'll briefly describe my findings here, in the hope it may help others:

Getting the appStream file into the package

That alone wouldn't be difficult, but we also need to get it into the package with the right target path.

There's no way to get this done with the regular options, like extraFiles and the likes, because the target path is absolute:

/usr/share/metainfo/

Unfortunately, you cannot do like below:

        "extraFiles": [
            {
                "from": "src/io.github.myrepo.myapp.metainfo.xm",
                "to": "/usr/share/metainfo/io.github.myrepo.myapp.metainfo.xm"
            }

... becasue electron-builder tries to copy it to that location on the local machine - which is totally wrong.

Bug in electron-builder

[!CAUTION] electron-builder bug: Target paths in the to: value which are absolute, should either be disallowed or handled in a way that they are getting into the package with that path - in no case should they be copied to the path locally.

I tried this:

"to": "../../usr/share/metainfo/io.github.myrepo.myapp.metainfo.xm"

...but it just copies it outside at an upper level and not into the package.

Workaround

Finally I found a way, using the raw fpm parameter option:

    "deb": {
        "fpm": [
            "<local-path-to-file>/io.github.myrepo.myapp.metainfo.xml=/usr/share/metainfo/io.github.myrepo.myapp.metainfo.xml"
        ],
        "depends": [

But that's just the first of several other hoops that need to be jumped through.

Spaces in App Installation Path

The productName property is meant to carry the display name of the app. It is allowed to have spaces which makes a lot of sense, because many app names have spaces. So does ours.

But now - stupidly, the electron builder uses that for the installation path, which is /opt/{productName}/, so when the product name is "My App Beta", the target path iwould be /opt/My\ App\ Beta/. Albeit supported by the file system, this is highly unusual on Linux for app installations - And eventually I didn't get it working with the spaceful path.

Worst of all: there's no other way to change that path, other than changing your productName.

Shortcoming in electron-builder

[!CAUTION] electron-builder should allow to specify a custom installation path per platform. Or at least replace spaces with something else on Linux. Either way, it should not start escaping spaces in the .desktop file or elsewhere.

I really don't want my product to be named like "My-App-Beta", but I had no other choice:

"productName": "My-App-Beta",

But this also completely defeats the purpose of being table to have a single config for all platforms. Of course I don't want to do this for the other platforms.

I could remedy the display name in the .desktop file at least

    "linux": {
        "desktop": {
            "entry": {
                "Name": "My App BetaBeta",
            }
        },

[!NOTE] The way how to use desktop.entry exactly, is not documented. It took me quite a while to figure it out.

Executable Name and .desktop File Name

The binary name also defaults to the productName, but at least it can be overriden with the executableName value.

The name of the desktop file is set to the name of the executable, so when I set executableName to myapp, the desktop file gets this path in the package:

/usr/share/metainfo/myapp.desktop

The Problem

The Id in an appStream file must be a reverse dns name (as per spec), so I used something like io.github.myrepo.myapp.

And then, for everything to work, there are many different values which (at least) Gnome is matching up.

• The name of the appStream file (before .metainfo.xml)
• The Id tag inside the appStream file
• The file name of the .desktop file
• The content of the launchable tag in the appStream file
• The package id /appId

Maybe not all of them have to match. But that's how almost all other installed apps are authored, and I had tried so many combinations before without success, so I ended up making it all the same (io.github.myrepo.myapp).

But unfortunately, the name of the desktop file is not configurable - it is set to the same as the executable name. The only solution I saw, was to change my executable name as well to io.github.myrepo.myapp - which I would really like to have avoided...

Shortcoming in electron-builder

[!CAUTION] electron-builder should allow to specify a custom name for the .desktop file

Wrapping Up

It's been quite a way, figuring all this out. I am quite surprised that there are so many "plot holes" in electron-builder of which I had thought to be quite a mature project.

But I'm not here for ranting. Hopefully the above may be helpful for some people and possibly also for the developers of this project, to whom I wish to thank for their work!.

PS: I used the "note syntax" to mark those points which I think should be considered and looked into - the terms in the heading s do not make much sense, but I like the marking that they are triggering.