Using appstream in xdg-app

[Alexander Larsson]

On mån, 2015-12-21 at 14:40 +0000, Richard Hughes wrote:
> 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.


Something like this maybe:

In order to protect against filenameconflicts between sandboxed apps,
xdg-app has some additional limitations on how desktop files, icons and
dbus service files are named. They must all have the same prefix, and
that prefix is what xdg-app uses as the application id.

This means that the application id is the same as the dbus name
(because the dbus service filename must be "$dbusname.service"). This
also matches the modern dbus-activation version of desktop files which
already requires the name to be "$dbusname.service". So, in practice
most apps would do this already (or eventually). The main change you
have to do for xdg-app compatibility is to name the icon based on the
dbus name too (so "$dbusname.png").


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

Ok. The could work I guess, all the different versions and arches of
gimp would have the same id, but different bundle value. Then gnome-
software would ignore any of them with a bundle-id for the wrong arch,
and bunch the the rest under the same "app" in the ui, with some rule
on how to pick the "main" version.

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

I'm not sure you need this necessarily. You could use the arch part of
the bundle-id. Thats standardized by necessity, as xdg-app calculates
the arch part automatically, unless you manually specify it.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl at redhat.com            alexander.larsson at gmail.com 
He's a lonely skateboarding waffle chef looking for 'the Big One.' She's 
a sharp-shooting out-of-work safe cracker with someone else's memories. 
They fight crime!