PackageKit Documentation

Richard Hughes


            
          

Version 1.00

Executive Summary

PackageKit is a D-Bus abstraction layer that allows the session user to manage packages in a secure way using a cross-distro, cross-architecture API. PackageKit is built using a lightweight backend architecture. PackageKit is product and vendor neutral and is currently being developed by a small team of developers.


Table of Contents

1. PackageKit Introduction
Overall Description
Backends
Daemon Config Options
TransactionLogging
ShutdownTimeout
DefaultBackend
2. Important Concepts
Package ID
Filters
Error Enums
Group type
Cancellation
Transaction ID
Status Values
3. Methods
Search Name
Search Group
Search Details
Search File
Install Package
Install File
Remove Package
Get Depends
Get Depends
Resolve
Get Update Detail
Get Requires
Get Description
Get Files
Update Package
Update System
Get Updates
Refresh Cache
Get Repo List
Repo Enable
Repo Set Data
4. Signals
Progress
Error
Status
RequireRestart
Message
Package
Description
UpdateDetail
RepoSignatureRequired
5. Compiled Backends
6. Spawned Backends
Methods
Common function outputs
7. DBUS Backends

Chapter 1. PackageKit Introduction

Overall Description

PackageKit is a small open source system that abstracts out common package management tasks such as:

  • Checking for updates and installing them in the background.

  • Automatically installing new or add-on software.

PackageKit has a modular design with an asynchronous API for client programs, a flexible queuing module, and run-time selectable backends.

Backends

A backend is just a compiled .so object that is loaded at run-time and provides an interface to the underlying package commands. A backend converts an async request into either a new thread in the same process, executes external "glue" files that can be written in any language, or uses DBUS to signal a daemon process to handle the request.

Backends do not have to support all of the commands supported by PackageKit. Each backend advertises the commands and options it supports, and the frontend will only show UI elements for those commands. Please see the html/pk-faq.html file for the current status of the existing backends. Backend maintainers, please keep this file updated.

Daemon Config Options

The config file /etc/PackageKit.conf allows to the administrator to change system daemon options. In normal use this file does not have to be changed, but it may be useful to people debugging the daemon or developing backends.

The options are:

TransactionLogging

This logs all transactions to a database so old transactions can be viewed, and rollbacks can be done.

ShutdownTimeout

This is the time that the daemon waits when idle before shutting down. A smaller number will result in slower response times when running many transactions in a small amount of time. A longer timeout will lock the underlying packaging backend for longer, although the daemon will start and stop less often.

DefaultBackend

The default backend that the daemon should use. The default is set at compile time to the --default-backend= configure setting.

Chapter 2. 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 can be used for the repository name or any other purpose. It is designed to make the life of a backend writer a little bit easier.

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 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.

Filters

Search filtering on the name is done in the backend for efficiency reasons. This can be added into the compiled backend if this is not possible in any new backend design.

Filter options are:

OptionDescription
installed or ~installedIf the package is installed on the system
devel or ~develDevelopment packages typically end -devel, -dgb and -static.
gui or ~guiGUI programs typically depend on gtk, libkde or libxfce.
free or ~free Free software. The package contains only software and other content that is available under a free license. See http://fedoraproject.org/wiki/Licensing for a list of licenses that are considered free. If a license cannot be determined from the package metadata, or the status of the license is not known, the package will be marked as 'non-free'.
visible or ~visible Repositories may want to specify if a package should be visible in an application chooser.
supported or ~supported If the package is supported or is a third party addon.
basename or ~basename The basename filter will only return results according to the package basename. This is useful if you are searching for pm-utils and you only want to show the main pm-utils package, not any of the -devel or -debuginfo or -common suffixes in the UI. The basename is normally the original name of the source package.
newest or ~newest The newest filter will only return the newest package available. This is useful if you are searching for gimp and only gimp-2.4.5-1.fc9.i386 would be returned, not gimp-2.4.5-1.fc9.i386, gimp-2.4.4-1.fc9.i386 and gimp-2.4.3-1.fc9.i386.

So valid options would be:

OptionDescription
noneAll packages installed or available with no filtering
devel;~installedAll non-installed development packages
installed;~develAll installed non-development packages
gui;~installed;~develAll non-installed, non-devel gui programs

Error Enums

