Translate

Image of RHCE Red Hat Certified Engineer Linux Study Guide (Exam RH302) (Certification Press)
Image of Android Wireless Application Development
Image of Linux Kernel Development (3rd Edition)
Image of Advanced Programming in the UNIX Environment, Second Edition (Addison-Wesley Professional Computing Series)

Exploring PackageKit's GNOME Software

Fedora 20 (codename Heisenbug) Beta was released on November 12th 2013. One of the accepted system wide change proposals for this release was to replace the existing gnome-packagekit frontends (gpk-update-viewer and gpk-application) with a new unified and more user-centric application.

A quick high-level overview of PackageKit first. It is essentially a framework which consists of frontends such as yum which communicate with backends such as PackageKit-yum via an abstraction layer based on D-Bus. Essentially, it is a set of APIs exported through a D-Bus interface. Glib, qt and python and other language bindings are available. This abstraction layer enables applications to perform high-level package operations such as add or remove a package without having to know much about package management. PolicyKit (AKA PolKit) is incorporated to provide a fine grained policy mechanism for users.

In Fedora 20, the familiar gnome-packagekit-installer is not installed by default OOTB (Out Of The Box) as it was deprecated in favour of GNOME Software. Unfortunately, when I did a Fedup install from Fedora 19 to Fedora 20 Beta a few days ago, both gnome-packagekit-updater and gnome-packagekit-installer were removed but GNOME Software was not installed.

Here is what GNOME Software looks like on my Fedora 20 system:


By the way, the updates tab claimed that all software was up to date until I created the empty file /var/lib/PackageKit/prepared-update.

This is an example of what is displayed when you click on OS Updates:

The current PackageKit frontends are all focused on packages. GNOME Software (/bin/gnome-software), which is also a frontend, was designed from the beginning to focus on installing applications. It presents applications information that is more relevant to casual users, i.e. icons, screenshots, reviews, descriptions, etc. instead of information that is relevant for packagers and system administrators, i.e. dependencies, package size, file lists, etc. It is also possible to easily search and browse for available applications.

As a comparison, here is what gnome-package-updater looks like for the same set of updated packages:

Note that GNOME Software does not currently allow you to install packages online. You are required to do an offline update by rebooting your system. While I have not examined the underlying source code in detail, it appears to use systemd-updates (which in turn uses /usr/libexec/pk-offline-update) to perform the actual package update.

According to the Fedora Appinstaller project page:

For F20, we will focus on completing the offline update experience and use gnome-software for it instead of gpk-update-viewer. Basic application installation and removal will also work. We are planning to show icons and descriptions for application, but most of the needed metadata for uninstalled applications (icons, descriptions, categories) will be provided statically for a limited set of applications. Screenshots, ratings, popularity and interactive features like reviews will have to wait until F21.

For F21, we will focus on adding more application metadata (screenshots, ratings, popularity, etc) and interactive features like reviews. We will also work with the Fedora infrastructure team to obtain the metadata online for all applications instead of shipping it statically for a limited set. To obtain this data in a decentralized an scalable way, we will be adopting a subset of the appstream data format to describe applications in a simple, translatable XML file that can be included upstream with the applications.

Let us now look under the hood at some implementation details. GNOME Software uses a series of what the developers (Richard Hughes being the main developer) call plugins to implement a lot of the underlying functionality. Here is a list of the installed plugins:

# ls -l /usr/lib64/gs-plugins
-rwxr-xr-x 1 root root 36880 Nov 25 12:02 libgs_plugin_appstream.so
-rwxr-xr-x 1 root root 15520 Nov 25 12:02 libgs_plugin_datadir_apps.so
-rwxr-xr-x 1 root root  6992 Nov 25 12:02 libgs_plugin_datadir_filename_local.so
-rwxr-xr-x 1 root root 11192 Nov 25 12:02 libgs_plugin_datadir_filename.so
-rwxr-xr-x 1 root root 11256 Nov 25 12:02 libgs_plugin_desktopdb.so
-rwxr-xr-x 1 root root 11176 Nov 25 12:02 libgs_plugin_hardcoded-featured.so
-rwxr-xr-x 1 root root 11456 Nov 25 12:02 libgs_plugin_hardcoded-kind.so
-rwxr-xr-x 1 root root 23360 Nov 25 12:02 libgs_plugin_hardcoded-menu-spec.so
-rwxr-xr-x 1 root root 15512 Nov 25 12:02 libgs_plugin_hardcoded-popular.so
-rwxr-xr-x 1 root root 11272 Nov 25 12:02 libgs_plugin_local-ratings.so
-rwxr-xr-x 1 root root 15440 Nov 25 12:02 libgs_plugin_packagekit-history.so
-rwxr-xr-x 1 root root 11176 Nov 25 12:02 libgs_plugin_packagekit-offline.so
-rwxr-xr-x 1 root root 15560 Nov 25 12:02 libgs_plugin_packagekit-refine.so
-rwxr-xr-x 1 root root 15568 Nov 25 12:02 libgs_plugin_packagekit.so
-rwxr-xr-x 1 root root 11272 Nov 25 12:02 libgs_plugin_packagekit-updates.so
-rwxr-xr-x 1 root root 11136 Nov 25 12:02 libgs_plugin_systemd-updates.so


