2.3. PackageKit Architecture

Red Hat provides the PackageKit suite of applications for viewing, updating, installing and uninstalling packages and package groups compatible with your system. Architecturally, PackageKit consists of several graphical front ends that communicate with the packagekitd daemon back end, which communicates with a package manager-specific back end that utilizes Yum (on Fedora) to perform the actual transactions, such as installing and removing packages, etc.

Table 2.1, “PackageKit GUI Windows, Menu Locations, and Shell Prompt Commands” shows the name of the GUI window, how to start the window from the GNOME desktop or from the Add/Remove Software window, and the name of the command line application that opens that window.

Window Title	Function	How to Open	Shell Command
Add/Remove Software	Install, remove or view package info	From the GNOME panel: System → Administration → Add/Remove Software	gpk-application
Software Update	Perform package updates	From the GNOME panel: System → Administration → Software Update	gpk-update-viewer
Software Sources	Enable and disable Yum repositories	From Add/Remove Software: System → Software sources	gpk-repo
Software Log Viewer	View the transaction log	From Add/Remove Software: System → Software log	gpk-log
Software Update Preferences	Set PackageKit preferences		gpk-prefs
(Notification Area Alert)	Alerts you when updates are available	From the GNOME panel: System → Preferences → Session and Startup, Application Autostart tab	gpk-update-icon

Table 2.1. PackageKit GUI Windows, Menu Locations, and Shell Prompt Commands

The packagekitd daemon runs outside the user session and communicates with the various graphical front ends. The packagekitd daemon^[2] communicates via the DBus system message bus with another back end, which utilizes Yum's Python API to perform queries and make changes to the sytem. On Linux systems other than Red Hat and Fedora, packagekitd can communicate with other back ends that are able to utilize the native package manager for that system. This modular architecture provides the abstraction necessary for the graphical interfaces to work with many different package managers to perform essentially the same types of package management tasks. Learning how to use the PackageKit front ends means that you can use the same familiar graphical interface across many different Linux distributions, even when they utilize a native package manager other than Yum.

In addition, PackageKit's separation of concerns provides reliability in that a crash of one of the GUI windows—or even the user's X Window session—will not affect any package management tasks being supervised by the packagekitd daemon, which runs outside of the user session.

All of the front end graphical applications discussed in this chapter are provided by the gnome-packagekit package instead of by PackageKit and its dependencies. Users working in a KDE environment may prefer to install the kpackagekit package, which provides a KDE interface for PackageKit.

Finally, PackageKit also comes with a console-based frontend called pkcon.

^[2] System daemons are typically long-running processes that provide services to the user or to other programs, and which are started, often at boot time, by special initialization scripts (often shortened to init scripts). Daemons respond to the service command and can be turned on or off permanently by using the chkconfig on or chkconfig offcommands. They can typically be recognized by a “d ” appended to their name, such as the packagekitd daemon. Refer to Chapter 6, Controlling Access to Services for information about system services.