appstream support lacking provided ids (impairing backwards compat)

Bug #1778719 reported by Harald Sitter
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Snap Store Server

Bug Description

The appstream extractor thinks one appstream file may have only one id, equally the snap apps' common-id mapping makes the same assumption.

Single id isn't a thing in appstream, and hasn't been for a while:



indicates that the appstream component is also "oldname.desktop" in addition to "org.kde.newname" and provides a means for backwards compatibility. The use case behind this is that if the desktop file needs to be renamed software stores will still be able to resolve the old id (e.g. uris [1]). Additionally this helps with de-duplication of overlapping entires: if the distribution repositories contains an old package which still was oldname.desktop, the software stores will be able to know that a snap providing org.kde.newname is the new variant of it and show the application as one entity as opposed to two with roughly equal data and ultimately referring to the same application (albeit in different package formats).

This is a major flaw in the current implementation as this prevents id backwards compatibility.

In the yaml schema there ought to be a supplemental-common-id key to list these "old" ids, or common-key needs to be changed to allow an array (with order having meaning so as to differentiate main-id from legacy ids).

The appstream extractor then needs to parse <provides> ids and extend the snap.yaml of associated apps accordingly.


tags: added: 19.04 19.04-blue 19.04-external
Revision history for this message
Sergio Schvezov (sergiusens) wrote :

snapd would need to support an array for common-id and so would the store in order to support this

Changed in snapd:
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Samuele Pedroni (pedronis) wrote :

> snapd would need to support an array for common-id and so would the store in order to support this

the last time this was discussed we agreed that snapd should support only one common-id, one needs to pick which one to use for the snap.

If we want to change/reconsider this, it probably needs to be rediscussed somewhere a bit more visible than a bug

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.