appstream support lacking provided ids (impairing backwards compat)

Bug #1778719 reported by Harald Sitter on 2018-06-26
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Snap Store
Undecided
Unassigned
Snapcraft
Undecided
Unassigned
review-tools
Undecided
Unassigned
snapd
Medium
Unassigned

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:

https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-provides

e.g.

```
<id>org.kde.newname.desktop</id>
<provides>
<id>oldname.desktop</id>
</provides>
```

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.

[1] https://www.freedesktop.org/software/appstream/docs/sect-AppStream-Services-UrlHandler.html

tags: added: 19.04 19.04-blue 19.04-external
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
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  Edit
Everyone can see this information.

Other bug subscribers