software-store-developers team mailing list archive

[Giovanni Campagna <scampa.giovanni@xxxxxxxxx>]

Il giorno mar, 13/12/2011 alle 09.53 +0100, Michael Vogt ha scritto:
> On Mon, Dec 12, 2011 at 09:00:29PM +0100, Giovanni Campagna wrote:
> > (cumulative answer since I didn't have much time in the last few days)
> > 
> > Il giorno lun, 12/12/2011 alle 18.21 +0100, Michael Vogt ha scritto:
> > > On Fri, Dec 02, 2011 at 08:52:43PM +0100, Giovanni Campagna wrote:
> > > > Hello everyone,
> > > Hi again,
> > >
> > > [...]
> > > 
> > > The icon-names in historypane.py will need a bit of thought too to
> > > make it compatible on both PK and aptdaemon systems. 
> > 
> > I guess we should bring the issue at freedesktop, agree on a common set
> > of icon names, and then ping our respective icon theme authors.
> 
> Sounds good to me, in the meantime I will just make sure both are
> supported (based on if PK is availalbe or not).

Awesome. Issue reported at freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=43796.

(In any case, probably we need a try: except: surrounding the code that
loads the icons, as there will always be weird incomplete themes without
them)

>> [...]
> > > 
> > > I put my progress into lp:~mvo/software-center/fedora.
> > 
> > I saw your changes. It's cool we have pk_status_enum_to_localised_text()
> > (although, ghgh, localised...) in the library.
> 
> I'm not quite sure I understand the "ghgh" :) ? is "localised" too
> long as a word? Or something else that I missed?

Don't worry, nothing important. Just that localised should be localized,
as everything else is using American spelling.

> > As for the changes you made to the distro class, I need to warn you that
> > at fedora-devel we are discussing a completely different backend for
> > screenshots, rating&reviews, and possibly even icons (for legal
> > reasons), based on the existing fedora package database. I still need to
> > start the client-side of this, though.
> 
> Thats absolutely fine of course. Please note that both our screenshot
> server and the reviews backend are free software. So you may want to
> consider just hosting a instance of those. I'm keen to learn more
> about the work that fedora is planning here. Of course its fine to
> write a new one, we need to put a bit more abstraction into place in
> the client, but I don't think it will be a huge amount of work.

About the rating&reviews stuff, I think we'll go with pkgdb simply
because we already have it running now, with a web interface and an
undocumented JSON API (you can see it at
https://admin.fedoraproject.org/pkgdb), although it needs some work on
both sides.
As for screenshots, I saw that your server is really just a proxy to the
debian screenshot mirror, so maybe we can do the same.
Which leaves us to icons. I didn't talk to fedora-legal yet, but
considering previous comments there is a real possibility that we'll
need a dynamic backend for those. (bah...)

> > Finally, I'm not sure about runtime detection of PackageKit. While it
> > makes sense on rpm distros (where software-center package would Require
> > PackageKitGlib-1.0.gir, and never run without it), on apt distros it
> > would mean that even installing packagekit by chance changes the
> > behaviour of the software-center substantially. The code is generally
> > biased on the apt side, with PK hacking around apt concepts (for
> > example, the xapian databases generated by PK and apt-cache are not
> > compatible, because of the slightly different interpretation of
> > XOorigin), so in no case one should have the PK backend enabled in an
> > apt distro. Maybe we can make this configurable at buildtime?
> > (I don't know distutils enough, but it is possible with other build
> > systems...)
> 
> Good catch! I agree that its currently not ideal. I will fix
> that. When it comes to differences (e.g. origin) I wonder if we can
> not fix this in a compatible way. 

Uhm...
apt-cache has origin, label, archive and component as different fields,
while packagekit only has repo-id and description (which is what yum
has, btw).
In my implementation, I mapped repo-id to origin and description to
label, then I added some heuristics for generating archive and
component. So for example a repo-id ending with -source gets a component
"source", and a repo-id ending with -updates-testing gets an archive
"testing". I saw that XOarchive and XOcomponent are not used (except for
license strings, which I bypassed taking the license from the package),
but XOlabel was sometimes used to do channel identifications (as XOlabel
and XOorigin are always equal in a debian-like distro), and I had to
change it to XOorigin.

> I did a bit more tweaking on the branch now, could you please check it
> out and tell me your thoughts? If it looks good I will merge into
> trunk and we can push a new release out.

To me, all your changes seem reasonable and look good.

> From memory there is one performance issue currently about PkgInfo
> "is_installed". This is called often from the listview code but
> iirc/afaik this generated a PK query every time. I wonder if instead
> we could make the code query PK for all installed pkgs at startup and
> cache the value (and keep it updated of course if PK sends change
> events). WDYT?

I looked into that for the whole package list, and it simply took too
long to fetch. OTOH, it seems possible to do if filtering on installed.
I'll try and see if I come up with something.

Giovanni

Attachment: signature.asc
Description: This is a digitally signed message part