PackageKit backend for Software Center: pencils down report

Software Center in openSUSE

Software Center with PackageKit backend in openSUSE Factory

Today the official coding period of GSoC 2011 ends. It’s been a four months journey, with challenges, failures and achievements, but nevertheless fun :-) .

You may be wondering what is the status of my project; here it goes: current version of Software Center can be tested in openSUSE Factory; it can populate its database with data from an AppStream XML; it shows application information (fetched from the package manager); it installs and removes software, in the same friendly manner the ubuntu does (showing progress, handling dependencies).

Moreover, my patches to gobject-introspection, PackageKit and obviously software-center, are all upstream and released; kudos to the project managers and the community for helping me get them there.

There are still parts that need work; some of then have been intentionally left with lower priority from my initial plan, in order to get a functional version up by the end of the program; others weren’t covered by the planed feature set. These are: performance (current version is rather slow on first load, and also on showing list, due to many resolve calls), transaction history (it can be implemented using the almighty PackageKit), reviews (currently these are fetched from ubuntu servers), screenshots (same as reviews). Software Center itself passes a period of active development and changes, once its fancy Gtk+3 interface stabilizes, more work can be done into polishing the <other-distro> experience.

Although I’m generally happy with the result of the project, since this is a report, I want to outline what differed from my expectations and slowed me down from bringing a full feature set cross-distro Software Center:

  • fast development – when I started hacking on software-center’s GUI, it was pygtk Gtk+2 based; a Gtk+3 branch existed, but was far from being usable; under the last few weeks, it was merged, and actively developed into a newly designed interface (which will become software-center 5.0);
  • Gio, GLib, GMenu, GObject, usually libs starting with a capital G, which introspection bindings are about to stabilize; having to get them from trunk, and dealing with API breakage;
  • waiting for the pygobject release; when it came, it broke my pygtk mixed work (since static vs GI are no longer permitted in the same program – which is the right choice. btw), and left me with no working GUI; luckily, I took the best advices on IRC, and also software-center devs fixed things along, so that the new UI isn’t affected by the underlying changes.

Something worth mentioning in this finale post is that OBS totally rocks.

Overall, I hope this effort won’t stop here, and with a bit of luck, it will be shipped by your favorite distribution :D

PS: for more implementation/testing/plan details, I have created this page on openSUSE wiki, please check it out.

PackageKit backend for Software Center: week 11 status report

This week in three short achievements:

- personal OBS project (playing around, tutored by DimStar), work in progress

- code tide-up, ready for merging into master

- features, usage and testing documentation, work in progress

I’m now focusing on the gtk3 part, and also documenting things around. Packaging has decreased priority, waiting for the pygobject release.

And done ;-)

PackageKit backend for Software Center: week 10 overview report

This week I’ve been trying to make things work correctly under openSUSE, and also provide an easy way of testing. I couldn’t achieve it, but I’m optimistic about doing it in the current week.

What’s been keeping me busy:

- getting a generic channels list in non-Debian based distributions; how things work: when the update-software-center script is called, a xapian database is populated with application data from various sources (software sources lists, AppStream XMLs, etc); each document entry has an origin property; based on this unique origins a list of software channels is generated dynamically (such as Provided by vendor, For purchase, From given PPA); I couldn’t find (yet) a friendly way of getting a package’s origin in PackageKit so I’m currently mocking it; what now works is listing all the applications from Appstream under an unknown channel;

- compiling a list of dependencies and a recipe for building my PK branch under openSUSE;

- fixing the script that populates the software-center database, making it work with PK too;

What I’m currently working on:

- building pygobject, glib, gobject-introspection and PK from master branches in openSUSE; next step is packaging;

- sanely hiding unused features, such as For purchase (Canonical specific), What’s new or Recommendations

- fixing the newer soon-to-be-pushed-as-default gtk3 interface, so that all the functionality of the backend is there; (fixing my code and assuring there are no unnecessary apt imports)

- getting the PK branch merged into s-c main

- testing and improving (I’m particulary unhappy with some implementation details, such as the fake caching I’m doing inside the PackageInformation class, or the mix of asynchronous calls with synchronous)

