PackageKit backend for pkgng

Project description

This and following sections are written in the future tense because they were written before the project was carried out.

I intend to develop, test and document a packagekit backend for pkgng, ideally with the view of being able to use an existing packagekit frontend such as Apper to install, remove and upgrade packages on a FreeBSD system. This will be written in C against the packagekit and libpkg APIs and glib, and the deliverable will be a .so file that can be used by PackageKit as a backend as well as the source code to compile it.

This would make system administration using binary packages easier in these use cases:

There is an existing packagekit backend for FreeBSD Ports; ideally I would like to implement as much of the functionality already present in that backend as is applicable to pkgng. However, the core functionality (getdepends, getdetails, getupdates, installpackages, refreshcache, removepackages, searchgroup, searchname and updatepackages) would be the main focus of at least the first leg of the project.

Approach to solving the problem

I will be using the pkgng library, libpkg, to create a C-based packagekit backend (as opposed to, say, the ports backend, which uses Ruby). This allows for the backend to be a relatively natural gluing of the two systems.

I intend to make full use of FreeBSD's unique features (sbufs, stdlib extensions, etc) as well as GLib's featureset where applicable and appropriate to make the backend development easier.

Due to problems encountered with the latest version of packagekit, initial development efforts are being concentrated on the (obsolete) version of packagekit in FreeBSD ports (0.6.11) with the aim of porting the code upwards as far as possible after a decent feature set has been achieved.





Test Plan

Initial Ideas

To be discussed with my mentor. Test environment bring-up in week 10.

Current testing efforts are concentrated on informal checking of the output of pkcon as well as some experimental automated acceptance testing via running both pkcon and pkg's equivalent processes on a set of packages and seeing if the output of one can be "mocked up" by the output of the other.

As well as this, static analysis (clang static analyser as well as simple compiler warnings at WARNS level 7) is used.

Possible other forms of testing include:

Tests Available

At time of writing there are:

Running the Tests

To be updated as I go along. Ideally this should be reproducible elsewhere.

The Code

The code (may not be in a compileable state at any given time) is at For cloning, replace "svnweb" with "socsvn".

I usually try to prefix any broken commits' messages with warnings (eg "(BROKEN)").

The main backend development effort is in the directory backend; other elements (such as test code, documentation and suchlike) lie outside of this directory.

All code is GPL2. (Sorry!) This is because PackageKit itself is GPL2. Any code that does not link against PackageKit (should any code exist) can probably be re-licenced as FreeBSD, but I'd rather not do so without legal assurances.

Compiling, Installing and Using

Remember to install ports-mgmt/packagekit and ports-mgmt/pkg before trying to compile.


Unlike the PackageKit backends that live in PackageKit's tree, this backend uses a BSD-style Makefile; this means that you just need to run make and sudo make install. Compilation should work with both FreeBSD GCC and clang; any failure to build using the normal settings should be classed as a bug. (The port should build with clang's -Weverything -Werror, as long as system includes are disabled.)


make install installs to the normal PackageKit backends directory (/usr/local/lib/packagekit-backend).

You will need to edit the PackageKit configuration file (/usr/local/etc/PackageKit/PackageKit.conf), changing the default backend from ports to pkgng.


The PackageKit CLI is called pkcon. Here are a few sample commands to try:

The search and resolve commands can take filters; currently these are --filter installed and --filter "~installed" to limit the search/resolution to installed or non-installed packages respectively.

To specify a version for a package, use a package ID instead of a name. These are strings of the format name;version;arch;repository (where the last two can be omitted, the repository is installed or repo-REPOSITORYNAME, and the arch is for example freebsd:9:x86:32.

Note that you may need to run pkcon as root. Technically this should not be the case, but ConsoleKit/PolKit wouldn't work for me.

In addition to pkcon, you can use the GNOME PackageKit frontent for a graphical user interface...

Graphical user interface

By installing ports-mgmt/gnome-packagekit, you can use the GTK user interface (gpk-application). Again, you may need to run this as root (or solve the mysteries of PolKit and ConsoleKit...!).

The GTK interface is fairly self-explanatory, and is based around a menu of possible packages. You can select a package group to look through on the left hand side, or search using the search bar in the top-left. Other actions are available from the top-level menu.

There appear to be some minor glitches with the GTK interface, which may be due to problems in the backend. Hopefully these will be fixed eventually!

Further Work


SummerOfCode2013/pkgPackagekit (last edited 2013-09-23 10:45:40 by MattWindsor)