Steve Morris wrote:
> The point I was trying to make is that, using libGL.so.1 as an
> example, modules that have a dependency on libGL should have that
> dependency on the symlink libGL.so which gets modified by standard
> processes to point to the latest version of libGL.so.*. If a module
> absolutely has to have a dependency on libGL.so.1 because the module
> will not work with any other version, then libGL.so.1 should be
> statically linked with the module, as there is no guarantee that
> libGL.so.1 will be around forever. Modules that really do have that
> sort of dependency should not get broken just because someone else
> decided to upgrade the dependent package. The libplasma example is the
> situation that currently exists that illustrates this.
> A large number of packages could be impacted for a vulnerability fix,
> but handling that is what your package management environment is for
> (assuming packages are defined properly), and in a cooker environment
> changes to a large number of packages is no big deal.
> Statically linking modules does increase the disk space which as you
> have said is not ideal, but then neither is writing software to be
> dependent on a specific version of in this case libGL, which is what a
> specific dependency on libGL.so.1 is implying.

Steve, you miss the point, and it's probably the mainframe background
talking.

You are implicitly assuming a lockstep relationship between application
providers and library providers which may exist in a single-vendor
mainframe world, but doesn't exist here.

Apps which don't, can't, or won't upgrade from one major library version
to the next are not uncommon in Linux. The apps are owned by their
creators, and the fact that the library author decides to incompatibly
upgrade the library imposes no requirement on them to conform. That's
why Linux is designed to allow multiple versions of libraries to be be
installed side-by-side, and provides for mechanisms so that the same
system can satisfy the libXXX.so.1 requirement and the libXXX.so.2
requirement simultaneously. The flip side of this is that the apps
can't just require libXXX.so if in fact they are dependent on a specific
version, and the packaging rules expect them to err on the side of
caution, i.e. be more specific rather than less specific.

In other words, the model wants packages to be as specific as they can
be as to their dependency requirements. If the package can work with a
later version, the packager is expected to update the RPM, which doesn't
require updating the source code. But the existing system allows that
to happen at a relaxed pace. The old version will be around as long as
it's needed.