This wiki was updated to MediaWiki 1.37. If you notice any issues, please report them to admin[at]

openSUSE:Libzypp introduction

Jump to: navigation, search


SUSE Linux 10.0 offered the following programs for package management:

  • YOU - the YaST online update (only update)
  • yast package manager ("yast sw_single") for installation and removal (but not update)
  • apt-rpm as alternative for yast and YOU

With SUSE Linux 10.1, SUSE integrated a new package manager resolver library called "libzypp".

libzypp is the integration of SUSE's yast2 Package manager and Ximian's libredcarpet. At Novell two solutions so far were used - Red Carpet and YaST package manager - and it was decided to merge both in a best of breed approach.

The advantages for SUSE Linux are:

  • A better resolver than before
  • More information about why a package is installed or no solution is found
  • A better integration of all those feature that were added over the years to our package manager.
  • A command line interface ("rug")
  • A common handling of packages *and* patches
  • Dependency handling for update packages
  • A better way to handle selections (we call them now "patterns")
  • Remote management (not yet in SUSE Linux 10.1)
  • Additional repositories during installation
  • More flexibility in handling of different repositories, e.g. it is possible to have additional patterns for each repository.
  • Additional dependencies based on language (for fonts, translations, etc.) or hardware (for drivers)

Libzypp's history

  • Thus, following its consecutive acquisitions SuSE GmbH and Ximian, Novell decided to merge both systems RedCarpet and YaST package manager to its Zen Management Network, designed to manage large heterogeneous park. While the resulting manager, ZYpp, worked well on products Company with the ZMD deamon, it was not very well suited for public distribution, leading to an openSUSE 10.1 release which came out with a system package not working as expected.
  • The openSUSE 10.2 release corrected some defects of the previous release, using the revisited libzypp v2. Then, ZMD was finally removed permanently from the 10.3 release and reserved only to the company Enterprise products. While zypp v3 provided openSUSE with a relative good package manager, equivalent to other existing packages management systems, it suffers from some flaws in its implementation which limited its performance.
  • Projects like OPIUM (Optimal Package Install / Uninstall Manager)[1a] and Mancoosi[1c] were trying to fix dependency solving issues with a SAT solver (Boolean satisfiability problem). Traditional solvers like Apt[1a][1b] sometimes show unacceptable deficiencies, SAT solvers, from the theory of complexity[2], basically work differently from them (see [3] for the operation of the algorithm Apt and Aptitude). It was decided to integrate SAT algorithms into the zypp stack, the solver algorithms used were based on the popular minisat solver.
  • After several months of work, the results are more encouraging: the benchmarks of zypp v4 compared to YUM and Smart, on the same machine, speak for themselves (see [5] to see a few graphs) and Smart "use-case" [6] are properly managed. Another surprising feature of this new zypp is its ability to invoke recommendations physical packages. Need to install a new camera? A simple connection of hardware and a simple "zypper update" command line (or via YaST) and zypp will try to get good drivers from the online repositories.
  • Zypp is to be an independent project of the openSUSE distribution: It has therefore some degree of interoperability [7] with the de facto standard yum, and can be used with other distributions: the graphical user interface implements a complete PackageKit zypp backend. Taking part of the flexibility of the openSUSE Build Service, packages of the ZYpp package manager will be available for other distribution like Fedora and Mandriva Linux [8].


1 - Why did you write a new library from scratch instead of using any existing solution? Why don´t you just refer to Apt which is the most requested one?

After the release of SUSE Linux 10.0 we wanted to take the existing package management infrastructure (above RPM) to the next level and add or significantly improve support for

  • several software repositories, sharing YOU and standard repositories
  • add-on product handling
  • rich local clients (zypper, updater applets)
  • centralized management interfaces
  • patterns, patches
  • C++ API
  • signing of repositories

Looking at the existing open source tools and their maturity available back in 2005, it is obvious that none of those fulfilled the requirements mentioned above and was able to work smoothly with the existing Linux management infrastructure software developed by Ximian and SUSE, both Novell then and now.

For that reason we decided to get the best ideas from existing pieces, but work on a new implementation to meet the requirements.

2 - How does libzypp compare against other tools in terms of features?

Here is a list of libzypp features. Also see Software_Management_Command_Line_Comparison about the functionalities available in different software management solutions based on RPM.

3 - What is the performance of libzypp in comparison with other similar tools?

The first versions of libzypp were indeed rather slow as it was a new library written from scratch. We are constantly improving the performance, based on the experience we are gaining with the released distributions and user feedback. Today, with the inclusion of the satsolver library, libzypp is one of the fastest package manager available.

See also Libzypp/Package Management.

4 - What about standardization and upstream use of libzypp and related technologies?

We are actively working on pushing technologies like rpm support for additional kinds of dependencies, or our enhancements for rpm-md repositories upstream. It does not make much sense to push SUSE-specific features upstream. We are also actively working on the LSB packaging and the rpm5 projects to ensure that SUSE-specific features will become more common in future.


See also

External links