software-store-developers team mailing list archive

[Michael Vogt <mvo@xxxxxxxxxx>]

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).
 
> > [..]
> > > I would like to join this team because I'm interested in bringing the
> > > software center to Fedora, as it was done for Debian and OpenSuse.
> > > For this reason, I started patching upstream code, extending and
> > > completing the PackageKit backend, and I have something that I consider
> > > mostly working in a personal branch here at launchpad.
> > > My interest would be in sharing this work, and thus I'd like to merge
> > > most changes (including some that are not limited to the backends) to
> > > the trunk line of development.
> > [..]
> > 
> > I picked up the work on this again this morning. Its progressing
> > nicely, I noticed that installbackend_impl/packagekit_enums.py adds a
> > bunch of translation strings that are also available in packagekit. So
> > I send a patch to Richard (PK upstream) to make
> > pk_status_enum_to_localised_text() (and friends) available via the
> > library and he accepted adding it. It will be available in PK 0.7.2. I
> > will update the branch accordingly.
> > 
> > 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?

> 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.

> 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. 

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.

>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?

Thanks!
 Michael