What I had on my calendar, and probably won’t happen before the end of GSoC is the personall AppStream mirror and the icon fetching work.

That’s it.

PS: today, somebody asked on #PackageKit when will this be ready, planning to push it to the next Debian. This sounds awesome :-) .

PackageKit backend for Software Center: short week 9 report

Hi all,

It’s nice to write to you again. I’ve been having a 10 days vacation (that’s why there was no week 8 report), enjoyed it and now I’m back with fresh forces.

This short (started slowly on Tuesday) week’s activity regards:
- almost fixing a bug that prevents my PackageKit software-center from prime time: package information isn’t correctly refreshed after an installation/removal
- starting work on the openSUSE integration (the corresponding Distro class, removal of forgotten apt related imports, dependency identification and testing).

I will continue work on this side and hope that by the end of the next week, will have everything working and up for testing in openSUSE.

Cya :-)

NB: I will have to provide for testing a trunk version of pygobject since a release is delayed by another awaited merge;

PackageKit backend for Software Center: short week 7 report

Short weekly report is short, this week’s achievements:

- fixed the install/remove simulation bits (it can now tell what packages will be removed after applying changes)

- improved PackageInfo testing (works with both AptCache and PackageKit)

- found the problem with dynamic/static libs conflict: it is gio statically loaded from gtk and then Gio dynamically loaded from PackageKitGlib; loading Gio before everything seems to fix the conflict for now;

- got another round of refactor changes into trunk, thanks to mvo; this way my PK branch is one step closer to merging into software-center

ktnxbye :-)

PackageKit backend for Software Center: week 6 report

Hi everyone, for this week report I would like to show you a screencast with the packagekit-backend branch of software-center:

As you can see in the video above, I’m using PackageKit in Software Center for the install/remove operations and also for fetching package information, such as summary, description and version.

The install backend lacks updates and addon management; also the dependency simulation is missing. For package information, work is still needed into getting license, installed_size and other custom fields, but all these seam doable.

Before you jump into running it by yourself, please note that to get PackageKit introspection working, you need the invoke-rewrite branch of pygobject, which will hopefully be merged into main and released next week.

This milestone being set, my work continues by completing the backend and then moving forward to other things such as optimizing or distro integration, packaging and testing :-)

PackageKit backend for Software Center: short week 5 report

This week I continued work on the install backend, especially connecting the PackageKit transaction signals to the software-center’s TransactionWatcher (also abstracted by me some time ago).

The challenge stands in differences from PackageKit and AptDaemon, such as in AD, after preparing a transaction and manually commiting it,  one has access to the transaction object, and can watch for progress changes; in PK, after a transaction is launched, there are two ways of getting access to it: first by listening to a TransactionListChanged signal in D-Bus and second by watching the objects returned by the progress_callback callback.

The current approach, helped closely by hue-see (hughsie) on #PackageKit is to get the transactions from the callback and listen to the gobject notify::<property> signals.

More to come next week, stay tuned!

PackageKit backend for Software Center: late week 4 report

Since third week’s report was no report – basically because I was delayed by missing parts in the architecture (the saga hasn’t finished yet), I’m posting this late 4th week report:

Workspace 1_003Yep, the PK InstallBackend is shaping up :D !

Unfortunately, the only machine running this code is mine, the reason being this chain of dependencies:

- static Python bindings for PK are dead

- PK gi depends on pygobject invoke-rewrite branch of J5 (which isn’t
yet merged into master, but will make it to 3.2 release);

- PK gi breaks statically loaded glib in software-center master; therefore, the -gtk3 port of software-center should be used;

- software-center-gtk3 isn’t ready for merging into trunk – experimental design changes towards a friendlier 5.0 are being done.

Therefore I’m testing the install/remove routines on the small modules, such as the PendingView in the above screenshot, waiting for components stabilization.

Next week – and probably until week 6 report, I will continue work on the install parts and start developing the PK PackageInfo class.

PS: I’m undecided if I should make my reports biweekly or milestone based :-/