If you have to handle an error, try to use internal-error as little as possible. Just ask on the mailing list, and we can add some more error enums to cover the type of error in an abstract way as possible.

Every error should have an enumerated type (e.g. out-of-memory) and also an error description. The error description is not translated and not converted into the users locale. The error description should be descriptive, as it's for power users and people trying to debug the problem. For instance, "Out of memory" is not helpful as an error description that is reported in a bugzilla, but "Could not create database index" is. For the description use ; to separate the lines if required.

The following error enumerated types are available for use in all backends:

ErrorDescription
out-of-memoryThere is an out of memory condition
no-networkThere is no network connection that can be used
not-supported Not supported by the backend. NOTE: You shouldn't be setting non-NULL in the compiled backend symbol table if you find yourself using this.
internal-error There was an unspecified internal error. NOTE: Please try and be more specific. If you are using this then we should probably add a new type.
no-cache The operation is trying to read from the cache, but the cache is not present or invalid
gpg-failureThere was a GPG failure in the transaction
package-id-invalidThe package ID is not valid for this transaction
package-not-installed The package that is trying to be removed or updated is not installed
package-not-found The package that is trying to be removed or updated is not installed
package-already-installed The package that is trying to be installed or updated is already installed
package-download-failedA package failed to download correctly
dep-resolution-failedDependency resolution failed
filter-invalid The filter was invalid. NOTE: syntax checking is done in the backend loader, so you should only use this if the filter is not supported by the backend.
group-not-found The specified software group was not found.
create-thread-failedFailed to create a thread
transaction-error There was a generic transaction error, but please give more details in the description
transaction-cancelled The transaction was cancelled as the result of a call to Cancel()
repo-not-foundThe repository name could not be found
repo-configuration-errorOne of the enabled repositories has invalid configuration
repo-not-available There was a (possibly transient) problem connecting to a repository
cannot-remove-system-package Could not remove a protected system package that is needed for stable operation of the system
process-quit The process was asked to quit, probably because it was cancelled
process-kill The process was forcibly killed, probably because ignored the quit request. This is probably due to it being cancelled
failed-config-parsing Configuration files could not be read or parsed.
cannot-cancel The Cancel() method was called, but it is too late to cancel the current transaction.
cannot-get-lock The backend could not acquire a lock on the underlying package management system.
no-packages-to-update UpdateSystem() was called, but there are no packages to update.
cannot-write-repo-config RepoEnable() or RepoSetData() was called, but the repository configuration file could not be written to.
local-install-failed A local file could not be installed. The file might not be readable, or it might not contain a valid package.
bad-gpg-signature The package is signed with a GPG signature, but that signature is not valid in some way.

Group type

Groups are enumerated for localisation. Backends should try to put packages in different groups if possible, else just don't advertise SearchGroup and the options should not be shown in the UI.

The following group enumerated types are available, but please check libpackagekit/pk-enum.h for the latest list.

GroupDescription
accessibilityAccessibility
accessoriesAccessories
educationEducation
gamesGames
graphicsGraphics
internetInternet
officeOffice
otherOther
programmingProgramming
multimediaMultimedia
systemSystem

Cancellation

If you have a multipart transaction that can be aborted in one phase but not another then the AllowCancel signal can be sent. This allows for example the yum download to be cancelled, but not the install transaction. By cancelling a job all subtransactions are killed.

By default actions cannot be cancelled unless enabled in the backend. Use AllowCancel(true) to enable cancellation and AllowCancel(false) to disable it. This can be done for any job type.

For compiled backends that are threaded, the cancel() method can be used to terminate the thread.

For spawned backends, there are two staggered signals send to allow locks to be released or for the backend to clean up after itself:

  • Send the process SIGQUIT.

  • Wait 500ms

  • If the process has not already quit, send the process SIGKILL to terminate it.

Transaction ID

A transaction_id is a unique identifier that identifies the present or past transaction. A transaction is made up of one or more sub-transactions. A transaction has one role for the entire lifetime, but the transaction can different values of status as the transaction is processed.

For example, if the user "Installed OpenOffice" and the backend has to:

  • update libxml2 as a dependency

  • install java as dependency

  • install openoffice-bin

  • install openoffice-clipart

This is one single transaction with the role install, with 4 different sub-transactions. This allows the user to rollback transactions with selected backends, rather than select sub-transactions which may need complex conflict resolution.

