appstreamcli not able to explain correctly a wrong icon tag

[fedelibre]

As discussed here, appstreamcli validate was not able to explain a problem in a metainfo file. Even worse, it was leading me on a wrong track.

The error printed by appstreamcli is:

$ appstreamcli validate-tree --no-net --explain build/files
org.frescobaldi.Frescobaldi.metainfo.xml
  E: org.frescobaldi.Frescobaldi:~: app-categories-missing
     This component is in no valid categories, even though it should be. Please check its metainfo
     file and desktop-entry file.

? Validation failed: errors: 1, pedantic: 1

The categories are set in the desktop file and I know that appstreamcli should check categories in the desktop file if they are not present in the metainfo. So my guess was that for some reason the desktop file could not be found. A wrong guess.

Eventually I was told that the problem is the presence of this tag in my metainfo file:

<icon type="stock">org.frescobaldi.Frescobaldi</icon>

For the records, appstream-util was able to detect and explain the error correctly, here's the output:

• tag-invalid           : stock icon is not valid [org.frescobaldi.Frescobaldi]

Can you improve this error detection?
Thanks

[ximion]

No, appstream-util is broken here, you should not use it.
And appstreamcli is correct with its warning. The problem is this:

• We only pull data from desktop-entry files if we need to, so, if a metainfo file has a stock icon defined, it is assumed that the metainfo file is complete on its own.
• If appstremcli knows that no desktop-entry data will be pulled, it validates the metainfo file more strictly, and only then does it raise a warning that you need to add categories.

This issue can be avoided by validating the two files together with validate-tree, and admittedly, the behavior is a bit obscure. But since the "pull data from desktop-entry files" is implicit by design and not explicit, there's sadly no good way for ascli to know which validation rules to apply when, other than using heuristics.

The only reason you "fixed" it with appstream-util is because that tool validates incorrectly, and just happened to flag a tag that you had to remove to make ascli's heuristics assume that there will be a desktop-entry file and switch to its more relaxed validation mode.

[fedelibre]

Thanks for the explanation. It makes sense.

I used the icon tag, because I found it in the documentation and I could not imagine that it could have broken this "data pulling" from the desktop file.
Maybe adding a warning in the docs might help?