Using appstream in xdg-app

Richard Hughes hughsient at gmail.com
Mon Dec 21 14:40:03 UTC 2015


On 21 December 2015 at 08:20, Alexander Larsson <alexl at redhat.com> wrote:
> I've not really done much public announcement of it, and its only
> necessary for upstreams to change if and when they create a xdg-app
> bundle. For instance, xdg-app-builder has some features to make the
> rename easy. Of course, everything makes most sense when you make the
> change upstream.

Right. If you write up a paragraph or two I can include it in only of
my "email all the people" broadcasts when I ask them to add new things
to the AppData file.

> I'm not against using libappstream-builder from xdg-app, but I would
> like it to be in a separate binary from the regular things that a user
> would use so that you only need to install it if you're building apps.

Makes sense to me.

> Maybe we can do things like git, and have "xdg-app build-finish" spawn
> "xdg-app-build-finish" which is in an optional package.

Right.

> No, i don't have any idea about how this could work, but I know that at
> least endless have interest in injecting app metadata (translations,
> etc) from the side. I was hoping you would know how to best do this. :)

So, my idea was to have an "override" AppStream XML file with values
that should be overridden from the upstream vendor; if the app-id
matches we just use the "priority" value in the <components> tag to
work out which data to use.

> Things would probably make most sense if we used the full xdg-app
> "name" as the id in the appinfo files. I.e:
>
> <id>app/org.gimp.GimpDevel/x86_64/master</id>

Hmm, I can see Matthias (as in Klumpp, not Clasen) not liking this as
the spec says it should be the desktop file name, i.e. the app-id. We
do however have the <bundle> tag which is supposed to contain the
xdg-app name like the following:

<bundle type="xdg-app">app/org.gimp.GimpDevel/x86_64/master<bundle>

Note, you can have multiple <bundle> tags for applications, although I
don't know if that helps or hinders.

> How does appdata currently handle multiple arches? Is there a metadata
> file per arch? xdg-app can share a single repo for multiple arches,
> which is not traditionally done for e.g. rpm repos (although multiarch
> does it a bit i guess).

We do have an <architectures> tag which is supposed to contain things
like <arch>i386</arch><arch>x64</arch> but at least on Fedora we don't
use this at all and none of the <component> entities have any
architecture information. This kinda assumes that the AppStream
metadata is a merged view of all the architectures, and you'd check if
your running arch was listed in <architectures> to see if it was
available on ARM for example. I guess it also makes it important to
standardise the values used inside <arch> betwee distros too, for
instance with ARM7 or HF v.s. SF.

> Yeah, I'll add a priority metadata field to the remotes.

Great, thanks.

Richard.



More information about the xdg-app mailing list