The transaction_id must be of the format job;identifier;data where the daemon controls all parameters. job is a monotonically updating number and is retained over reboots. identifier is random data used by the daemon to ensure jobs started in parallel cannot race, and also to make a malicious client program harder to write. data can be used for ref-counting in the backend or for any other purpose. It is designed to make the life of a backend writer a little bit easier. An example transaction_id would be 45;dafeca;checkpoint32

Status Values

A transaction will have different status values as it it queued, prepared and executed. The ::StatusChanged signal from PkClient allow you to design user interfaces that tell the user what is happening with the transaction.

A typical transaction will have the following states:

  • Queued in the active queue (PK_STATUS_ENUM_WAIT)

  • Transaction started, and is being prepared (PK_STATUS_ENUM_SETUP)

  • The transaction is running (PK_STATUS_ENUM_RUNNING)

  • (optional) Data is downloading (PK_STATUS_ENUM_DOWNLOADING)

  • (optional) Data is installing (PK_STATUS_ENUM_INSTALLING)

  • The transaction is finished (PK_STATUS_ENUM_FINISHED)

If the transaction is waiting for other jobs to finish (in the active queue) then the status will be stuck at PK_STATUS_ENUM_WAIT and the UI should show a message to this effect.

If the transaction is waiting for a package lock (when a legacy tool like pirut is loaded and has the yum lock) then the transaction will be stuck at PK_STATUS_ENUM_SETUP.

As a backend writer, you do not have to set PK_STATUS_ENUM_RUNNING manually, as this will be set for you if you set any other value such as PK_STATUS_ENUM_DOWNLOADING or PK_STATUS_ENUM_INFO. However, you will need to avoid setting any status values until a package lock is available and the transaction has started.

Chapter 3. Methods

Methods used by the backends are as follows:

Search Name

The arguments are:

OptionDescription
filter A correct filter, e.g. none or installed;~devel
search_termA single word search term with no wildcard chars.

Do not refresh the package cache. This should be fast.

Always emit installed before available packages first, as it allows the client program to perform the GUI filtering and matching whilst the daemon is running the transaction.

If the backend includes installed and available versions of the same package when searching then the available version will have to be filtered in the backend.

The search query in the backend should not be case sensitive, and should not be sensitive to _ or -.

The search methods should return all results in all repositories. This may mean that multiple versions of package are returned. If this is not what is wanted by the client program, then the newest filter should be used.

This method typically emits Progress, Error and Package.

Package enumerated types should be available or installed.

Search Group

The arguments are:

OptionDescription
filter A correct filter, e.g. none or installed;~devel
group_typeAn enumerated group_type, or unknown

Do not refresh the package cache. This should be fast.

This method typically emits Progress, Error and Package.

Package enumerated types should be available or installed.

Search Details

The arguments are:

OptionDescription
filter A correct filter, e.g. none or installed;~devel
search_termA single word search term with no wildcard chars.

Do not refresh the package cache. This should be fast. This is very similar to search-name. This should search as much data as possible, including, if possible repo names, package summaries, descriptions and URLs.

This method typically emits Progress, Error and Package.

Package enumerated types should be available or installed.

Search File

The arguments are:

OptionDescription
filter A correct filter, e.g. none or installed;~devel
search_termA single word search term with no wildcard chars.

This should search for files. This should allow an application to find out what package owns a file on the system.

This method typically emits Progress, Error and Package.

Package enumerated types should be available or installed.

Install Package

The installer should always install extra packages automatically as the use could call GetDepends prior to the install if a confirmation is required in the UI.

The arguments are:

OptionDescription
package_idA single, valid, package ID.

This should search for files. This should allow an application to find out what package owns a file on the system.

This method typically emits Progress, Status and Error and Package.

Package enumerated types should be downloading, updating, installing or removing.

Install File

The installer should always install extra packages automatically as the use could call GetDepends prior to the install if a confirmation is required in the UI.

The arguments are:

OptionDescription
full_pathA full path and filename to a single package.

This method typically emits Progress, Status and Error and Package.

Package enumerated types should be downloading, updating, installing or removing.

Remove Package

The arguments are:

OptionDescription
allow_deps Either "yes" or "no". If yes allow other packages to be removed with the package, but "no" should cause the script to abort if other packages are dependant on the package.
package_idA single, valid, package ID.

