[AppStream] Unifying the AppStream IDs

Matthias Klumpp matthias at tenstral.net
Fri Jul 22 10:19:54 UTC 2016


Hi everyone!
For a long time, the recommended AppStream ID format has been:

> A general pattern for a valid ID tag is to use a reverse URL scheme, consisting of <tld>.<vendor>.<product>.<type>, e.g. org.kde.gwenview.desktop or com.hugski.ColorHug2.firmware.

The reason for this is mainly historical, and today this doesn't work
too well. 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.

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. And in that case, they
could just change the IDs on their own quite easily.

So, what I want to do is:
 * Drop the requirement of ".type" in the AppStream spec for IDs
    - This means "org.kde.gwenview.desktop" IDs would become
"org.kde.gwenview" only.
    - 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.

 * Make not having a reverse-URL ID a spec violation for everything
that is not of component type "desktop(-application)". The validator
will throw an error for that.

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

Comments / thoughts on this?
Streamlining this would be really important, because the current ID
namespace is a mess, and since the unique IDs are one of the most
important bits of AppStream, it will be important to put some
constraints on them. Especially our story on "what ID should I pick?"
is pretty confusing and inconsistent for different component types
right now.
I am planning to make the necessary changes in AppStream with the next
release already.

Kind regards,
    Matthias

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


More information about the AppStream mailing list