A software center for Fedora

[Giovanni Campagna]

Il giorno dom, 27/11/2011 alle 18.47 +0100, Björn Persson ha scritto:
> Giovanni Campagna wrote:
> > We also need translations (that are in .desktop files
> > but not in .spec files),
> 
> Looky here, a spec file with translations:
> http://pkgs.fedoraproject.org/gitweb/?p=mine_detector.git;a=blob;f=mine_detector.spec;h=294bcf4148789afb1ba7bb7b11971e231e001061;hb=master
> 
> Making lots of translators co-maintainers of all packages just to let them 
> translate the spec files wouldn't scale of course, but there also exist 
> translated package descriptions which do not originate from the spec files – 
> even for packages without desktop files. At least some Swedish translations 
> exist; I don't know about Italian. I can't tell you exactly how those 
> translations are produced and distributed, but someone who works with 
> translations presumably could.

Well, I'm happy to see that some spec files are translated. In fact, I
found out some packages have translations, but those are only visible
from yum, not PackageKit (no matter how you insist).
In any case, I would consider spec files as somehow complementary to
desktop files. As you point out in an other mail, we currently don't
have good user visible titles in rpm metadata, but for most of our
packages this is not an issue, as most of the users should not even
notice their existance.
On the other hand, a .desktop file has the property that the very same
file, when the package is installed, will end up
in /usr/share/applications and thus in the app launcher (gnome-shell,
kmenu). This means that the categories exposed in the .desktop file
actually reflect the position of the application as installed, that the
name and the command are exactly the same, etc.
Also, it becomes possible to have multiple applications in the same
package, without the user knowing that one app is part of a bigger
collection.

> > we need screenshots, we need reviews, we need
> > ratings.
> 
> OK, then I'm starting to understand what you want. You might want to find a 
> better term for that than "application installer", as it apparently does a lot 
> more than just install applications.

Ubuntu settled with Software Center, and explicitly says translations
should not use the equivalent of Application Center in the guidelines.
We could do the same, although for the GNOME case we may want to keep
Add/Remove packages (gpk-application), even if shipping the
software-center, because, as the implementations stands, packages
without a .desktop files are not shown.
(The KDE case is different, as apper handles both app search and package
search)

> How much new server infrastructure do you think would be needed? Is a 
> hierarchy of FTP mirrors with a round-trip time of a day or two satisfactory 
> for distributing reviews and ratings?

Tricky question. There are various services here to consider:
1) repo metadata.
I've prepared a small python script that explodes rpm and generates
suitable appdata.xml and app-icons.tar.gz. Once built, they can be
distributed like every other .xml file in repodata.
Since appdata.xml is the primary source of information for
software-center (even before primary.xml), it must always be in sync
with mirrors (otherwise it may try to download non existing packages) 
2) rating/reviews.
I don't know exactly what infrastructure Ubuntu uses, but it seems to be
a single server with django; maybe it's possible to get away without
mirroring. In any case, the rating/review API is RESTful but requires
special knowledge in the server; FTP or HTTP alone are not enough.
(debian has reviews disabled, opensuse uses ubuntu's infrastructure)
3) we need screenshots.
Currently all the three distros use the same servers (shared between
debian and ubuntu); this is going to be a large amount of data (on avg.,
4 large jpgs per app), so perhaps we could agree with the other distro
and use the same imgs. This said, if screenshots are stale for a bunch
of days (or weeks, even), I wouldn't care.

Giovanni

PS: to be honest, there is a 4th item in the list: a server for
accepting app store payments. I don't think this would be appropriate
for Fedora, at least now.
-------------- 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/20111127/cf456ae9/attachment-0001.bin