This method typically emits Progress, Status and Error and Package.

Package enumerated types should be downloading, updating, installing or removing.

Get Depends

GetDepends should return packages that this package depends on.

The arguments are:

OptionDescription
filter A correct filter, e.g. none or installed;
package_idA single, valid, package ID.
recursive Either "yes" or "no". If yes then the requirements should be returned for all packages returned. This means if gnome-power-manager depends on NetworkManager and NetworkManager depends on HAL, then GetDepends on gnome-power-manager should return both HAL and NetworkManager.

This method typically emits Progress, Status and Error and Package.

Package enumerated types should be available or installed.

Get Depends

WhatProvides should return packages that provide the supplied attributes. This method is useful for finding out what package(s) provide a modalias or GStreamer codec string.

The arguments are:

OptionDescription
filter A correct filter, e.g. none or installed;
type A PkProvideType, e.g. PK_PROVIDE_ENUM_CODEC.
data The data to send to the backend to get the packages. Note: This is backend specific.

This method typically emits Progress, Status and Error and Package.

Package enumerated types should be available or installed.

Resolve

Resolve turns a single package name into a package_id suitable for the other methods.

The arguments are:

OptionDescription
filter A correct filter, e.g. none or installed;~devel
packageA single package name, e.g. art-clipart.

This method typically emits Error and Package.

Package enumerated types should be available or installed.

Get Update Detail

GetUpdateDetail should return details about the update.

The arguments are:

OptionDescription
package_idA single, valid, package ID.

This method typically emits UpdateDetail and Error

Get Requires

GetRequires should return packages that depend on this package. This is useful to know, as if package_id is being removed, we can warn the user what else would be removed.

The arguments are:

OptionDescription
filter A correct filter, e.g. none or installed;
package_idA single, valid, package ID.
recursive Either "yes" or "no". If yes then the requirements should be returned for all packages returned. This means if gnome-power-manager depends on NetworkManager and NetworkManager depends on HAL, then GetRequires on HAL should return both gnome-power-manager and NetworkManager.

This method typically emits Progress, Status and Error and Package.

Package enumerated types should be available or installed.

Get Description

GetDescription should return the description of that package_id.

The arguments are:

OptionDescription
package_idA single, valid, package ID.

This method typically emits Progress, Status and Error and Description.

Get Files

GetFiles should return the file list of that package_id.

The arguments are:

OptionDescription
package_idA single, valid, package ID.

This method typically emits Progress, Status and Error and Files.

Update Package

The installer should always update extra packages automatically.

The arguments are:

OptionDescription
package_idA single, valid, package ID.

This should search for files. This should allow an application to find out what package owns a file on the system.

This method typically emits Progress, Status and Error and Package.

Update System

The installer should update all the updateable packages on the system, including automatically installing any new packages that are needed for dependancies.

There are no arguments.

This method typically emits Progress, Error and RequireRestart and Package.

Package enumerated types should be downloading, updating, installing or removing.

Get Updates

This function should return a list of packages that are installed and are upgradable. It should only return the newest update for each installed package.

The arguments are:

OptionDescription
filter A correct filter, e.g. none or basename

This method typically emits Progress, Error and Package.

Package enumerated types should be blocked, low, normal, important or security.

The status blocked signifies the package cannot be updated, probably due to other dependencies not being met. This type allows the GUI tools to show to the user that an update exists, but cannot be installed. The reason for it not being installed should be put into the update description when doing GetUpdateDetail.

A filter such as basename or gui is also useful if you want to do filtering on the method to only show the main packages rather than the complete list. The complete list is available but specifying none as the filter. Using no filter which may be useful in advanced tools or when using libpackagekit and searching for an update of a specific name. Other filter types may be present, but can be safely ignored of the backend does not support them.

Refresh Cache

There are no arguments.

This should fetch updated meta-data for all enabled repositories. This operation should be only scheduled when the computer is idle as the network connection will be very active, and will the computer will have have non-trivial levels of hard disk and processor activity. For these reasons, it should not be done automatically when on battery power.

This method typically emits Progress, Error and Package.

Get Repo List

Return the list of repositories used in the system.

The arguments are:

OptionDescription
filter A correct filter, e.g. none or ~devel

This method should emit RepoDetail.

Repo Enable

This enables the repository specified.

The arguments are:

