A software center for Fedora

[Martin Bacovsky]

On 12/07/2011 09:50 PM, Toshio Kuratomi wrote:
> On Wed, Dec 07, 2011 at 02:23:05PM +0100, Giovanni Campagna wrote:
>> Il giorno sab, 03/12/2011 alle 22.58 -0800, Toshio Kuratomi ha scritto:
>>> Yep.  This is a pseudo-bug.  Because of the way people have been
>>> interpreting the spec for .desktop files, all of these provide .desktop
>>> files where the name is "Terminal".  So they're all placed on the same page.
>>> This could be fixed in the .desktop files (Judging from past experience,
>>> I think that's a losing effort).  Or someone could code up some other ways
>>> of extracting and reconciling this information.  There are other things that
>>> could be enhanced in this.  For instance, there's currently no extraction or
>>> recording of information about applications that lack a .desktop file.
>> That's wrong, as explain by Freedesktop menu spec. You should group
>> applications according to the desktop file id, which is the desktop file
>> path, minus /usr/share/applications, with .desktop stripped and with /
>> replaced by -. This way, gnome-terminal (which
>> has /usr/share/applications/gnome-terminal.desktop) becomes
>> gnome-terminal, while konsole (which
>> has /usr/share/applications/kde4/konsole.desktop) becomes kde4-konsole,
>> and no conflicts are possible (otherwise, you would get a menu conflict
>> and/or a rpm file conflict).
>> Name, GenericName, X-GNOME-FullName, etc. are user visible strings and
>> should not be used as identifiers.
>>
> 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.
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.

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'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 :)

Regards,
Martin

>
>>>> As for repodata, you mention tags, but I can't find them here, in
>>>> primary, comps or other (and I don't see anything else in mirrors).
>>>>
>>> I hit a mirror and browsed around.  Here's the one for the F16 x86_64 update
>>> repo:
>>>
>>> http://mirrors.xmission.com/fedora/updates/16/x86_64/repodata/pkgtags.sqlite.gz
>> Interesting. In fact, the file exists, but only for updates repo, not
>> for fedora. Is there a reason for that?
>> (I'm looking at
>> http://mirrors.xmission.com/fedora/releases/16/Everything/x86_64/os/repodata/)
>>
> Not sure.  Maybe one of the rel-eng's would know the answer to that.
>
> -Toshio