Re: [PATCH] Framework shlib versioning

[Jeff Teunissen]

Nicola Pero wrote:
> 
> > Btw, at this point I'm curious and I'd like to know how this is done
> > on Apple.  If you make release 1.5.3 and install it, would that
> > overwrite the resources of already-installed release 1.5.2 ?
> 
> I've looked into this, and Apple has a sort of open policy, but there is
> a caveat :-)
> 
> As usual, the problem arises because of Apple's habit of hardcoding
> absolute/full paths in the linked objects.
> 
> The dynamic linker will remember exactly the path to the shared object
> file.  That path will include 'Versions/XXX/' where 'XXX' is the version
> used in the path.
> 
> So if the version used in the path is the full version (say, 1.5.2),
> then something linked against 1.5.2 wouldn't work with 1.5.3 because the
> dynamic linker would still look for {a_path}/Versions/1.5.2/{more_path},
> and so wouldn't find 1.5.3 which is in
> {a_path}/Versions/1.5.3/{more_path}.

This "problem" is because there is no such thing as a "release version" as
separate from "interface version". That is, a framework has one version, and
1.5.2 and 1.5.3 are (correctly) assumed to be incompatible. The same problem
exists in other projects where people don't understand these things. GNU
libtool includes code that makes it difficult to do this, because it tries
to enforce interface versions being separate by giving them explicit
meanings.

The version triplex for a libtool shared library breaks down into three
single numbers, for "current", "revision", and "age". "current" is the
current version of the interface, "revision" is the # of times that the code
has been revised (released), and "age" is the difference between the newest
and oldest interface versions that the lib implements.

So with GNU libtool, version 9.1.3 (or rather, "9:1:3") means that the
library's interface version is 9, it is the second revision of that
interface (numbering begins at zero), and that it can be used with
applications that use interface versions 6, 7, 8, and 9 of that interface. 

If this were applied to GNUstep, then there would be symbolic links
installed for each of those versions. i.e.

libMyLib.so -> libMyLib.so.9
libMyLib.so.6 -> libMyLib.so.9.1.3
libMyLib.so.7 -> libMyLib.so.9.1.3
libMyLib.so.8 -> libMyLib.so.9.1.3
libMyLib.so.9 -> libMyLib.so.9.1.3
libMyLib.so.9.1.3

If the next release is incompatible with interface versions 6 and 7, you
have:

libMyLib.so -> libMyLib.so.10
libMyLib.so.6 -> libMyLib.so.9.1.3
libMyLib.so.7 -> libMyLib.so.9.1.3
libMyLib.so.8 -> libMyLib.so.10.0.2
libMyLib.so.9 -> libMyLib.so.10.0.2
libMyLib.so.9.1.3
libMyLib.so.10 -> libMyLib.so.10.0.2
libMyLib.so.10.0.2

A monkey-wrench is thrown in when applying this to NeXTish interface
versions, because they are arbitrary strings without inherent meaning except
for perhaps sorting, but that may be specious -- there is no concept of
"newer" or "older" at that level, only "current" and "non-current". There is
no value judgement possible based on version numbers, only whether or not it
is "deployed".

My proposal allows for (specifically) a secondary "release version" to help
distinguish the release name of a package from the version of the
implemented interface; otherwise people will often do incorrect things like
changing the interface version for no reason other than making a new
release. With the separation people will still do that, but it should happen
less often.

[snip]

-- 
| Jeff Teunissen  -=-  Pres., Dusk To Dawn Computing  -=-  deek @ d2dc.net
| GPG: 1024D/9840105A   7102 808A 7733 C2F3 097B  161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project        http://www.quakeforge.net/
| Specializing in Debian GNU/Linux              http://www.d2dc.net/~deek/