+1

@rhughes any comment on this?

I just tested the proposed approach on a small scale by adding appstreamcli validation to eleven GUI packages I maintain, and I was unsurprised to find that I did not encounter any practical difficulties. (I retained the appstream-util version for compliance with current guidelines.)

Yeah, I found that appstreamcli is usually less strict when validating files, so switching over should not cause problems.

Ping. This is also now affecting KDE software. KDE uses appstreamcli validate to ensure their appstream data is valid in their CI but because we use appstreamdata-util our builds fail.

appstream-builder is the tool we use for generate AppStream repodata, which uses appstream-glib instead of appstream, so for that reason alone we need to keep using appstream-util instead of appstreamcli.

So we're stuck using a downstream tool instead of the "official" appstream one which makes our builds fail even though upstream code is fine against appstreamcli?

They are both official, and standards changes don't get implemented unless both projects are going to implement the change. The fact it fails appstream-util means the files are still broken, because it's more strict than appstreamcli in some regards.

Thank you for the additional info @ngompa

appstream-builder is the tool we use for generate AppStream repodata, which uses appstream-glib instead of appstream, so for that reason alone we need to keep using appstream-util instead of appstreamcli.

Hum ... given that the only place where appstream-glib is involved is in appstream-builder, but all client-side applications use appstream, shouldn't we make sure we verify that they work with both implementations? :smiling_imp:

Sure, if you want. But we can't drop appstream-util verification.