#1053 gnome-software switched from libappstream-glib to appstream
Opened 3 years ago by decathorpe. Modified 4 months ago

The guidelines at https://docs.fedoraproject.org/en-US/packaging-guidelines/AppData/ require all appdata files to be validated with appstream-util validate-relax.

However, gnome-software 40.beta has switched to using the appstream implementation from appstream instead: https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/583

We should probably switch appdata validation from the metadata library nobody uses any longer to the one that's actually used by gnome-software (and all other app stores in Fedora):

appstreamcli validate --no-net $PATH

Which also means switching BRs from libappstream-glib to appstream.


+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.

So we want to change the guidelines to do both?

Can someone add a script/macro that does both with one call/line?

Metadata Update from @james:
- Issue tagged with: needinfo

7 months ago

Yes, it looks like we need to run both validation steps, since both libraries are still in use.

I thought about doing a BRP script instead that failed the build, but that's 1. possibly backwards incompatible and 2. would also require adding appstream-util and appstream-glib into the default buildroot. So RPM macro it is, I guess. I can try to implement one, but I can't promise that it will happen very soon :)

I do wish we could just validate these things automatically.

I wonder, though, could we avoid forcing appstream-util and appstream-glib into all buildroots and instead just require them to be build dependencies when needed? The BRP script would just fail the build if there is something that needs checking but the packager neglected to add the dependencies.

I don't know if we have anything else that works this way, though. The only tenuous precedent that I can come up with is the way %autosetup -S git works, where you have to manually add the dependency on git-core.

Or this could be enforced by the out of package test gating logic we have, though personally I prefer that everything possible be repeatable in a local koji build.

Having the BRP script just do nothing if the necessary BRs are not included would be a possible solution, but it would still require mandating the BRs ... so we're back at square one where this validation requires manual work for packagers. But having the validation in updates CI would be a good idea as well, because it can run unconditionally there, since the CI test has control over the environment it runs in.

I don't think we can avoid any change like this requiring some work for package maintainers. Doing checks like this in a BRP script has the end result that packagers can lose some boilerplate, so the end result is still positive. It is possible to do things slowly over time as well, and an interested group filing PRs can help quite a bit.

One possibility is to make the BRP script warn if it needs to check something but a dependency is missing, which gives you a marker in the logs. After a mass rebuild and some grepping, you can gather some stats and start generating emails/PRs/bugzilla tickets. Eventually the big switch can be flipped to fail instead of warning.

When and if we start requiring appstreamcli validation, I think we should favor passing --explain,

appstreamcli validate --no-net --explain $PATH

so that the output isn’t so cryptic.

Login to comment on this ticket.

Metadata