Ask Your Question

Why are RPM dependencies given as sonames instead of package names?

asked 2015-01-26 07:52:19 -0600

casey gravatar image

Why are RPM dependencies expressed as filenames and library sonames instead of the names of the actual packages that satisfy those dependencies?

This layer of abstraction significantly increases the size of the yum repository metadata since

*every library package declares a list of sonames that it provides,

*every package declares a list of sonames that it requires, and

*the relation between packages and sonames is one-to-many.

For example "rpm -q --provides glibc" shows multiple versioned entries for,, libpthread, etc, and every package that requires glibc is likely to list several of these as dependencies despite them all being provided by the same package.

In the debian/ubuntu world, the libraries required by a package are resolved to concrete package names at build time, which makes dependency resolution much faster for the end user since the package manager can just read off the list of required packages. Additionally, this practice makes the repository metadata much smaller, because

1) Library packages do not need to provide all the included sonames as metadata, because those are only used for building packages, not for resolving dependencies at install time.

2) Multiple library dependencies that are provided by the same package are simply expressed as a single dependency on that package. When one builds a package that refers to various shared libraries, the packaging script first lists all the required symbols, replaces each symbol by the package providing that symbol, and then cleans up redundant entries. For instance, package that uses,, and would ultimately list a single dependency on the "libc6" package, which provides all those sonames.

The reduction in metadata size is really quite significant (see for example ). Consequently, a "yum check-update" takes much more time and bandwidth than an "apt-get update". What is the main rationale for RPM's design, and what can be done to reduce the size of the metadata?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2015-01-26 08:17:16 -0600

cobra gravatar image

The answer is in the way that the dynamic linking is done. A package isn't dependent upon another package, it's dependent upon the library that the package provides. This is a significant distinction, and is resolved by the package manager. It's fair to say that some packages are dependent upon other packages - but that's not the true picture with libraries.

What would happen if you needed a certain library but the package containing it had its name changed. Or if it got so big that it was split into two, both containing different libraries.

What if you've changed your repository provider and the package names are slightly different?

It's absolutely fine for Ubuntu to do this if it can guarantee package names. Fedora does not provide any non-GPL compliant packages, so users rely on 3rd party repositories for their non-open-source software.

edit flag offensive delete link more


I believe Debian policy is one package per soname according to a specific formula ( ), so the package name would change if and only if the soname changes. The package maintainer would need to rebuild the package either way.

casey gravatar imagecasey ( 2015-01-26 09:14:27 -0600 )edit

That suggests, then, that there is a 1:1 relationship between packages and shared libraries in Ubuntu. I didn't know that. In Ubuntuland, it seems, the scenery is a different colour... :)

cobra gravatar imagecobra ( 2015-01-26 09:23:35 -0600 )edit

To clarify my previous comment, there's a 1:1 relationship between packages and groups of libraries whose sonames all change together (at least according to debian policy).

casey gravatar imagecasey ( 2015-01-26 09:28:26 -0600 )edit

Question Tools

1 follower


Asked: 2015-01-26 07:52:19 -0600

Seen: 682 times

Last updated: Jan 26 '15