On Tue, Mar 9, 2010 at 11:36 AM, Scott James Remnant <sc...@ubuntu.com>wrote:
> 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. > > > 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 > 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 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
-- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss