[AppStream] Unifying the AppStream IDs

[Richard Hughes]

On 22 July 2016 at 11:19, Matthias Klumpp <matthias at tenstral.net> wrote:
> The reason for this is mainly historical, and today this doesn't work
> too well.

Well, it allows me to ship a firmware for the ColorHug as:
com.hughski.ColorHug.firmware and also have the client tools as
com.hughski.ColorHug.desktop

> Additionally, for .desktop AppStream IDs, people simply
> started to drop the ".desktop" suffix to display the app, and there
> iis no technical reason to have the .desktop suffix in the first
> place, because the component-type already tells us that we should be
> looking for a .desktop file to add more metadata from it.

Well, if you just have an appstream-id without a .desktop suffix you
have to manually add it before you can launch it with GLib for
instance.

> The reverse-URL scheme also already guarantees the uniqueness of the
> AppStream ID, and the case that one vendor publishes e.g. a font and
> an app with the same name is really small.

See above.

> And in that case, they
> could just change the IDs on their own quite easily.

Sure, I could call the app com.hughski.ColorHugClient and the firmware
com.hughski.ColorHugFirmware but I don't see how that's better than
just having a suffix, especially when they are different types. I
would even argue to go the other way, to enforce:

<id-without-suffix>.<type> so we enforce that you can have the same ID
with different types, or I could just do this inside appstream-glib
complicating everything for no good reason. With two things with the
same ID and a different type you have to change lots of code paths.

>     - The old names must be supported for stuff using the ID to refer
> to the .desktop file, so we need a short transition phase for the
> AppStream tools.

This is a huge compatibility matrix of fail. GNOME Software is going
to look at the new metadata with the new-style desktop IDs, try and
launch them, and then show a failed-to-launch dialog box. We CANNOT
break backwards compatibility in such a huge way just to make the spec
somehow more pure.

>  * Slowly move the .desktop apps to use a reverse URL - we need this
> for DBus activatable apps and Wayland already, so it does make sense
> to push this a bit via AppStream. I am thinking of adding a validator
> warning in case a metainfo file has a desktop component and no
> reverse-URL ID.

So, we have different AppStream IDs to the desktop file name? A lot of
upstreams are unwilling to change the desktop file name (the app-id)
as it breaks things like adding apps as favorites.

> I am planning to make the necessary changes in AppStream with the next
> release already.

Sounds like you've made up your mind already... Please understand I'm
maintaining this stuff for decades in RHEL and can't modify apps in a
backwards incompatible way without a lot of notice and planning. Every
time we change the spec we become more and more known as "unstable"
and not ready for deployment. Please consider this.

Richard.