Version 24 (modified by timlau, 7 years ago)

Yum D-Bus API

This is a proposal for a API for a Yum D-Bus daemon service. It is implemented as a D-Bus system service with the name 'org.baseurl.Yum' and an interface named 'org.baseurl.yum.Interface'

There is a prof of concept located here:

API marked with (DONE) has been implemented in the POC.

Check this README to see how to test

The idea is to give other applications access the services that yum provides, undependend of the programing language they are written in. And most languages has D-Bus bindings.

The D-Bus service will be auto launch when someone tries to access it. Yum will only lock when some consummer grabs the lock and the yum object will be deleted when the lock is released. So it dont have any big memory impact when not in use. We could close down the service when it unlocked if we want that. The daemon uses PolicyKit to check for acccess, so if the consummer is non root, the user will get a dialog asking for root password, so non root application can easy use the yum services, without security issues.

Points to be worked out:

  • API functions we what to provide
    • What should they do
    • What parameter should they take
    • What should they return an in what format.
      • A good choice for non simple datatypes, could be JSON, it is simple and most languages has bindings for it.
  • Should it be included in the yum source tree or should it live alone ???
    • if inside yum:
      • the daemon code could live in yum.daemon
      • a client wrapper class could live in yum.client
        • Wrap the D-Bus daemon interface in a pythonic way to make it easier to use from a python application.
    • if outside yum
      • how should it be named : yumdaemon (yumdaemon & yumdaemon.client)
      • we could include wrappers for other languages (If someone wants to write them)

Known problems:

There have been some DBus packaging APIs already, we should avoid their mistakes:

  • DBus isn't meant to push around a lot of data, this means things like "list installed" or even "list all" really shouldn't be happening over DBus.
    • Don't seems to be a problem in my tests
      [timlau@r2d2 python]$ sudo python | wc -l 
  • We need to create some kind of context, so that different callers aren't speaking to a single instance. If you don't do this you have huge problems with auditing/etc. This probably means changes in core yum, so that we can have more than a single "backend" at once.
    • With the locking in the current code, we only have one active consumer at a time. Adding multi consumers can cause a lot of pain and weird cases :)
  • Needs to not be a giant single point of failure, so that if user X does a query FOO that isn't affected by user Y doing operation BAR (this is probably related to the previous problem ... and has problems when someone does a transaction).
    • In the current code, I work with a Lock/Unlock so only the consumer there has the lock, will be able to perform any actions until the lock is released. Currently there is no automatic lock timeout, so if there user somehow don't releases the lock, then the daemon is locked. So some kind of automatic unlock & shutdown if no actions is being performed for a period of time.
  • Previous attempts have tied authorization to API calls (this is probably helped by DBus), but this is almost worthless where "install" is a single API call. One hacky solution is to have a stupid number of specific APIs like "install_firefox_plugin". There really needs to be a better way though (maybe DBus feature?)
    • Authentication is a True/False case, All methods there changes the system should need root authentication, selected ones will work without authentication (currently only GetVersion), but others readonly action could be candidates to no require authentication. The main issues is Lock and UnLock, should it be possible to lock yum without authentication ?


Here are some examples for consumer application:


* aptdaemon the D-Bus daemon for apt used in Ubuntu. This is user by the Ubuntu Software Center to do the apt actions.

API Definitions: (Work in Progress)


<Package Id> = "name,epoch,version,release,arch,repoid" (Comma separated string)
<Transaction Id> = "name,epoch,version,release,arch,repoid,ts_state" (Comma separated string)


Lock() (DONE)

start a new yum instance and set the yum lock

Unlock() (DONE)

release the yum lock and delete the current yum instance


GetConfig(option) (DONE)

return value from config

SetConfig(option, value, persistant)

set config option=value (for current session or persistant)


EnableRepo(repo_id, persistant)

Enable repo

DisableRepo(repo_id, persistant)

Disable repo


get list with repos
filter = "" return enabled repositories
filter = "<some pattern>" will return repo matching <some pattern>
Ex. filter = "*" will return all repos., filter = "*-source" will return source repos

GetRepo(repo_id) (DONE)

return information about a repo the information is returned as a dictinary in JSON format

SetRepo(repo_id, repo_info)

change repo info or create new one is not exists
repo_info = {'name' : values,.......}


GetPackages(pkg_narrow) (DONE)

Return list of package ids
pkg_narrow = installed|available|updates|obsoletes|.....

GetPackages_by_name(pattern, newest_only) (DONE)

get a list of package ids where name matches pattern
pattern ::= <pattern string> (ex. 'yum', 'yum*')

GetAttribute(pkg_id, attribute) (DONE)

return an attribute value from at give pkg_id.
attribute = <Yum Package attribute Name> (Ex. 'summanry', 'description')
it return a string there contains a python repr of the attribute
':none' will be returned if attribute dont exist.
':not-found' will be returned if no package matching pkg_id is found


Get updateinfo about a given pkg_id


Methods to handle yum groups/categories

<Do be definded>


Search(fields, keys, match_all)

return a list of package ids for matching packages
fields = a list of package attributes to search in (Name, summary, description etc)
keys = a list of key words to search for.
match_all = define if all keys should match or partial match is allowed (boolean)



return a list with a number of history ids (integers)

elements = the number of elements to return


return a dict with details about a give history id


redo a given history id


undo given history id


AddTransaction(pkg_id, action) (DONE)

Add a package to the current transaction for an given action
action = install|update|remove|reinstall|downgrade|localinstall
localinstall takes a path to a .rpm file as pkg_id
return a list of transaction ids for the packages added to the transaction

BuildTransaction() (DONE)

resolve the dependencies of the current transaction.
return a (return code, output) pair
return code = 2 is transaction was resolved without problems
if no problems output will contains a repr of a list containing tuples of (action, package info list)
if problmes output will contain a list of desolve problem messages.

RunTransaction() (DONE)

will run the current transaction (Download, signature check, test transaction, transaction)

high-level Methods

Simple method to emulate yum cli actions
there methods will find packages matching the argument and add them to the transaction
and return the transaction result for confirmation.
The transaction can then be executed by calling RunTransaction()


Do the same as "yum install args"


Do the same as "yum remove args"


Do the same as "yum update args"


Do the same as "yum reinstall args"


Do the same as "yum downgrade args"

Signals: (D-Bus signals sendt by yum's callback handlers)

UpdateProgress(self,name,frac,fread,ftime) (DONE)

This signal will be sent a evey progress callback when something is being downloaded (metadata, packages etc)

name: filename
frac: Progress fracment (0 -> 1)
fread: formated string containing BytesRead
ftime : formated string containing remaining or elapsed time

TransactionEvent(self,event) (DONE)

This signal will be in differnet part of the transaction flow

event: an action keyword of where we are in the transaction process.
'start-build' : when starting to depsolve
'end-build' : when depsolve is completed
'start-run' : when starting to execute the current transaction
'end-run' : when current transaction is ended without error
'fail' : when current transaction is ended with errors
'download' : when package downloading is started
'signature-check' : when package signature check is started
'run-test-transaction' : when rpm test transaction starts
'run-transaction' : when rpm transaction starts

RPMProgress(pkg_id, action, te_current, te_total, ts_current, ts_total) (DONE)

package: A package id or simple string of a package name
action: the action being performed ( install,cleanup .....)
te_current: Current number of bytes processed in the transaction element being processed
te_total: Total number of bytes in the transaction element being processed
ts_current: number of processes completed in whole transaction
ts_total: total number of processes in the transaction.

Progress(action, percent)

action = action being performed
percent = the progress of the whole transaction in percent