OptionDescription
repo_id A repository identifier, e.g. fedora-development-debuginfo
enabled true if enabled, false if disabled.

Repo Set Data

This sets a parameter for the repository specified.

The arguments are:

OptionDescription
repo_id A repository identifier, e.g. fedora-development-debuginfo
parameter The backend specific value, e.g. set-download-url.
value The backend specific value, e.g. http://foo.bar.org/baz.

Chapter 4. Signals

Signals used by the backends are as follows:

Progress

This is optional. Backends should send the percentage fields to 101 if the amount complete cannot be calculated.

OptionDescription
percentageThe percentage complete of the entire transaction
subpercentageThe subpercentage complete of the sub-transaction
elapsed The amount of time in seconds this transaction has been in the running state
remaining The amount of time in seconds this transaction will take to complete. Zero is sent for unknown.

Error

Errors should only be send on fatal abortion.

OptionDescription
enumEnumerated type, e.g. no-network.
description Long description or error, e.g. failed to connect to mytry.xml

Status

This is optional, but highly recommended. It gives the GUI tools a chance to show a different icon to show what stage the transaction is in, for instance, a downloading icon can be shown whilst in the download state.

OptionDescription
status One of "download", "install", "update", "remove".

RequireRestart

This is optional, but highly recommended.

This can be sent as many times as needed by the backend script. PackageKit will always choose the 'worst' method in the UI notification.

OptionDescription
type One of "system", "application", "session".
detailOptional details about the restart

Message

This allows the backend to queue up a message to be shown after the transaction has completed.

OptionDescription
type One of "warning", "notice", "daemon".
detailRequired details about the message, non localised

Package

If updating, as packages are updated then emit them to the screen. This allows a summary to be presented after the transaction.

When returning results from a search always return installed before available for the same package name.

OptionDescription
infoA valid info string enumerated type
package_idA valid package ID string with as much data as known
summary The one line package summary, e.g. "Clipart for OpenOffice"

The info enumerated type

SituationValueDescription
SearchinginstalledIf installed
 availableIf available to install
Getting UpdateslowIf update is of low severity
 normalIf update is of normal severity
 importantIf update is very important
 securityIf the update is security sensitive
Installing/Updating/RemovingdownloadingIf we are downloading this package
 updatingIf we are updating this package
 installingIf we are installing this package
 removingIf we are removing this package
OtherwiseunknownIf we cannot use any other option

Description

OptionDescription
package_idThe package ID
license The license, e.g. "GPLv2+" or "proprietary". If you need to add a EULA then do it like this: "proprietary;By installing this software\nyou may kill a kitten."
groupThe enumerated package group description
detail The multi-line package description. NOTE: Tabs may have to be stripped from the description to avoid being split.
urlThe upstream project homepage
size The size of the package in bytes. This should be the size of the entire package file, not the size of the files installed on the system.
file_list A list of all files and directories created by the package at install time. The list is separated by the ; character.

UpdateDetail

OptionDescription
package_idThe package ID
updatesA list of package_id's that are to be updated
obsoletesA list of package_id's that are to be obsoletes
vendor_url A URL with more details on the update, e.g. a page with more information on the update. The format of this command should be http://www.foo.org/page.html?4567;Update to SELinux
bugzilla_url A bugzilla URL with more details on the update. If no URL is available then this field should be left empty.
cve_url A CVE URL with more details on the security advisory
restart_enumA valid restart type, e.g. "system"
update_text The update text describing the update in a non-localised way. Newlines should be converted to ";" before printed.

RepoSignatureRequired

Some backends support repositories which use a cryptographic signature, such as GPG. If a package cannot be installed because it is signed with a key that has not been verified, this signal is generated so the user can choose to accept or decline the key.

This signal includes information that can be used to verify that the key should be trusted, such as a URL for the company or person who owns the key, the key's ID, the userid of the key creator, and the date the key was generated.

OptionDescription
repository_name The name of the repository associated with the provided key
key_urlThe URL provided with the key.
key_useridThe user id associated with the key
key_idA unique identifier for the key
key_fingerprintThe hashed fingerprint of the key
key_timestampThe date the key was created
typeThe type of signature used. 'GPG', for example.

Chapter 5. Compiled Backends

