I wouldn&#x27;t strictly blame the package managers.  Last I checked, it&#x27;s not straight-forward to link against any library version other than what the versionless .so symlink points to (-llibname will always use liblibname.so).  The lame workaround is to move a portion of the version into the basename, and that&#x27;s where you get libname2.so, so you can explicitly ask for it with -llibname2).  You can specify the path of the library file to link against, but this doesn&#x27;t get you the same dynamic linking semantics (and you really want to let the linker search the cache for the exact file rather than having to specify the path yourself).<p>It&#x27;s actually pretty straight forward to build multiple packages with the same name and different versions that can be installed side-by-side: it&#x27;s like a single line in an RPM spec file, as long as the files list doesn&#x27;t conflict.  A lot of the required effort is in building the software that uses the library.  The library&#x27;s header files are not often in versioned paths, so the -devel package for multiple versions has conflicts.  It&#x27;s easier to specify the option to configure that installs all the files with a version suffix and just be done with it.  It is, unfortunately, not in the interest of the person doing the packaging to significantly diverge from how upstream suggests it be installed in their docs.  That is, what <i>should</i> happen is entirely doable but, as part of the larger ecosystem of software and packaging and distributions, it&#x27;s complicated and has little payoff.