Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
[WIP] Allow AppStream to parse recommendations #45
This MR add the feature to AppStream to allow it to parse recommendation files. A recommendation file is defined by a XML document in the following format:
<?xml version="1.0"?> <recommendations> <recommendation> <id>vim.desktop</id> <because> <id>emacs.desktop</id> </because> </recommendation> <recommendation> <id>ipython.desktop</id> <because> <id>eric.desktop</id> <id>winpdb.desktop</id> </because> </recommendation> </recommendations>
Where id is the package being recommended and because is the user packages that generated this recommendation.
Currently, it is already working the construction and parsing of a valid XML recommendation, however there are some necessary improvements to be done:
Therefore, this MR is manly to collect feedback from the AppStream community regarding this feature.
Nice! I'll be a bit busy the next days (KDE AppStore meeting and other things), but I think I can give it a quick review tonight. One obvious thing to resolve would be fixing the test issues ;-) (minor stuff, as far as I can see).
<recommendations> <recommendation> <recommended>vim.desktop</recommended> <because> <pkg>emacs.desktop</pkg> </because>
You want to define a condition here, right? So, something like "if Vim present, suggest Emacs". The "because" should therefore probably be an "if". Also, I think the whole block is a bit strange... Why not put the recommendation into the component-block of the thing recommending it? So, something like:
<component type="desktop"> <id>emacs.desktop</id> <recommendations> <recommendation>emacs.desktop</recommendation> </recommendations> </component>
That would look far more simple to me, and would prevent the need for declaring logic in XML. Aside from that, your
I need to read the code this evening to fully understand the concept behind this and give some better feedback though ;-)
No problem. I will look why the build is failing. It is currently presenting this error:
gpg: no valid OpenPGP data found.var/lib/app-inf
But I will look it up to fix it.
But you are right, the tag names provided by your XML file are way better than the ones I have provided. I will create an XML file with better names and update the code accordingly.
Sidenote: I really want a reply function in the GitHub UI! Making replys manually is annoying...
No worries, that was a temporary failure due to the LLVM APT repo not being available. I took that as an argument to make the whole build process happen in a Docker container now, which allows us to be independent of the outdated Travis base system.
Okay, then why have this because information in the first place? Wouldn't simply dropping a list of recommended AppStream-IDs into some directory in
Okay, I have applied the rebase and I will check again if there is another problem during the build process.
But about the because tag. Originally, I though that it would be good for an user to know which of his packages generated the one being recommended. It would made the recommendation more trustworthy, since the user would see the reason behind it. Therefore, I thought that the applications that would use this AppStream data could display this extra information for their users.
However, maybe on the context of AppStream this extra information is really not necessary or I can make it optional.
8 times, most recently
Jun 6, 2016
added a commit
this pull request
Aug 9, 2016
I fixed up the first two patches and committed the result to master.
Bonus points for adding some validator hints (e.g. having a
I already took care of the YAML world (and pretty much all other bits) - the remaining piece is getting the merge logic work for (almost) all fields, see the
I hope I can do a new AppStream release ASAP.
The libappstream library is capable of writing the necessary XML or YAML files for merge components now.