#1041 Use only .metainfo.xml in AppData guidelines
Merged by james. Opened by oturpe.
oturpe/packaging-committee appdata-update  into  master

Download 1041.patch

Current AppStream documentation instructs saving all AppStream metainfo with file extension metainfo.xml and mentions appdata.xml only as historical (though supported) format. Since metainfo.xml is now preferred, Fedora should use it for all AppData.

Using only metainfo.xml extension also makes the guidelines somewhat simpler, since less duplication is needed to cover two file extensions.

Relevant discussion:
1. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HYLVPAHS5WS5QZIDLTAXLT3XFH6SUBS2/
2. https://pagure.io/packaging-committee/issue/944
3. https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/thread/TPJPRPTGXNPK3R3BYGDVF3H3UNOR45J2/

I'm not sure if only mentioning metainfo.xml file extension is a good idea, since almost all upstream projects still use appdata.xml. This might lead to the (wrong) impression that packages have to rename those files (which they do not).

rebased onto e708aff16d49ec5929b2c6749a9a8b7fa69b6a69

That is a valid concern. I added a new paragraph to cover that situation:

For GUI applications, extension +.appdata.xml+ MAY be used instead of
+.metainfo.xml+ if upstream provides an AppData file named so.

Does that address your concern?

Wouldn't it be better to extract it into NOTE: *.appdata.xml*: and describe it as obsolete practice? That way, it would send a message to package maintainers that they should collaborate with upstream to update the AppData to the latest specification.

rebased onto 9e32bf66b34e8f43af6ca07f00c181e57cf1b53c

Another good suggestion. I moved the appdata.xml discussion into a note.

I did not add explicit suggestion to submit an update upstream, and used milder terminology than "obsolete practice", since a) I read @decathorpe 's comment as supporting not actively directing resources in renaming existing metadata files and b) AppStream also uses quite mild wording for this ("supported for historical reasons", compare with "deprecated and may be removed in a future release" they use for the appdata directory). The note can be rephrased if different tone is desired.

Commit d66c26a5 fixes this pull-request

Pull-Request has been merged by james

Pull-Request has been merged by james

Metadata