Thing is: If we allow those separations, we would also need to allow putting the metainfo file in an arbitrary package, so in the end, in the worst case, we need to run a global archive wide or dependency- and reverse-dependency based search on the metainfo file, the .desktop file and icons. At least with the current generator's speed, that will consume resources. So right now, I am not sure if we want to have the tradeoff of putting two most of the time arch-independent files together with the binary (and consume slightly more space in the archive), or have longer processing times when generating the metadata. Since I am not a fan of the TryExec line[1] and separating .desktop files and metainfo, I would strongly prefer to adjust the packaging, since it also appears to be a rare event that the files are separated. This of course diverges from what people are used to do for a long time now, which is a downside. I still can be convinced that doing that archive wide hunt for the right file is the way to go, but at time I am questioning if it is worth to go through all that trouble if people could just fix the package once and avoid us doing that search again and again with every new upload. I will ask around at other AppStream-enabled distros how they handle it, maybe they have some useful input.
Btw, the appstream-generator rewrite I am working on is a massive improvement in terms of speed over the older one, but even that one spends a huge amount of time on getting contents information from packages and decompressing .deb files - so searching for files which aren't in the contents file by e.g. going through dependencies will still be an expensive operation. [1]: Desktops not only have to hunt down the icon, but *also* have to search through $PATH to check that a specific binary exists, which slows down loading all .desktop files. Caching the data isn't as easy as it is with icons too, since the binary could vanish (theoretically) at any time, and desktops would need to hide the launcher then. An icon gone missing at least doesn't affect the function of the launcher. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to evince in Ubuntu. https://bugs.launchpad.net/bugs/1553156 Title: evince not listed Status in appstream-glib package in Ubuntu: New Status in evince package in Ubuntu: Fix Released Status in gnome-software package in Ubuntu: Triaged Bug description: Using current xenial, evince is not listed in gnome-software. The log states it's of unknow application type ... could it come from the fact that the .desktop is in the -common binary? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/appstream-glib/+bug/1553156/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
