[PATCH] Blender should supply an AppStream metadata file to downstream packagers #53611

New Issue

Nate Graham · 2017-12-22T00:09:05+01:00

Nate Graham commented

2017-12-22 00:09:05 +01:00

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.

org.blender.Blender.appdata.xml

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

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. [org.blender.Blender.appdata.xml](https://archive.blender.org/developer/F1999109/org.blender.Blender.appdata.xml) 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

Nate Graham commented

2017-12-22 00:09:05 +01:00

Added subscriber: @ngraham

Nate Graham changed title 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")

2017-12-22 00:42:57 +01:00

Nate Graham changed title 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

2017-12-23 17:29:38 +01:00

Vuk Gardašević commented

2017-12-24 00:48:45 +01:00

Added subscriber: @VukGardasevic

Vuk Gardašević commented

2017-12-24 00:48:45 +01:00

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?

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?

Nate Graham commented

2017-12-24 03:08:51 +01:00

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:

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: ![Screenshot_20171223_190542.png](https://archive.blender.org/developer/F1509005/Screenshot_20171223_190542.png) Relevant information: - https://www.freedesktop.org/wiki/Distributions/AppStream/ - https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#sect-Metadata-GenericComponent

Nate Graham commented

2017-12-28 02:30:37 +01:00

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.

Diego Gangl commented

2018-01-15 18:07:21 +01:00

Added subscriber: @Januz

Nate Graham commented

2018-01-26 21:11:12 +01:00

Friendly ping!

Diego Gangl commented

2018-01-26 22:48:57 +01:00

Hey @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.

Hey @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.

Nate Graham commented

2018-01-27 12:21:09 +01:00

@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.

@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.`

Nate Graham commented

2018-02-13 06:25:01 +01:00

Changed status from 'Open' to: 'Resolved'

Nate Graham closed this issue

2018-02-13 06:25:01 +01:00

Nate Graham self-assigned this 2018-02-13 06:25:01 +01:00

Nate Graham commented

2018-02-13 06:25:01 +01:00

D3025: Add appdata.xml file for Linux packagers has landed, so this is done!

[D3025: Add appdata.xml file for Linux packagers](https://archive.blender.org/developer/D3025) has landed, so this is done!

Sign in to join this conversation.