[AppStream] RFC: A UniqueID in AppStream

[Matthias Klumpp]

2016-08-08 17:47 GMT+02:00 Richard Hughes <hughsient at gmail.com>:
> For a long time appstream-glib has supported having more than one
> "scope" of component in the system store. This allowed us to represent
> more than one type of bundle in the gnome-software UI. An example of
> the deduplication ID I was using was "gimp.desktop" for the
> distro-supplied package, flatpak:gimp.desktop for the system flatpak
> instance, and flatpak-user:gimp.desktop for the per-user flatpak app.
> This was a hack, and meant the API was inflexible, but worked well
> enough if you remembered that each AsApp object ad a get_id() and
> get_id_no_prefix() method that would produce different results.

Thanks for bringing this up, this is actually something I am looking
into as well for a while now.

> I've been working a bit with Endless, and one of the requirements they
> have to have more than one branch of the same software in the AsStore,
> e.g. "unstable" and "stable". This allows them to filter in the
> application according to user preference. This is where my prefix hack
> breaks down a bit, as a "flatpak-user{stable}gimp.desktop" encoding
> starts to look more and more like a hack.
>
> I've prototyped a new "unique id" that I've been testing in
> appstream-glib for a couple of weeks. This isn't designed to be in the
> XML itself (as like the scope it depends on how the <component> is
> being used), but I'm using it internally for matching and
> de-duplication of apps. The unique-id is made up of the following
> string:
>
> scope/system/origin/kind/id/arch/branch/version
>
> the kind/id/arch/branch section should look familiar, as it's nearly
> the same (although, see below) to the ID that flatpak uses to identify
> different things in each remote. This means you can have a unique ID
> of:
>
> system/package/fedora/desktop/gimp.desktop/i386/f23/3.1.2
> or
> user/flatpak/gnome-apps-nightly/runtime/gimp.desktop/*/master/*

I think the "kind" is redundant here, as per AppStream spec there must
never be some component with the same ID.
What a "scope" is would need some clear definition, IMHO.

One thing that is bothering me is that we have version information
already in every AppStream component, and each AppStream provider
(each "repository") can only ship one version of an AppStream
component at a time (anything else would lead to ID collisions). With
this super fine-grained system you propose, we pretty much allow for a
lot of complexity in the system, showing users a massive amount of
options which software to choose from.

Previously, when there were duplicate IDs, we checked if one was from
a bundling system (has a <bundle/> tag) and folded that into the main
component, so there was really just one component in the data pool
offering two different installation methods. With your proposal, we
would have two components which could have completely different
metadata and would essentially be visible as different components in
the software center - and not only per bundling system and channel,
but also per version and architecture...

I am not sure if we really need that level of granularity (try to convince me!).

What I think is reasonable is an ID like:
scope/system/origin/id

Having the architecture in there might make some sense for multiarch
support, but do we actually want to expose that in any SC?
In any case, if we are going down this path I want the "system" (or
rather "origin_type") defined in the XML, to make this non-ambiguous.

> The wildcard character indicating "don't know" or "don't care".
> Supporting a wildcard makes all of the API so much easier to
> implement, for example an merge component might only have
> /*/*/*/*/gimp.desktop/*/*/* as the unique ID, which matches against
> the flatpak *and* the package instance.

Makes sense...

> Some differences to what flatpak uses:
>
>  * we're using "desktop" (or "desktop-application", urgh) rather than "app"

I don't think this is necessary, since the AppStream ID is already
unique enough here...

>  * we're using a .desktop suffix on the ID like in <id>

That's something which might change on the AppStream side in future,
aligning with the Flatpak scheme.

> So, I guess any comments are welcome; this isn't super important to
> get a consensus on as it's not in the XML representation, but I
> thought it might be useful to share what I'm doing as it's likely
> libappstream will be dealing with the same issue sometime soon.

I am dealing with it right now, even - itÄs one of the issues that
should be resolved for the upcoming 0.10 release (where I will break
API anyway, so it makes sense to get things right).

Cheers,
    Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/