Version 16 (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:

https://github.com/timlau/YumTools/tree/master/yum-daemon

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

Check this README to see how to test

https://github.com/timlau/YumTools/blob/master/yum-daemon/README

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.
  • 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.
  • 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).
  • 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?)

API Definitions: (Work in Progress)

Data

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

Locking

Lock() (DONE)

start a new yum instance and set the yum lock

Unlock() (DONE)

release the yum lock and delete the current yum instance


Config

GetConfig(option) (DONE)

return value from config

SetConfig(option, value, persistant)

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


Repository

EnableRepo(repo_id, persistant)

Enable repo

DisableRepo(repo_id, persistant)

Disable repo

GetRepositories(filer)

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


Packages

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

GetUpdateInfo(pkg_id)

Get updateinfo about a given pkg_id


Groups

Methods to handle yum groups/categories

<Do be definded>


Search:

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)


History

GetHistory(elements)

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

elements = the number of elements to return

GetHistoryInfo(id)

return a dict with details about a give history id

RedoHistory(id)

redo a given history id

UndoHistory(id)

undo given history id


Transaction

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?

Install(args)

Do the same as "yum install args"

Remove(args)

Do the same as "yum remove args"

Update(args)

Do the same as "yum update args"

Reinstall(args)

Do the same as "yum reinstall args"

Downgrade(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

Comments