I must say that I found appstreamcli to be to unstable in CI of projects that I used to
maintain, and file format documentation and validator source code reality diverge, and
behaviour is understandably changed between appstreamcli revisions. We had to disable and
later re-enable the metainfo tests in GNU Radio for various CI runners, because slightly
different versions of the same validator couldn't agree amongst each other and with the
file format documentation what is legal and what not.
There used to be a formal definition of what is legal in that file format (an XSD file),
but it got, again, understandably, removed by the appstream maintainer, because they
couldn't stem the workload of writing both a C parser/validator for this XML format as
well as keep that XSD up to date [1].
So, now: we're left in a situation where we have a human-oriented documentation that we
can't trust, a choice of two validation tools that are both buggy in our experience, and
although this is an XML format, no format definition.
If Fedora depends on that validation, we might **really** want to help maintainers get the
formal specification of the format back into shape. That would also make checking the
documents tool-independent, and allow for validation in rpmbuild/lint steps without the
wealth of dependencies that the specific tools bring.
My 2ct, anyway.
Cheers,
Marcus
[1] https://github.com/ximion/appstream/issues/279
On 24.09.23 00:04, Michael Catanzaro wrote:
On Sat, Sep 23 2023 at 10:26:48 PM +0200, Alexander Ploumistos
<alex.ploumistos@xxxxxxxxx> wrote:
Could someone involved
with AppStream please provide some information? Shouldn't our
documentation be changed to reflect these changes? Does the FPC need
to decide on this?
From upstream perspective: appstream-util is indeed obsolete. Upstream software should
stop using it and switch to appstreamcli instead.
But as you've noticed, it seems Fedora isn't ready for that yet....
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
