Comment 37 for bug 645300

(In reply to comment #34)
> The point is - running another program to generate data then stuffing it into
> an rpm which we then ship out is a bad plan. Just as it was with specspo.
> Putting this data into the repodata is a better plan.

This is the process in generating the data:

* explode every rpm containing a desktop file (including selected deps where appropriate)
* extract lots of data from the desktop file
* copy the icons from the exploded root, converting and *resizing* where required
* tarring up the icon tree
* pushing the translations and desktop metadata into a sqlite database

This takes 4 hours on my laptop to do for fedora, or 30 minutes for rpmfusion. This is not something we want to do every day, for data that probably should only be updated once or twice a release (Ubuntu .

So, looking at positives and negatives, for putting it in a package:

Package:
 * Allows us to ship the data on the media, so the user doesn't have to "download metadata" every time they open the application tool
 * Allows us to query the database directly, rather than convincing PackageKit [to download us the single chunk of metadata and then import the metadata into the system database, as root]
 * Means we share the *same tools* as Ubuntu, Suse and Foresight.
 * Means we don't have to patch KPackageKit which already depends on the system database.
 * Means we can merge rating stats from other external sources before we ship the data, e.g. the gnome3 application usage stats
 * It already exists, and someone is willing to maintain the package

Metadata:
 * Allows us to ignore the fact that there are a few different licenses
 * Means we have to dedicate 4 hours per compose (possibly quicker if you have the rpms locally, but as we've discussed, the builders don't)
 * We have data changing daily that differs by only a few superficial entries
 * Means we can't use external data sources, for instance application usage stats
 * The app-install hooks in yum or PackageKit do not exist, and no-one is willing to write code for them. I've heard lots and lots of stop energy from the yum guys, but nobody has offered to write any code.

Also bear in mind: Ubuntu has been shipping app-install-data FOR FIVE YEARS. It works for them as a package. Why do you think they shipped it as a package back then? And still now? They have a very similar infrastructure to us.

The biggest point, and the most important from a user experience point of view is that we need to query the application database directly. If we make every query go through PackageKit, then through yum then we've killed our performance. Instead of getting responses back in the required 25ms for search-as-you-type we're talking about latencies of hundreds of milliseconds, or if yum has to check and download new metadata, *seconds*. This sucks and is simply not good enough.