Software packaging is one of Linux greatest strengths and weaknesses. If all or most of your software comes from your Linux distribution, managing software installs, updates and removal are a piece of cake. But, it can be a fragmented landscape that is confusing for users and annoying for developers and vendors. PackageKit is an attempt to solve some of that.
All of the distros have package tools already, right? So why bother with another toolkit? On Ubuntu you can use APT or the front-end tools to manage packages; on Fedora you have RPM and Yum; openSUSE has RPM and Zypper; and Mandriva has RPM and URPMI. Lots of great tools to work with packages. Well, that’s sort of the problem. All of the distros have their own toolkits. You can install software using various command line tools and GUI utilities. You have RPMs and Debian packages, Slackware packages, Conary, and so on. Each of the solutions has its advantages, but the problem is that they all differ.
This makes it non-trivial to manage software, and it makes it very complex to write documentation. If you’re shipping software for all the major distributions, you may have to explain several ways of installing software.
There’s not much chance of convincing vendors and projects that use RPM to switch to Debian-style packages, or vice-versa. The solution? A package manager agnostic front-end that can manage Linux packages without the end user needing to know if they’re on an RPM or Debian-based system.
PackageKit is used by several of the Linux distributions for updates and software installation. It’s available for most major Linux distros but isn’t installed by default for all of them. Fedora and openSUSE are using PackageKit for updates, and Fedora is using PackageKit for updates and software installs. Ubuntu doesn’t ship PackageKit by default, but it is in the repositories.
PackageKit GUI
For the purpose of this tutorial I’m going to be looking at PackageKit as shipped with Fedora 13 under GNOME. PackageKit is also available to install software; you go to the GNOME System Menu and select Administration then Add/Remove Software. This will bring up the PackageKit dialog to select new software.
You’ll see several panes in the Add/Remove window. It’s pretty self-explanatory; you can search through the package collections, browse various categories (like GNOME desktop, Fonts, or Education) and select the packages or package collections that you want. Behind the scenes, PackageKit is handling the RPM and Yum operations to search the Yum package repos, install software or remove it.
One thing that’s particularly handy is the Software Log Viewer. Wondering what you’ve installed lately? Go to System, Software Log and it will pull up a dialog with all of the packages that have been touched by the Add/Remove Software application. Go to Software Sources (under the System menu) to see what sources your system is using to pull updates and scan for new software.
By default, Fedora should be configured to check for updates automatically. To run updates, you should see an icon in the GNOME taskbar when updates are ready, and all that you’ll need to do is click the icon and it will provide the Software Update menu. You’ll only need to provide the admin password if you want to actually run the updates.
This should show you the type of updates, the size and notes for each update.
The PackageKit interface is fairly full-featured and should be enough for most users to get by on any Linux distribution. However, PackageKit also has a command line interface you can use if you prefer to do things at the command line, or if you want to write scripts that work across distributions.
PackageKit Command Line
The primary tool for PackageKit is pkcon. Unfortunately, its man page is a bit sparse, but you can get all the options you need with pkcon –help. Let’s look at some of the more common operations you might want to use.
To refresh the list of software, run pkcon refresh. This should pull down any new data from the repositories.
To search the repos and see what is installed or available, run pkcon search typestring where type is the type of search, and string is the search string. For instance, if you want to search packages by name, run pkcon search name yum and you’ll see something like this:
Transaction: Searching by name
Status: Starting
Status: Querying
Package: PackageKit-yum-0.6.3-1.fc13.i686
Package: PackageKit-yum-plugin-0.6.3-1.fc13.i686
Package: anaconda-yum-plugins-1:1.0-5.fc12.noarch
Results:
Installed PackageKit-yum-0.6.3-1.fc13.i686
Available PackageKit-yum-0.6.4-1.fc13.i686
Installed PackageKit-yum-plugin-0.6.3-1.fc13.i686
Available PackageKit-yum-plugin-0.6.4-1.fc13.i686
Installed anaconda-yum-plugins-1:1.0-5.fc12.noarch
The results have been trimmed for length, but you get the idea. It shows all packages that match the name, and the state (Installed or Available). You can also search package details using pkcon search details string. If you need to figure out what package provides a specific file, you can use pkcon search file filename. Note that you need to provide the entire path for the filename.
To install software with pkcon, use pkcon install packagename or pkcon install-local filename. The second command will allow you to install a package from the local disk, the first will pull a package from the system repositories. Naturally, you can remove software using pkcon remove packagename as well.
Generally, using pkcon isn’t any harder than using APT, Zypper or Yum. The advantage to learning pkcon is that it should be available for most distributions and you can use the same commands to work with packages on openSUSE, Fedora, Debian, Mandriva, Ubuntu, and others. It’s well worth spending some time to get to know pkcon if you’re working with multiple distributions.
One Tool to Rule Them All
This is one area where users should encourage their favorite distro to focus on one solution, or at least make sure that PackageKit is enabled by default for updates and available for working with packages. As Linux continues to evolve and bring in more mainstream users, it doesn’t help our new users to have to learn multiple tools just to install and work with software at a basic level.
