[AppStream] Unifying the AppStream IDs

[Matthias Klumpp]

2016-07-22 12:50 GMT+02:00 Richard Hughes <hughsient at gmail.com>:
> 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

And you can continue to do so - it would just not be recommended anymore.

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

Yes, but that would be really really easy and quick to do.

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

You could also just keep the old name...

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

Oh no, that would be insane! The AppStream ID will always be unique, I
do not intend to make the combination of ID-and-type unique.
I just want to waive the requirement for ".type" from the AppStream ID
requirements.
That doesn't mean that you are not allowed to have that, pretty much
everything can stay the way it is already (but new metadata might
choose to drop the type suffixes).

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

I would probably have a long transition phase for the .desktop case,
by having the metadata generator append the .desktop bit in case it is
missing...
But I get your point here.

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

Yes, that's why this would just be a warning and not an error.

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

I made up my mind on fixing the inconsistencies in the spec. This
could be done by enforcing a .type suffix to be added, or by removing
it. Removing it seemed to be like the better idea, since people don't
seem to add the suffix properly, or for generic components it doesn't
even make sense. You can also not easily change the type of a
component that way. Think of a new component type being introduced
which a previously generic component would want to use: With having a
type in the ID, the component would need to change its ID, which is
something I would consider to be really bad.

A compromise we could probably make is to waive the requirement for
everything but .desktop files... IMHO using the ID to launch stuff,
and therefore introducing breakage just by changing the component ID
is bad (but also nothing we can resolve easily anymore...).

How would this change impact distributions like RHEL, which do have a
fixed set of applications? Any change affecting new metainfo files
only would be not very relevant to those frozen disttros, would it?

In any case, I want to resolve this in a way you and RHEL can live with.

Cheers,
    Matthias

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