Closed probonopd closed 7 years ago
All the assumptions are correct, and everything is actually documented.
If the <bundle/>
tag was allowed in metainfo files, you would find it in its documentation. How the compose server gets its information to build the final metadata is not something which should be in the spec, as it is an implementation detail. The spec makes suggestions for some obvious cases though (e.g. "take it from a .desktop file").
The bundle tag is described in the spec as having a string value, so of course no subtags are possible. And allowing it to be defined multiple times for different bundling systems is also mentioned there.
What is not mentioned is to define it for different "channels", because this concept doesn't exist in AppStream yet and needs some discussion first whether we add it and how it will look like then.
Thanks for the clarification.
Thanks for adding the bundle tag and for adding AppImage support.
Please document the best practices for how the bundle tag should be used. I try to summarize what I understood from our earlier conversation, feel free to correct me:
usr/share/metainfo/$ID.appdata.xml
files but is added to collection data (a.k.a. distro metadata) by a compose server (e.g., operated by a distribution or app store). If upstream adds the bundle tag tousr/share/metainfo/$ID.appdata.xml
anyway it is likely to be removed by the compose server<bundle>
tag. This is to allow for easier verification and deserialization. But it is possible to have more than one<bundle>
tag, even for the same bundling format (this is useful when an upstream wants to provide different channels like stable, weekly, daily, continuous, canary, aurora, etc.)