Important Concepts

The following sections explain key concepts used internally in PackageKit.

Package ID

One important idea is the package_id. This is the name;version;arch;data in a single string and is meant to represent a single package. This is important when multiple versions of a package are installed and only the correct one is removed.

The package_id is parsed and checked carefully in the helper code. The package arch and data is optional, but 3 ;'s must be present. For instance, gnome-keyring-manager;2.18.0;; is valid but gnome-keyring-manager;2.18.0 is not. The data field is used for the repository name.

The data field for an installed package must be installed as this is used to identify which packages are installable or installed in the client tools.

The data field for an non-installed local package must be local as this signifies a repository name is not available and that package resides locally on the client system.

For example:

csup;20060318-5;x86_64;local: for locally available package file.
csup;20060318-5;x86_64;fedora-devel: for package that is not installed and can be downladed from the Fedora development repostory.
csup;20060318-5;x86_64;installed: for locally installed package

Situation	Value	Description
Searching	`installed`	If installed
	`available`	If available to install
Getting Updates	`low`	If update is of low severity
	`normal`	If update is of normal severity
	`important`	If update is very important
	`security`	If the update is security sensitive
Installing/Updating/Removing	`downloading`	If we are downloading this package
	`updating`	If we are updating this package
	`installing`	If we are installing this package
	`removing`	If we are removing this package
Otherwise	`unknown`	If we cannot use any other option

The backend must ensure that the package_id only matches on one single package. A single package_id must be enough to uniquely identify a single object in any repository used on the system.