[Bug 488968] Review Request: fedora-app-install - Fedora application data

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=488968

--- Comment #36 from Richard Hughes <rhughes at redhat.com> 2010-09-08 04:03:34 EDT ---
(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.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.