If you have a C or C++ binding for your package system then you can use a compiled backend, which is more efficient than using helpers as described below. You can include the headers in the backend (with extra libraries) and then just write the simple code to interface with the methods of PackageKit. A C example can be found in backends/box and a C++ example in backends/apt.

You will have to use threading if your backend does not support async operation as requests have to return immediately. This is very important. Do any significant processing in a thread, and certainly don't return package results without creating a thread. By keeping the backends async we can make sure that there is no blocking which means the command line and UI do not freeze.

Chapter 6. Spawned Backends

If you do not have a C or C++ language binding, PackageKit executes helper scripts written in pretty much any language. It then watches the standard out and standard error and parses the output into compiled backend commands. This means a python library can be interfaced easily with a C backend.

Even when using helpers, a compiled backend stub is still used for two reasons:

  • It is still needed for the dlopen internally in PackageKit.

  • You can add cleverness in the C backend that you might not want to do in the scripted backend, for example using a hashtable in C rather than checking all the names in awk.

Backends are typically open-programmable, which means we can define a standard for what goes on stdin and stdout to try and maximise the common code between the backends. The following section will explain the convention used on backends/conary and backends/yum.

If you are unable to write scripts that conform to these specifications then just launch a PkSpawn object in the compiled helper with stdout callbacks and then try to do screenscraping in the backend. This screenscraping is least popular for obvious reasons.

Backends scripts are run with arguments and data is sent to standard out and standard error asyncronously so that PackageKit can proxy this to DBUS. A method has command line arguments seporated with tabs, and data is also seporated with tabs.

It is important to flush the standard output after each output, else Linux will helpfully buffer the output into more efficient size chunks. If you do not flush, then there will be a long IPC delay. Flushing can be achived in C using fflush or in python using sys.stdout.flush().

Methods

The following methods are mapped from the helper to comand line programs in the compile helper.

MethodFile
Search Namesearch-name.*
Search Groupsearch-group.*
Search Detailssearch-details.*
Search Filesearch-file.*
Install Packageinstall.*
Install Fileinstall-file.*
Remove Packageremove.*
Get Dependsget-depends.*
Resolveresolve.*
Get Requiresget-requires.*
Get Update Detailget-update-detail.*
Get Descriptionget-description.*
Get Filesget-files.*
Update Packageupdate.*
Update Systemupdate-system.*
Get Updatesget-updates.*
Refresh Cacherefresh-cache.*
Get Repo Listget-repo-list.*
Repo Enablerepo-enable.*
Repo Set Datarepo-set-data.*

Common function outputs

The following commands echoed to standard error will automatically make the backend-launcher do the correct action in the compiled helper.

MethodData
Percentagepercentage[tab]value
Subpercentagesubpercentage[tab]value
NoPercentageUpdatesno-percentage-updates
Errorerror[tab]enum[tab]description
Statusstatus[tab]state
RequireRestartrequirerestart[tab]type[tab]details
AllowUpdateallow-cancel[tab]enabled
Packagepackage_id[tab]status[tab]summary
Descriptiondescription[tab]package_id[tab]group[tab]detail[tab]url[tab]size_in_bytes
Filesfiles[tab]package_id[tab]file_list
UpdateDetailpackage_id[tab]updates[tab]obsoletes[tab]vendor_url[tab]bugzilla_url[tab]cve_url[tab]restart[tab]update_text
ChangeTransactionDatachange-transaction-data[tab]data
RepoSignatureRequiredrepository_name[tab]key_url[tab]key_userid[tab]key_id[tab]key_fingerprint[tab]key_timestamp[tab]type
RepoDetailrepo-detail[tab]repo_id[tab]description[tab]enabled

Chapter 7. DBUS Backends

Backend helpers communicating over standard out and standard error are easy to write, but can have some performance problems. For instance, if your packages system has to do a lot of work when it starts up and shuts down, performance in the UI may suffer. In these cases, you can use a persistant backend daemon that communicates to the C backend over DBUS.

Your daemon will be started by DBUS, and should be responsible for it's own thread management. It should receive an Init() method call when the C backend starts, and an Exit() method call before it exits. You should also consider adding a timeout value to your daemon so that it will exit after a set time with no activity from the C backend. That way the daemon will still exit even if the C backend crashes for some reason.

Again, like the helper backends described above, a compiled backend stub is needed. An example of a DBUS backend written in python can be found in backends/yum2, along with a compiled stub written in C.