appdata -> metainfo, add support for metainfo files

[Conan-Kudo]

These provides are specifically for packages providing AppStream files, which are either going to be *.appdata.xml or *.metainfo.xml files in /usr/share/appdata or /usr/share/metainfo.

The upstream AppStream specification mandates *.metainfo.xml files installed into /usr/share/metainfo, but there's still a large body of legacy AppStream files installed in the legacy location.

For now, let's support both under the new metainfo() Provides.

[dnf-bot]

Can one of the admins verify this patch?

[ignatenkobrain]

I think for plugins it should not be same...

[Conan-Kudo]

*.metainfo.xml is being used for everything now. You can see this in new KDE AppStream files, and GNOME ones as well. They aren't called *.appdata.xml anymore.

[mlschroe]

Wait a sec, those files are appdata, not appstream. Appstream is the data included in repositories. Appdata is the data installed in /usr/share/appdata and /usr/share/metainfo.

[Conan-Kudo]

@mlschroe That's not how @ximion explained it to me. He seemed to indicate that AppStream covers both aspects, and supersedes the old AppData spec.

[Conan-Kudo]

Hmm, apparently there is or was a difference between *.appdata.xml and *.metainfo.xml... https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html

[ximion]

@Conan-Kudo I understand this confusion, as in the early days AppStream was indeed "what distros ship" and the upstream metainfo files followed later, being part of AppStream and making the whole naming a mess. Since naming is especially important for a spec, this stuff is now sorted out properly:

• Data shipped by upstream projects is called metainfo and stored in /usr/share/metainfo (or the legacy location /usr/share/appdata - whether the files are named .appdata.xml or .metainfo.xml doesn't matter, but convention is to name the metainfo files for applications .appdata.xml
• Data shipped by distributors is called collection metadata and stored in /usr/(share|lib|cache)/app-info/<format>
• The whole project and family of specs (which are 90% identical) is called AppStream

The spec uses this terminology consistently, if you find any place where it is misleading or ambiguous, please file a bug against AppStream :-)

So, IMHO either metainfo or appstream would be fine - metainfo would be very accurate, while appstream would indicate that this is metadata that is part of the AppStream spec in general, without telling which particular flavor it is.

[Conan-Kudo]

@ximion Would as-metainfo work better as a name than appstream or metainfo? I want it to be clear what this actually is (a form of AppStream data).

[Conan-Kudo]

I think I want to just leave it as appstream(), as then we won't get bitten again by changes in what actually bits of AppStream are called.

[ximion]

The naming will never change again, unless we have a really really good reason for breakage (and I see none there).
as-metainfo would be fine if it fits the general style of these RPM names, appstream would also be okay - I don't really have preferences, take whatever you think is best.

[Conan-Kudo]

@ximion I've elected to change everything to metainfo(), as it resembles what we did before with calling them appdata().

[ffesti]

Thanks for the patch! Merged.

[mlschroe]

How about we remove the appdata provides generator from rpm? It's not used anymore anyway. The reason I added it was so I did not need to fetch the complete package filelist, as /usr/share/appdata is not included in primary.xml. That's why the original generator just added some provides for the file names.

It turned out that this approach wasn't very useful, as some packages used pretty much random filenames instead if the ids. So IMHO scrap the thing. Or replace it with some code that parses the xml data.

[Conan-Kudo]

@mlschroe I may come back later to make the generator a little smarter, but I wanted the name/path fixed first, as I rely on it for stuff myself.