If you start GNOME Software with debugging turned on, you will see that these shared objects are loaded when GNOME Software starts up and unloaded when it is terminated. There is not much good information about the design and purpose these plugins other than the README in the ../src/plugins directory, the source code itself, Hughes’s highlevel and incomplete Overall Plan, and this LWN article.

If you look carefully at the first image of GNOME Software shown above, you will see that a lot of application real estate is essentially an application promotion or feature area. Interestingly, you can customize what applications are featured and how they are displayed by modifying the files in /usr/share/gnome-software.

# cd /usr/share/gnome-software
# ls -l
-rw-r--r--    1 root root 286568 Nov 25 12:02 featured-darktable.png
-rw-r--r--    1 root root  71392 Nov 25 12:02 featured-firefox.png
-rw-r--r--    1 root root  97705 Nov 25 12:02 featured-gimp.png
-rw-r--r--    1 root root  53762 Nov 25 12:02 featured-gnome-sudoku.png
-rw-r--r--    1 root root    797 Nov 25 12:02 featured.ini
-rw-r--r--    1 root root 314346 Nov 25 12:02 featured-mypaint.png
-rw-r--r--    1 root root  22240 Nov 25 12:02 featured-weather-bg.png
-rw-r--r--    1 root root 151137 Nov 25 12:02 featured-weather.png
-rw-r--r--    1 root root  77742 Nov 25 12:02 featured-xchat.png

# cat featured.ini
[darktable]
background=url('/usr/share/gnome-software/featured-darktable.png') left 20% / 50% auto no-repeat, linear-gradient(to bottom, #393d39, #5a5e58)
stroke=#1f2122
text=#ffffff

[gimp]
background=url('/usr/share/gnome-software/featured-gimp.png') left 20% / 50% auto no-repeat, linear-gradient(to bottom, #8ac674, #cbddc3)
stroke=#2a6c10
text=#000000

[mypaint]
background=url('/usr/share/gnome-software/featured-mypaint.png') left 67% / 50% auto no-repeat, linear-gradient(to bottom, #8fa5d9, #d8e0ef)
stroke=#4c52aa
text=#362d89

[org.gnome.Weather.Application]
background=url('/usr/share/gnome-software/featured-weather.png') left 80% / 50% auto no-repeat, url('/usr/share/gnome-software/featured-weather-bg.png'), linear-gradient(to bottom, #25486d, #6693ce)
stroke=#d8e0ef
text=#ffffff


Looking at the source code (gs_feature_tile.c), it appears that you can only configure the background image, the stroke color, and the text color.

One of the problems I have with this application is the large amount of metadata such as graphic files, icon files, and description files that is required to support it. Just look at the current size of /usr/share/app-info.

# cd /usr/share/app-info
# ls
icons  xmls
# du -sh
11M
# ls -R | wc -l
1663


Over 1600 files totalling approx 11 Mb of space. This is only going to increase in number and size as we move forward.

Currently this application makes heavy use of systemd-updates and PolicyKit’s pkexec to implement the operating system and applications updating. Moreover it is all or nothing decision; you cannot choose just to update the operating system for example. This requires a restart and a delay while the platform is being updated. This approach is totally unacceptable, even for tablets, in the long term. Updates should be capable of being downloading and staged in the background and installed without a reboot if possible.

While some people have criticized the design of GNOME Software, I quite like it. I would be happier however if I could toggle between a system administrator view of packages and updates, and the current user-centric view. I look forward to following it’s evolution over the next few Fedora releases.

2 comments to Exploring PackageKit’s GNOME Software

  • sean connolly

    Would it be presumptuous of me to suggest that this article provides more evidence for using XFCE. Not only do you get a smaller footprint and a simpler interface, you also get away from what looks like a significant commitment to even MORE GNOME bloat in the future.

  • Sriram Ramkrishna

    Sean – or we can continue to improve the memory consumption. I mean that’s the advantage of open source. Also one man’s bloat is another man’s better user experience.

Leave a Reply