[PATCH] Blender should supply an AppStream metadata file to downstream packagers
Closed, ResolvedPublic

Description

Blender does not provide an AppStream metadata file. This makes life harder for downstream packagers like Linux distros and Flathub, since each one of them must re-invent the wheel with their own information about Blender. This also fragments Blender's branding because it gives up control of key information about the software to others. If you provided an AppStream metadata file, downstream packagers would use it and you would remain in more control of your branding and presentation on those platforms.

I'm attaching an AppStream file you can use. Please feel free to incorporate this file and update it accordingly for future releases. This makes life easier for downstream packagers like Linux distros and Flathub.

Note that the text in this file can be translated. For an example, see https://cgit.kde.org/krita.git/tree/krita/org.kde.krita.appdata.xml?id=390f8d72a559575e7179287acc6d238c7b36a3bb

Details

Type
To Do
Nate Graham (ngraham) renamed this task from Blender desktop file doesn't define an AppStream ID (should be "<id>org.blender.Blender</id>") to Blender doesn't define an AppStream ID (should be "org.blender.Blender").Dec 22 2017, 12:42 AM
Nate Graham (ngraham) updated the task description. (Show Details)
Nate Graham (ngraham) renamed this task from Blender doesn't define an AppStream ID (should be "org.blender.Blender") to [PATCH] Blender should supply an AppStream metadata file to downstream packagers.Dec 23 2017, 5:29 PM
Nate Graham (ngraham) updated the task description. (Show Details)
Nate Graham (ngraham) changed Type from Bug to To Do.

Does the readme.html already provides the necessary information about the release? Could that be parsed? What formats are needed and are they standardized between different distros and packages?

Parsing the readme.html file to generate this file (especially the <release> tags) is probably possible, but that would unfortunately have to be acocmplished through some custom tooling on your side.

An AppStream file actually is the standardized format between distros and packages. Most Linux software developers provides one for their software at this point, because it makes life for downstream packagers, and also gives developers like you better control over how information about your software is delivered to users. You get to control the branding, screenshots, description, release notes, etc, rather than leaving this up to downstream packagers.

It also ensures that when Blender is available through multiple sources (e.g. Flathub and distro packages), software center apps like GNOME Software and KDE Discover are able to de-duplicate them correctly and show a nice "which source do you want to install this from" UI rather than confusingly and erroneously showing multiple versions of the app, like this:

Relevant information:

FWIW after asking around, a lot of projects are using the AppStream file as the canonical source of truth, and then generating other files from that.

Hey @Nate Graham (ngraham)! It'd be better if you post this via differential (like in KDE's phab). I can do it for you if you don't want to mess with Blender's repo.

Also there's a couple of errors in the xml file:

  • ID tag closed with a li tag on line 9
  • Double quotes on line 16

For the update_contact tag you should probably ask in the mailing list, #blendercoders (freenode) or the differential revision.

@Diego Gangl (januz) that would be lovely, thanks. I didn't submit this using differential because I wanted to give the Blender developers flexibility regarding where to put it and what tweaks they might want to make.

Also, thanks for pointing out the errors in the file. I submitted this a while ago, before I knew about appstreamcli validate. I've attached a new version that has valid XML and passes appstreamcli validate.