Re: xdg-app discussions at the GNOME DX hackfest

[Alexander Larsson <alexl redhat com>]

On fre, 2015-01-30 at 11:28 +0000, Allan Day wrote:
> Hi all,
>
> I just returned from the recent GNOME Developer Experience Hackfest in
> Cambridge, UK. We discussed xdg-app a fair bit, particularly in terms
> of the overall user experience it could provide. I've copied my
> (incomplete) notes below, for those who might be interested.

I'll follow this up with a bunch of more random things we talked about.

* UI for xdg-app
The complexities of e.g. mixing xdg-apps with system packages, and the
early state of xdg-app as well as the many unknowns means its very hard
at this point to have any real idea of how the final UI for apps (e.g.
in gnome-software) will look. So, rather than trying to come up with a
general solution we'll focus 3.16 on the lower levels of the problem.
I.e. building the runtime, building the apps, making it easily testable,
but mainly via commandline ops (to reach the right audiences). We'll
keep working on gnome-software integration, but we'll focus that on a
special build that shows off what an xdg-app-only gnome-software could
look/work like.

* What happens when multiple versions of an app is installed?
Say TheApp 2.0 and 2.2 is installed. Both of these will have the same
dbus id, and thus necessarily the same desktop file id name. We can't
auto-rename this during export, because it *has* to be the name of the
dbus name. Not to mention that the UI in the shell when launching apps
will be very confusing.

The resolution we came up with here is that xdg-app needs to track which
version of an app is "active", and only export the files from that one.
One could then swap this at a later time. If the developer wants to have
parallel installable apps will have to rename one of them. The typical
usecase for this is beta/development releases of an app. Such apps could
be renamed to e.g. "TheApp (Testing)" in the desktop file and
org.foo.TheApp.Testing as the dbus name. Ryan wanted to add an option to
GApplication to be able to use a custom dbus name, then this renaming
could be done purely in the desktop/service file rather than having to
rebuild the app.

* gnome-software wants a descriptive name for repos
When you add-remote a repository we should do some i/o to verify that
there really is a remote at the other side. We should also look in the
remote configuration for some kind of description of the repo (and allow
a local commandline arg to override this) so that we can store a local
nice description we can show in list-remotes.

* Allowing/disallowing app requirements
Right now the metadata file for an app only lists the requirements, and
xdg-app always fulfills these. We need to somehow verify that this is
what the user wants, and store this agreement somewhere where xdg-app
can verify it.

* How to specify kdbus sandboxing limitation
kdbus allows "filtering" of the bus, limiting what names you can own and
which ones you can talk to. The amount of options for this is
essentially infinite though, and there is no sane way to expose that to
the user. We need to have a limited amount of option that the apps can
chose from. The obvious ones are "anything", and "only own my name, can
only talk to safe portals". We need to sit down and figure out on a case
by case basis if we need other levels beyond this.

* Reproducible builds
I talked to ross about how reproducible the current builds are. This is
kind of important to us, as ostree de-duplication relies on producing
bitwise identical files. There is someone who has done some work on this
in yocto, but its not currently a general goal for yocto. We need to do
some experiments with this to see how bad it is and whether we need to
do any work on it.

* yocto security releases
Yocto generally does security updates for a stream until there has been
two major releases after it, but sometimes longer. For instance, there
has been updates for branches that were ~2 years at least. This is nice
for us as it allows us to piggy-back on that work. There has been talk
on and off in the yocto community about a long-term release branch with
longer support. If that happens that would be very interesting to us.
There has been a bunch of updates since the 1.7 release we're currently
using, so we probably should import those.

* Test app with custom runtimes
To be able to test apps on different runtime (i.e. to test if an app
work on gnome master) we want to add a --runtime=foo option to xdg-app
run.

* Make it easy to bundle stuff for apps
We really really need to get some kind of story on how to easily manage
bundling with your app (ideally such that the same binaries are used for
ostree dedup). This currently is a major pain point for making app
bundles, and we have only vague plans. We discussed a lot of options
here, but nothing has been done so far.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a one-legged moralistic cyborg gone bad. She's a supernatural snooty 
lawyer from the wrong side of the tracks. They fight crime!