A software center for Fedora

[Giovanni Campagna]

Il giorno sab, 03/12/2011 alle 22.58 -0800, Toshio Kuratomi ha scritto:
> On Sat, Dec 03, 2011 at 04:13:37PM +0100, Giovanni Campagna wrote:
> > Il giorno ven, 02/12/2011 alle 16.37 -0800, Toshio Kuratomi ha scritto:
> > > On Fri, Dec 02, 2011 at 09:39:31PM +0100, Giovanni Campagna wrote:
> > > > 
> > > > packagedb seems an interesting project, for storing ratings and reviews,
> > > > and it could be a candidate to replace the Ubuntu backend. Is there some
> > > > documentation somewhere? Does it provide some webservice API (REST,
> > > > JSON, SOAP, anything)
> > > > 
> > > It does.  Many of the URLs that you can use to view information in a web
> > > browser will return the equivalent information as JSON data.  Not all of the
> > > URLs are fast enough for what you may want to do with them now, though -- we
> > > may want to craft some custom methods that give you the information you need
> > > faster or in bulk.  Another option for some of the things is to have users
> > > enter it into the packagedb but to export it via the repodata.  This was
> > > done for the tag information for instance.  From reading one of Richard's
> > > review request bugs, it looks like people wished to do the same thing with
> > > icons but there were possible legal problems with that approach (the legal
> > > problem seemed to cover distributing the icons in either the repodata or
> > > a package :-( ) so you'd probably need to pioneer a different approach here.
> > 
> > Uhm...
> > curl -H "Accept: application/json"
> > https://admin.fedoraproject.org/pkgdb/applications/Terminal results in
> > 500 Internal error.
> 
> Yep.  I said many URLs.  If you want to enable this for this URL we just
> need to add an
> 
> @expose('json')
> 
> decorator to that method.  But, I'm not sure if that URL will serve your
> purposes or not... my experience is that it is a bit slow as currently
> implemented.  Plus you'd need to query the packagedb for every package
> you're looking up which introduces the latency of round-tripping to the
> server and back.  This may be a good place to start and then after you
> understand where the bottlenecks are, you may want to work on some custom
> pkgdb-server methods to aggregate data.

I was thinking to use that url to find reviews and screenshots for each
application. This is something that software-center shows for each app
individually, so making a separate request is not a problem.
As for ratings/icons, we may need aggregate data instead, except that
still 

> > Also, packagedb seems to be coalescing different packages and apps in
> > one (same example: konsole, gnome-terminal and xfce4-terminal are all in
> > the same page).
> > 
> 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.

> > 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/)

Giovanni
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20111207/4a09cfc5/attachment.bin