Il giorno gio, 08/12/2011 alle 19.41 +0100, Martin Bacovsky ha scritto: > On 12/07/2011 09:50 PM, Toshio Kuratomi wrote: > > On Wed, Dec 07, 2011 at 02:23:05PM +0100, Giovanni Campagna wrote: >>[...] > > > > Except.. the URL is for a user visible string (just like a menu entry). At > > least, that's what I think the intention was. We can ask mbacovsk (CC'd) > > if that was in fact intentional. If not, feel free to change it. > > My intention was to map applications from all active fedora and epel > releases. > I found out that desktop file ids were not reliable identifier as they > sometimes differed among releases. > So I chosed to use the application name as the grouping attribute (it > differed as well) and I had to implement some heuristic, trying to guess > which desktop files belong together. This is indeed a problem, but IMHO we should optimize for the single version case - at the cost of having multiple entries for the same app. As policy, we can additionally ask maintainers and upstreams to avoid changing the name of a desktop file. Again, the desktop file id is what app launchers group on, so it's the only reasonable field to use, if we want consistency between the software installer and the launcher. > One of the requirements was user to be able to install selected > application from the web, so I had to match the desktop file to the > respective rpm in each of the releases. Is this really a requirement? To me, installing from the web (as currently implemented, not with the packagekit plugin) is just a security hole, as you're installing untrusted packages and sidestepping the yum repository. > I created a few patches to make the heuristic more precise and eliminate > false matches(it matches the exec and distro executables as in some > cases the .desktop and executable it triggers are not in the same rpm) > but didn't deploy them since then as it makes the pkgdb a lot slower > then it is today. I was thinking about fulltext search as a solution but > newer it make it into reality. I think fulltext search needs to be made local, to be efficient. I heard there were already plans for using Xapian, so let's see what turns out. > I'm open to discussion about necessary changes to make pkgdb's data > usefull for you. For a start I'll look what is wrong with the JSON > exports :) Great, thanks! Giovanni
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
