I've seen an interesting pattern in RPM packaging. The main library package will include the shared library itself:


The -devel package will provide headers and a symlink:

/usr/lib64/libavcodec.so -> /usr/lib64/libavcodec.so.54

Why is the libavcodec.so symlink provided by the devel package and not just included with the shared library package? What about the symlink has anything to do with something a developer would want? The headers make sense, but why the symlink to the shared object?


Software from the distribution is mechanically linked consistently, and expects to find libavcodec.so.54, so the unversioned name isn't required for any of the pre-built packages.

If you're building software yourself, however, it's common to use -lavcodec or similar, which will find libavcodec.so unversioned. Similarly, build scripts may expect these names to exist.

The unversioned names aren't required for the distribution packages, so they're not included by default, but as they're useful when building other software they're included in the -devel package. Other distributions make different delineations and include the .so link in the main package; both are reasonable choices.


There are different ways to handle that, but, in the main, it wouldn't need handling if you didn't use automated package management. In fact most of the work done by automated package managers is done just to correct problems caused by automated package management. That isn't intended to mean that there isn't any value in package managers, just that the value added is costly in terms of necessary overcorrection after the fact.

When you settle on a package-management method you kind of lock yourself in. You give control of your rootfs over to some schema or another, and its eccentricities are something you just have to accept from that point on, because thereafter any one file might be codependent on any other file and the only way to know is to unravel the whole web until you can see the bottom.

The package managers weave the web in, among, and atop the dynamically-linked library threads. Package-management solutions typically rely very heavily on dynamic linking - it makes it easier for the package-managers to version control if a whole suite of applications can source the same lib. And so where package managers mostly differ is in their various strategies for handling dynamic library versioning - especially in an FHS environment because the root tree is really the only other major variable piece of the puzzle. You have pointed out one of these typical of apt-based schemas.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.