Shared Libraries - naming & versioning

The convention of UNIX shared libraries names may be somewhat puzzling because it appears different systems may not strictly adhere to the convention. What makes most sense appears to be the convention followed on Linux and (apparently) not quite strictly followed on Solaris. On this post I'll try to make a better sense of this in order to discover the right (or at least best) way of doing things in Solaris.

So, let's say I'll be dealing with a central library from an application called myapp. According to what appears to be the best convention, besides a meaningful name including something such as myapp-kernel  I'll also have to be concerned with versioning in the form of 2 (or at most 3) other numbers:
 

• The major version:
  For "big" changes.
   
• The minor version:
  For "small" changes or bug fixes.
   
• The (optional) release:
  For "something else".

By the same convention it's also usual that the name begins by lib (for library) and includes the so (shared object) extension right before the versioning information. Hence, the file name of the shared library version 1.2 (major version 1, minor version 2), release 3, of this fictional example should be called:

But that's not the end of the story. For the sake of version support by the host system it's also a convention the create 2 more symbolic links to this file:

1. libmyapp-kernel.so.1
2. libmyapp-kernel.so

The first symbolic link is intended to represent a chosen (to be "active") minor version and release within the major version 1 series (the set of all minor versions and releases within major version 1) of the shared library. Furthermore, dynamic applications (those which dynamic link to a shared object) linking to the version 1 series of the shared library will try to follow this particular symbolic link in order to properly load the "active" minor version and release.

The second symbolic link is intended to represent a chosen (to be "active") major version series. Dynamic application actually links to this symbolic link, which in turn points to the "active" major version symbolic link which in turn points to the "active" minor version and release. That is:

libmyapp-kernel.so  →  libmyapp-kernel.so.1  →  libmyapp-kernel.so.1.2.3

But that's not yet the end of the story. It has to be shown how all this is tied together in practical terms, which will be the subject of a following post. I'll just end this post adding that for some odd (optimization?) reason what's usually done in Solaris slightly deviates from this as follows:

libmyapp-kernel.so     →  libmyapp-kernel.so.1.2.3

libmyapp-kernel.so.1  →  libmyapp-kernel.so.1.2.3

And in Solaris there are cases where the major version first symbolic link isn't strictly respected as shown on the output below taken from a Solaris 11.3 GA:

A Solaris double-deviation:  libcurl.so.3  →  libcurl.so.4.3.0

OPINION

So far I don't think that this "Solaris deviation" is right or has any significant advantage. On the contrary I tend to believe this is some kind of laziness because anyone could fix this at anytime and because in spite of large chunks of userland software is originated at the open-source community they have been IPS packaged at Oracle.