-
-
Notifications
You must be signed in to change notification settings - Fork 555
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Supporting "AppStream" is an almost impossible task. #603
Comments
cc @ximion |
This does no good, I had removed it recently: |
@ximion is there a way to exit with 0 when there are no errors but some warnings? |
I also manually did run
|
And worst, the most recent versions of those tools will require the very latest glibc and will hence not run on older systems... whereas we tell people to always develop using the oldest still-supported LTS distributions in order to increase compatibility. Hence I suggested an online syntax checker. |
To me, everything looks like it works as intended - just the original AppStream file was wrong, and there is obviously a bug in the version of appstream-util used (the So resolve the confusion: You should have a @KurtPfeifle For your point 9. your version of appstreamcli is indeed too old - everything else should work though.
Can you tell me what they complained about? That would be helpful. The appstream-util tool is usually very restrictive in what it considers "valid", failing even on style issues. The appstreamcli tool is a lot more forgiving, failing only on issues that make the data invalid or result in degraded information that can be extracted from the files. @probonopd If a metainfo file produces warnings or errors when validated, it isn't valid and therefore we exist with a status > 0. An error means are violation of the specification of some kind, or an issue that renders the metainfo file completely invalid so no information can be read from it. A warning means that while we can get some information out, there is an issue that prevents fetching certain information (could e.g. be a typo in a tag name) and those should be caught and fixed by the user. I do wonder whether it makes sense to only validate with one utility here, or allow to define which one is used (e.g. appstreamcli by default, appstream-util on manual request). |
For everyone who wants to verify the validity and compliance of the appstream metadata files on his own system, here is how I examined one of my own systems, a Debian Stretch (v9.3).
|
@ximion wrote:
Well, it is the version shipping with Debian Stretch (v9.3) with all the current updates applied.
Sorry, not right now any more. I have fiddled around a lot with these files in that process, but didn't use a Git repository for versioning them. But quite a few editing steps can be re-constructed from my report above, no? But since I'll be re-visiting this topic over the next few weeks from time to time, I'll try to keep better track of this and provide more details. However, take a look at my previous comment above and spot the results of, for example, /usr/share/metainfo/org.winehq.wine.appdata.xml:
Details:
|
For the For the wine case, appstream-util is simply wrong on all accounts (or rather, nothing of the issues mentioned there is actually a problem, they are mere recommendations). In part, this is because appstream-util is far too strict, and because it isn't up to date in that version. (This is why I am thinking of starting to recommend using only appstreamcli, since that will show information about "nice to have" features, but not fail these cases (it only fails on warnings or errors) - appstream-util should for CI purposes only be used in relax mode, but even then it is sometimes a bit too pedantic) |
You just very convincingly argued the case for providing current versions of both these tools to me, provided as AppImages, so they could be used on any Linux system from the last few years, to get some consistent evaluation of existing or to be created .appdata.xml files.... |
|
@KurtPfeifle I have nothing against someone providing current versions of the tools. There is a PPA for recent Ubuntu versions, and I think Simon has also made an AppImageKit bundle for it. |
Can we close this issue? |
No, as it is not solved. The mere passing of time without an acceptable solution is never a justification for closing anything imho. |
As a workaround to get a up-to-date version of appstream-util... If you're not already using Flatpak, then first:
Run it:
Make sure that your file at least passes |
Thanks for your suggestion but Flatpak does not work for me. |
add workaround for building AppImage packages while appstreamcli usage in appimagetool tool is broken. See: AppImage/AppImageKit#603
add workaround for building AppImage packages while appstreamcli usage in appimagetool tool is broken. See: AppImage/AppImageKit#603
You can work around this issue by removing the appstream package from you system. (Worked on Ubuntu 18.04 at least) |
This gets even more ridiculous
Rename the file according to specs and now the validator can't find it:
|
@Mailaender That warning is not from AppStream - the file should be named |
Can someone summarize the problem please. I don't get it. |
This issue should serve as a place to discuss all this mess that supporting the Freedesktop.org "standard" for AppStream metadata is for application developers as well as AppImage maintainers, and how (if at all) it can be solved or worked around...
Here is a collection of stuff I encountered on a Debian Stretch system yesterday when I
"--appimage-extract"
-ed a perfectly working AppImage which had no AppStream metadata included and where I wanted to regenerate it after inclusion of just that info.appimagetool foo-squashfs-root foo.AppImage
Presence of
appstream-util
on the systemWhen this utility is present, it chases the developer in circles. Be my witness with going through the following stages:
Say, your
foo.appdata.xml
file contains the line:You then get something posing as a Warning but which nevertheless stops creating the AppImage, and you'll read this message:
Next, you try to fix it and make the above line now read
and rename your .desktop file accordingly to usr/share/applications/org.oneapplication.foo.desktop.
Now you still have no AppImage, but you successfully changed that "Warning" message to
Next, you try to fix that last issue and rename the .desktop file to now be usr/share/metainfo/org.oneapplicaton.foo.appdata.xml:
Bravo, you've now turned full circle (and been sent to read some "quickstart" document on Freedesktop.org).
Disabled
appstream-util
on the systemThis ominous
appstream-util:7983
gave you the hint to temporarily knock out and disable that dear goody by runningsudo mv /usr/bin/appstream-util{,___ko}
and then try to create the AppImage one more time. Oh, beautiful:Oh, BTW: the metadata license which above warning complained about was set as
MIT
. Just sayin'...Ah, ok... remove that AppStream template which was created before by the friendly
appstream-util
tool:Congratulations, your AppImage is being created -- however, it is missing the AppStream metadata:
You've (almost) turned full circle now. Except, that your AppStream data is now provided as
Let's rename it to foo.appdata.xml again:
after all, this is what appimagetool seems to be looking for. You AppImage creation now is canceled and ends with this message:
On the recommended chap-Quickstart.html resource
Next, read that document which had been hinted at before (https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#sect-Quickstart-DesktopApps). You find a recommendation about a tag called
<launchable/>
, which leads you to add the following line to your AppStream XML file:You go back to the situation in step 6, where at least an AppImage without AppStream metadata was created and run
appimagetool
one more time:Thank goodness, the AppImage is still created...
Let's enable
appstream-util
again, just to see how it groks that line:Fantastic!, now you again get no AppImage, but you are entertained with a different message:
Don't you also love it, if you follow the Freedesktop recommendations for tag names, and then a Freedesktop-recommended tool tells you that you have to re-name the tag to prefix it with an "x-"?
The text was updated successfully, but these errors were encountered: