URI scheme should support listing alt ids

[hsitter]

The metadata format now supports providing previous ids via <provides> unfortunately the URI format doesn't.

It would be good if the format supported alternative ids being passed. e.g. something like

appstream://org.kde.filelight?alt1=com.github.darthvader.filelight&alt2=net.launchpad.vader.filelight

With the id renaming in place the target system evaluating the appstream URI could have any of those ids depending on how old it is.

[ximion]

@hughsie Do you have an opinion on this?
Seems like a reasonable thing to have...

[hughsie]

Not a fan of the alt2 etc. Maybe alt=org.foo.bar,alt.foo.baz

[ximion]

Not a fan of the alt2 etc. Maybe alt=org.foo.bar,alt.foo.baz

Obviously, yes. But if there are no objections to the thing in general, I would add it to the next release. Problem is that using the new scheme might break existing tools unless they explicitly already extract the path component of the URI.
KDE Discover currently fails at that, and GNOME Software also seems to have problems. So when added, it will be a while until we can really use this feature.

[hughsie]

GNOME Software also seems to have problems

Urgh, then it's an "API break" which probably needs a different URL prefix.

[ximion]

@hughsie Purely by the specification alone, this isn't an API break because the apps were supposed to use the path component as component-ID. Since there was no other URI component so far though, it was fine to not care about the specifics here and just take the whole URI.
So, in a way the implementations in Discover and GNOME Software are wrong, not the API.
That doesn't help in reality of course, where we'll run into problems :-P
I think another scheme would be really confusing... I could add the "alt" query to the URI scheme and add a big warning to not use this if certain older versions of GNOME Software / Discover should be supported (could be something like "Ubuntu 19.10, Debian 10, Fedora 31 etc. and higher").
The fix to this issue could actually also be deployed as a bugfix to the tools (all that's needed is to parse the URI properly).

[hughsie]

GNOME Software also seems to have problems

   path1 = gs_utils_get_url_path ("appstream://gimp.desktop?alt=org.foo.bar,alt.foo.baz");
   g_assert_cmpstr (path1, ==, "gimp.desktop");

...this passes. What problems did you see?

[ximion]

Very interesting! I just launched it with gnome-software 'appstream:org.gnome.Totem.desktop?alt=org.foo.bar,alt.foo.baz' and got an error message.
I just did this again though (at a different computer...) and it worked fine.
Given that KDE Discover's URI handling is broken anyway and needs fixing, I think we could actually add this feature in the next revision of the spec.

[ximion]

This was overdue, so it's in now. Discover still chokes on these URLs, so it may be a good idea to update it first ;-)

[hsitter]

Doesn't seem to "choke" on 5.17? appstream:org.gnome.Totem.desktop?alt=org.foo.bar,alt.foo.baz correctly opens totem

[ximion]

In that case I blame the ancient KDE/Qt components on Debian Testing. For some reason the Debian KDE team didn't update the KDE components for a really really long time now.
(I am running the latest Discover though...)

[aleixpol]

Just implemented this in Discover, should be available in Plasma 5.18 LTS.