Package version numbers in names

Evan eapache at gmail.com
Tue Mar 9 19:55:59 UTC 2010


On Tue, Mar 9, 2010 at 11:36 AM, Scott James Remnant <scott at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20100309/ad5f38c6/attachment.html>


More information about the Ubuntu-devel-discuss mailing list