ZYpp is a library that gives the status of a system, the available software and updates, and user preferences, can determine the best solution (sequence of actions) to apply those updates and preferences keeping all dependencies in a consistent state.

Warning: This and the pages below refer to libzypp-2.x (opensuse-10.2,SLES-10), so they contain lots of outdated info. Better refer to the developer documentation.

ZYpp actors, the Big Picture

Resolvables

Resolvable is an object that provides and requires. Examples of those are: Packages, Patches (and subelements/atoms Script, Message), Selections, Patterns, Products. All those are known in zypp world as "kind" of resolvables.

Resolvables have various properties. The most important is their dependencies. Dependencies is a list of Capabilities, and capabilities are grouped in categories: requires, prerequires, obsoletes, conflicts, freshens, etc. They are grouped because when looking for a solution, depending on which category a Capability is, it has a different semantic. Another property it is the status. That is “installed” “to be installed”, just “available”, etc.

Capabilities

A Capability looks like “a patch named foo, with a version newer than 2.0”. So you can see, if a package has this capability in its dependencies, in the “requires” group, then it means something different as if it is in the “conflicts” group. What is nice, is no matter in which group they are, as a developer, you can use them all the same way. All you need its just to place them in the correct category.

Sources

So, where do Resolvables come from? The answer is from a Source. A Source is a place where you can get a bunch of resolvables. Of course there are different types of sources. There are Novell Cds/DVDs for installation, there are repositories in the Internet. ZyPP supports all the common ones. Zypp abstract the differences in a generic Source interface. You can use the SourceManager to create a source from a giving URI, and it will autodetect the type, instanciate the particular implementation and give you a generic interface. At the end, for a given source, you only care the list of Resolvables that are there. . Those Resolvables will most likely have the status set to “available”.

Targets

You also have now a running system. And this system has already lot of packages installed. In Zypp this is called Target. Target also provide resolvables, for example, it can look the list of packages in the RPM database, patches and selections from another database, and create a set of Resolvables from those metadata. At the end, the goal is to get Resolvables we can operate on. Those Resolvables will most likely have the status set to “installed”.

Target has a operation called commit. As it can provide Resolvables, you can also give it a bunch of them and ask it to install them. Those resolvables will come most likely from a Source. Next time you ask the Target after commit, for its resolvables. There will be a Resolvable both in the source, and in the Target, because with commit you installed it.

The pool

So, now we have lot of sources, and the target, and we ask them all “gimme all the resolvables”. And what do we do with them. We throw them into the Pool. The pool is just a collection of resolvables.

Now, we add the third ingredient. The user. Humans have some freedom to decide what they want and what they don't. We are not saying what the user decides makes sense, but lets take it in count.

Let's assume the user want to install a package, and remove other. So we can express this desire changing the status of the Resolvables in the pool to “to be installed”.

Now we have a bunch of resolvables in the pool, plus some user wishes, and this should result in a sequence of actions to be done. So we call God here: The Solver. The Solver is a black box which reads the pool, and gives you back a list of problems. The Solver also present the possible solutions to the problem. If you give it back some solutions, it will need to think again and probably then everything is fine, or probably you need to decide again.

Commit

Once there are no problems, you can know now a list of actions in certain order to be done, and commit them into the Target.

Implementation of ZYpp

Code organization

`-- zypp ----------------> public interfaces
    |-- base ------------> string, exception
    |-- capability ------> different capability implementations
    |                      like named, hal, modalias
    |-- detail ----------> resolvable implementation interfaces
    |-- media -----------> abstract media access (http, ftp, file)
    |-- parser ----------> xml, tagfile, yum, inifile parsers
    |   |-- tagfile
    |   `-- yum
    |-- pool ------------> resolvable pool implementation
    |-- solver ----------> ZYpp Dependency Solver
    |-- source ----------> Different repository type implementations
    |   |-- susetags ----> YaST repository types
    |   `-- yum ---------> repomd repository types
    |-- target ----------> targets are information provider backends
    |   |-- hal ---------> provides HAL hardware information to 
    |   |                  HAL capabilities
    |   |-- rpm ---------> creates resolvables from installed packages
    |   |                  and allows package installation
    |   `-- store -------> same as rpm, but for non-package kinds like
    |                      patches, patterns, etc
    |-- thread ----------> threading classes
    |-- ui --------------> helpers useful for writing UIs
    |-- url -------------> url classes
    `-- zypp_detail -----> ZYpp main facade implementation

In trunk, you can find a zypp2 directory, with development code that will be moved to zypp/

`-- zypp2 -------------------> public interfaces
    |-- repository ----------> the future Source* replacement
    |   `-- cached ----------> create resolvables from cache
    |-- cache ---------------> APIs to read and write from the cache
    `-- parser --------------> new parser code that couldn't be added to the old zypp tree
        |                      (will replace the old parsers)
        |--susetags ---------> YaST repository parser
        `--yum --------------> YUM repository parser

Others

ZYpp is written in C++ and makes heavy use of the C++ standard library and Boost.

Boost provides free peer-reviewed portable C++ source libraries. Ten Boost libraries are already included in the C++ Standards Committee's Library Technical Report (TR1) as a step toward becoming part of a future C++ Standard. More Boost libraries are proposed for the upcoming TR2.

Archive:Libzypp design

Contents