<div class="gmail_quote">On Tue, Mar 9, 2010 at 11:36 AM, Scott James Remnant <<a href="mailto:scott@ubuntu.com">scott@ubuntu.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="im">On Tue, 2010-03-09 at 10:36 -0500, Evan wrote: > In a normal scenario, for a library X, we would have the package libX. > When a new version of the lib is released upstream, the new version > gets packaged, > and the version field of the package gets bumped appropriately. > </div>No, not true at all. This is the scenario for *badly maintained* libraries, which do not maintain their ABI and instead consider the "upstream version" canonical. Sadly glib, GTK+, etc. were examples of this in the past which is why they have "2.0" in their names :-( The *correct* way for a library, and which the vast majority follow, is that each library has its ABI versioned, and this is reflected in the library's SONAME For example, the first version of a library would be: libexample.so.0 The second version would be libexample.so.1 The third version libexample.so.2 etc. Minor versions are permitted in the library name, so if you add new API/ABI without breaking any existing, you might name it: libexample.so.2.1 this still has a SONAME of libexample.so.2 (since it is compatible) Packaging policy *always* includes the SONAME of the library in its binary package name, e.g. libexample0 libexample1 libexample2 Thus libraries with different SONAMEs are always parallel installable. For the minor version example, both would be libexample2 but different versions of it. dpkg provides the "shlibs" and "symbols" systems for identifying the minimum required version of a library at build time, and encoding this in the dependencies. Thus a package built against libexample2 that actually required symbols from 2.1 would have libexample2 (>= 2.1) in its dependency list, while a package built against the earlier version (or that did not require symbols from 2.1) would have just libexample2 Both can use the same library package </blockquote><div> Thank you so much for clarifying, that makes more sense. Now let's throw symlinks into the mix :) Suppose libexample is at version 1.0 upstream. The previous version was version 0.5. The current package is named libexample0.5 It has a version field of 1.0 </div></div>It installs libexample.so.1.0 It also installs the symlink libexample.so.0.5 -> libexample.so.1.0 Now as I see it the problem exists in one of two places: Either upstream misincremented the major version number (without changing the API/ABI), or it has been mispackaged. Does this make sense? Thanks, Evan