Using appstream in xdg-app

[Richard Hughes]

> Each app ships an exported appinfo file. It goes into
> export/share/appdata, similar to how the desktop files goes in
> export/share/applications.

Makes sense.

> The name of the appinfo file needs to be "$(APP_ID).appdata.xml", in
> order to be allowed for export (xdg-app only allows files with the app-
> id as prefix to be exported, to avoid conflicts in the exported
> directories). The id of the app should be that of the desktop file,
> which due to the prefix rule is "$(APP_ID).desktop", and similarly the
> icon will have the app-id as the prefix.

Is this an upstream change required for apps? If so we probably want to blog about this a bit more, and if this does stick it makes the "find an application icon" code in appstream-glib becomes SO much simpler.

> In the repo
> ===========
> 
> Whenever the repo is updated we run appstream-builder on it,

The binary as a spawned exec or using libappstream-builder? If it's the latter we get a lot more control about where logs go and that kind of thing.

> i.e. a standard (uncompressed) appstream and corresponding icon cache.
> This directory is then checked into the repository as a branch called
> "appdata/$arch".  We also want to update static delta files for it, one
> from-scratch to allow initial fetch (which is otherwise slow for the
> many small icon files), and one that is from the last version (as this
> allows the deltas to the uncompressed appdata.xml to be encoded as a
> diff, which, assuming we sort it, should allow very small delta
> files).  Note that the xml will be compressed on the repo/network, but
> not on the client.

Makes sense.

> Additionally, during the extraction of the appinfo we can supply
> custom xml that overrides the appdata from the apps, or supply extra
> translations.

Any ideas on the format of this?

> On the client
> =============
> 
> Each xdg-app directory (i.e. /var/xdg-app and ~/.local/share/xdg-app)
> will maintain a local mirror of the "appdata" branch of each
> configured remote. This will typically be a reference called
> "€remotename:appdata/$arch" and be stored in
> "repo/remotes/$remotename/appdata/$arch".

wfm.

> Additionally, there will be a deployed version of this branch in
> "appdata/$remotename". This is where e.g. gnome-software would look
> for appdata info and icons.

Is there an issue here if more than one remote is shipping the same application ID?

> Localized data is pretty large, and we generally don't need all
> locales. For instance, on my fedora 23 install 62% of the uncompressed
> repo appdata is made up of localized strings. We could split up the
> xml files per-locale and have separate branches (say
> "appdata/$arch/$locale" and "appdata/$arch/icons"). Would this be
> worth it? Also, does appstream support localized icons?

We support localised icons in theory, but I don't think any of the tools support it. I'd say ignore this for now, localised screenshots are much more important IMHO and very few applications are doing that right now.

I'd also really like to keep the translations in one place if possible; 62% sounds a lot, but the total size of the XML file is tiny. Having all the locale data there also means you can switch your "language" in the control center and do searches in the new language *without* waiting for the next idle refresh of all the remotes to get your new locale appstream metadata. It also means I don't have to write that code to auto-fetch certain appdata locales depending on your locale, which would work okay for the --user target but be much harder to do system-wide.

> What do we do about appinfo id conflicts? For instance, a single
> repository can have two branches of org.gnome.Gimp, say "master"
> (tracking 2.10.*) and "2.8" (tracking 2.8.*). Both of these would have
> an id of "org.gimp.Gimp.desktop". In this setup, how can we tell the
> difference between the app ids? Also, if they have the same icon name,
> but different icon files, which one will be stored in the icon cache?

At the moment, the last added "wins". I'm not terribly sure it's a huge problem, but you certainly could put the commit id in the <id> rather than the application "name" if we needed to support this. As long as we had some way of getting the xdg-app app "name" from the AppStream file I don't think it matters. I think renaming the file like we do the .desktop file would also work.

> The way xdg-app handles conflics on the client is that you have to
> specify which one you want when you pull, and you can have multiple
> installed locally, but only one of the is "current". Only the current
> one gets its files (e.g. desktop file) exported to the system, and the
> other ones need to be started manually. Should we do something like
> that on the repo too? i.e. mark one current and ignore the others in
> the UI? Or should we extend the ids and icon names with the branch
> name?

I think we have to do the current thing; we don't want to return ~15 different "GIMP" applications when searching.

> The conflicts can also happen between different remotes. I.e. multiple
> remotes can contain the same app. gnome-software has to handle that
> somehow by showing a list of possible sources when installing the app.

This sounds more like a #gnome-design discusssion, but I'm pretty sure Allans response would be "JDI without asking questions" -- i.e. we need to 'prefer' one remote, or have some kind of prioritisation even if it's as simple as remote-added-first-wins or remote-updated-last-wins. People who want more control than that can use the command line.

Richard.